Silent mail handler

Bruce Lilly bruce at balilly
Fri Mar 29 20:50:53 AEST 1991

In article <1991Mar28.150925.703 at chance.UUCP> john at chance.UUCP (John R. MacMillan) writes:
[ I wrote: ]
>|Both versions of smail fail to handle the "%-hack" (See RFC1123), and
>I'm running smail3.1.18.1, and it most certainly does handle the
>percent hack.

Depending on "attributes", I've seen smail 3.1 turn a perfectly fine
(envelope address) "foo%bar at" (the names have been changed
to protect the innocent) into garbage like "!foo%bar".
That's (1) not a valid RFC822 address because it does not contain an
'@', and (2) if one interprets the '%' as a low-priority '@' (in
accordance with RFC1123), mail gets delivered to the wrong machine.
This has happened recently, and of course people started pointing fingers
at sendmail, saying things like "sendmail is munging addresses". Well, the
problem was clearly demonstrated to be an smail problem -- sendmail was
and is working just fine.

>|...  Sendmail does the job admirably, and frankly isn't as difficult
>|to configure as some people think.
>Is that why there's a package available (EASE) that attempts to make
>it easier?  (1/2 :-) ) I found it not difficult to get sendmail to
>pass mail, I had enormous difficulty trying to keep it from molesting
>the headers.

I've never found it necessary to use "ease". And sendmail with IDA
enhancements has separate rewriting rules for headers and envelope, so
it's trivial to *entirely avoid* rewriting headers.

There's no "trick" to configuring sendmail -- simply (1) read TFM and the
applicable RFC's, then (2) figure out what it is that you're trying to do
(e.g. UUCP<->Internet gateway?, mail delivery via SMTP?, UUCP?) *before*
you start hacking away at  And use sendmail's built-in
regression testing capability to verify that it's working properly before
pressing a new into service.  That's simply common sense.
	Bruce Lilly		blilly!balilly!bruce at sonyd1.Broadcast.Sony.COM

More information about the Comp.sys.3b1 mailing list