🚀 go-pugleaf

tp@mccall.com writes:
   The sendmail sites (and anyone foolish enough to emulate them) are wrong.
   Headers shouldn't be modified! This is according to RFC822. If you are
   using headers, they are probably rfc822 headers, and thus you should follow
   the rules that go with them.

My sendmail.cf is perfectly happy to leave RFC822-compliant headers
alone.  It's all those damnable broken headers that I feel compelled
to slice, dice, and julienne-fry until they come out looking at least
vaguely reminiscent of something that a TOPS-20 MAISER won't barf all
over.  (And before you ask, Yes, I have to deal with MAISER all the
time, handing it addresses that don't make it complain.)

Take a couple of cases in point.

[1] Start with my favorite example of broken headers, BITNET-
originated mail from a site which doesn't seem to care much for
staying up to date.  (That is, I recognize that, as a purely
ontological statement, "there exist" up-to-date, standards-compliant
mailers for most flavors of systems on the BITNET; but, based on my
mail logs, I assert that one heck of a lot of BITNET sites have admins
who do not care to update their software to use such mailers.  They
prefer old, broken ones.  I _hate_ the BITNET.)

On the BITNET, lacking the DNS, addresses are apparently of the form
UserName@OneWordHostName (hereafter called OWHN).  This is fine, so
long as the mail stays within the BITNET -- but it doesn't, of course,
and it is positively routine for such mail to be aimed at someone
around here without any update to such a header (or Mail From:<>
envelope) to give it a domain.

This is a violation of RFC822 section 6.2.2 page 29 last paragraph[*].
It is a _requirement_ that all addresses show fully-qualified domain
names (FQDNs) any time that a message crosses a domain boundary.  The
reasons for the requirement are trivially easy to understand: Given an
incomplete (or nonexistent) domain specification, it is impossible for
my mailer to figure out how to route a reply back to the originator.

Therefore, in my best Domain Absolutist fashion, my sendmail.cf
notices anything of the form Anything@OWHN and rewrites it as
Anything@cis.ohio-state.edu, and to hell with the BITNET.

(The tendency to rewrite OWHNs as cis.ohio-state.edu actually has
other, perfectly legitimate, reasonable and understandable purposes,
having to do with our use of a shared /usr/spool/mail and the desire
for this entire department to generate mail headers which appear to be
all one big, happy family.)

[2] I see that rewrites of domainisms into !-paths for the benefit of
UUCP sites are protested.  I disagree with the protest.  I count on
the following transform always working, for which I have yet to find a
failure case:

	anything@proper.domain.name <=> proper.domain.name!anything

In my sendmail.cf, I prefer to canonicalize in S3 to stuff@domain.name
syntax, believing that this syntax is the superior method in all
cases.  And when I gateway UUCP-originated mail showing
"OWHN!username" via SMTP to some site, I mostly leave it alone, except
to _add_ "@cis.ohio-state.edu" to it, again because RFC822 requires an
FQDN in all such cases.

However, if I receive mail which shows OWHN!user@F.Q.D.N and I am
about to route it out of here as UUCP mail, that syntax cannot be
assured of working, because "dumb" UUCP sites cannot be counted on to
obey RFC822's requirement of @-over-! precedence.  So I rewrite
"OWHN!user@F.Q.D.N" as "F.Q.D.N!OWHN!user" in the From: line, and the
From_ line (for SMTP Mail From:<>) is modified (by a combination of
sendmail and smail-2.5) to be "osu-cis!F.Q.D.N!OWHN!user," thus giving
a syntax which even a dumb UUCP site can cope with.

And lastly, when I receive mail of the form "F.Q.D.N!OWHN!user" and I
am about to deliver locally or to forward via SMTP, I rewrite it to
"OWHN!user@F.Q.D.N," which works for RFC-compliant sites.  (MAISER is
kept happy -- and that's important to me. :-)

   Since sendmail sites do muck with the header, I have to have extensive
   rewrite rules to clean up addresses so they are useable. I get unuseable
   From: lines because my neighboring site is a sendmail site.

The latter does not necessarily follow from the former: The fact that
sendmail mucks with the headers does not, in and of itself, cause you
to get unusable From: lines.  The problem is that one can almost
always expect that vendor-supplied sendmail.cf files are broken and
unusable, and that most sysadmins are not willing to invest the time
required to understand what it is that sendmail is doing, much less
how to update a sendmail.cf to do something other than what it already
does.  Understanding sendmail.cf is admittedly a daunting proposition.

   If by internet-compliant you also
   mean rfc822 compliant, this is one of the rules of the game. If everybody
   would leave the From: line alone, it would be reliable.

Feh.  An entirely unsupportable assertion.  If everybody left the
From: line alone, it would be set to whatever the first broken mailer
set it to, which is frequently incorrect right from the outset.  Mail
gets here pretty routinely from UCBerkeley with OWHNs in the UNIX
From_ line, rewritten to "cis.ohio-state.edu."  (No, not from ucbvax
or ucbarpa, but yes, from other UCB sites.)

   The basic problem here is there is not a clear model of what an
   internet-uucp gateway should be.

Hm.  Well, maybe and maybe not.  I tend to think that I've got a
pretty clear model of what it is that I'm doing.  This is how I look
at the task, simplified to table format:

Incoming Address	Departing via	Rewrite
-------- -------	--------- ---	-------
owhn!user		local or UUCP	don't touch it
			SMTP		owhn!user@cis.ohio-state.edu

user@f.q.d.n		local or SMTP	don't touch it
			UUCP		"From:" -- don't touch it
					"From_" -- osu-cis!f.q.d.n!user

owhn!user@f.q.d.n	local or SMTP	don't touch it
			UUCP		"From:" -- f.q.d.n!owhn!user
					"From_" -- osu-cis!f.q.d.n!owhn!user

f.q.d.n!owhn!user	local or SMTP	owhn!user@f.q.d.n
			UUCP		as for previous case

It seems to be a pretty clear model to me.  I do minimal-but-necessary
changes, I don't support %ification wraps except for a couple of very
small special cases, and I don't deal with `:' or `.' at all as
address punctuation.

--karl

[*] RFC 822 6.2.2 p.29 last paragraph:
    "When a message crosses a domain boundary, all  addresses must
    be  specified  in  the  full format, ending with the top-level
    name-domain in the right-most field.  It is the responsibility
    of  mail  forwarding services to ensure that addresses conform
    with this requirement."