🚀 go-pugleaf

I note editorially at the outset of this response that I am not a
General Rabid Rerouter, but merely a Domain Absolutist Rabid Rerouter,
that is, I short-circuit to rightmost domain, but otherwise leave
!-paths alone.  The difference is significant.

There are several of these rules with which I quibble, and it is not
at all clear to me that the set of assumptions is complete.

geoff@Fernwood.mpk.ca.us writes:
>  Assumptions:
>	[non-uniqueness of UUCP names; DNS names are unique; UUCP
>	 envelopes are hacked via prepending of pass-through hosts.]

How about "UUCP hosts cannot be counted on to respect RFC-compliant
`operator precedence' in mixed-mode addresses"?  E.g., some UUCP hosts
will take
	a!b@c.d
as
	a!(b@c.d) [broken]
and others will take it as
	(a!b)@c.d [correct].

>  Header Treatment Rules:
>  1.  Headers are treated the same regardless of transport.

No.  Example:
	Origin address given me by someone.else.edu:
		SomeUucpHost!username@out.there.gov
	If I hand it to someone via SMTP, especially DEC-20's w/MAISER:
		I leave it alone.
	If I hand it to a UUCP neighbor:
		out.there.gov!SomeUucpHost!username
Reasoning: UUCP hosts should not be given mixed-mode addresses, due to
my extra assumption above.  I must do the work for them, to ensure
sanity.

This also happens to work around an old bug in smail 2.5 which I have
never taken the time to trace down.

>  2.  Headers should not be touched as messages transit systems UNLESS 
>	 the message is transiting from the UUCP(!) to the SMTP(@) environment.

No.  See above, on SMTP->UUCP.

>  3.  While transiting a message from the UUCP(!) to the SMTP(@) environment,
>  3a.  IF the header contains an (@) style address with a rfqdm address on the
>	    right of it THEN do not touch it;

OK.

>  3b.  IF the header contains an (@) style address with a non-rfqdm address on
>	    the right of it THEN do some type of %ification to the non-rfqdm
>	    address and append the rfqdm (@) address of the transited system;

Absolutely not.  RFC 822, section 6.2.2, page 29:

    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.

There are several implications of this.

First, if a header arrives with the address
	username@OneWordHostName
(lacking, notably, any dotted domain qualifiers), I _cannot_ guarantee
the intended interpretation of the OneWordHostName.  The mailer which
handed me that address has failed the 2nd quoted sentence from 6.2.2.
I cannot say if OneWordHostName was supposed to have been known within
the context of the mailer which handed me the mail, or some other
entity farther behind itself (if the one which handed it to me was
merely the Nth-stage intermediate transfer point).

Second, as a result of the first, given that I have no means by which
to interpret OneWordHostName reliably, I aggressively rewrite it _in_
_my_own_context_, cis.ohio-state.edu.  Since I hide hostnames, I
therefore rewrite this as
	username@cis.ohio-state.edu.

I will _not_ %ify the header.  I flatly refuse.  I %ify the _envelope_
in order to reach, e.g., .bitnet.  Under duress.  Nowhere else.

>  3c.  IF the header does not contain an (@) style address THEN replace 
>	    the header "From:" address with envelope "From " address and 
>	    append the rfqdm (@) address of the transited system. 

I don't think so.  In my configuration, anything lacking _both_ ! and
@ is considered not to be punctuated at all; that is, it looks like a
local username, and I add @cis.ohio-state.edu in accordance with 6.2.2.

>  There is no attempt to fix or clean-up bad/invalid headers or short-circuit
>     routing.  garbage in ==> garbage out (with the exception for rule 3c's
>     handeling of "From:" when transiting a message from !-land into @-land).

You ignore the Property of Non-Reversability of UUCP Paths, at your
peril.  I don't perform DARR[*] for nothing; it's a solution (which
has worked without exception up to this point, mind you) to this
particular Property.

--Karl

[*] DARR: Domain Absolutist Rabid Rerouting.