Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip
From: chip@tct.uucp (Chip Salzenberg)
Newsgroups: comp.mail.misc
Subject: Re: Which headers may Sendmail re-write?
Message-ID: <277106F1.1079@tct.uucp>
Date: 20 Dec 90 18:46:09 GMT
References: <1990Dec13.131236.25304@mp.cs.niu.edu> <276D0D6A.6581@tct.uucp> <1990Dec18.152151.29598@mp.cs.niu.edu>
Organization: Teltronics/TCT, Sarasota, FL
Lines: 41

According to rickert@mp.cs.niu.edu (Neil Rickert):
>No where did you get the idea that I support "pessimistically rewriting
>all mail headers for the greats common denominator"  -- I never said that,
>and I don't practice that.

Well, I apologize for jumping to conclusions.  Having read further
messages from Mr. Rickert, I see that he refuses to rewrite addresses
that arrive via UUCP unless the host part of the address specifies one
of his neighbor sites.  I have no objection to this policy.

On the other hand, Mr. Rickert also writes:

>If I see mail with a header address 'user@host.valid.domain', and I am
>forwarding it to a host which does not understand RFC822 addresses, I WILL
>rewrite that as 'host.valid.domain!user'.  The fact that uucpnode may not
>be the final destination is AN IMPORTANT PART of the reason.  For 'uucpnode'
>is very likely to blindly stick 'uucpnode!' in front of the address.

Let's analyze the situation described here.  As a message moves from
site to site via UUCP, each site's mailer can (1) understand or (2)
not understand RFC822.

In the first case -- a "smart uucp" site -- the mailer will recognize
valid RFC822 addresses and leave them alone.  This is so because a
properly configured Sendmail will only prepend "host!" to an address
that already contains a bang.  (Note that sites with broken Sendmail
configurations are not a valid excuse to mangle headers.  They may be
a pain, but they're not an excuse.)

In the second case -- a "dumb uucp" site -- the mailer will not know
that the RFC822 headers even exist, since it is concerned only with
the message envelope.  It therefore will not prepend "host!" to the
RFC822 addresses in the header.

Therefore, according to the preceding analysis, there is no reason
ever to rewrite a valid RFC822 address into a bang path.  What have I
missed?
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
"Please don't send me any more of yer scandalous email, Mr. Salzenberg..."
		-- Bruce Becker