geoff@Fernwood.MPK.CA.US (Geoff Goodfellow) (07/13/89)
[The following blurb is the result of an ~11pm-1am fueling at The Oasis (a local
burger/pizza/beer garden) between Geoff Goodfellow & Paul Vixie. Comments?]
ASSUMPTIONS & RULES FOR TRANSITING UUCP/SMTP MESSAGES
Assumptions:
1. UUCP(!) style addresses are not guaranteed to always be unique and/or
registered in the uucp maps.
2. SMTP(@) rfqdm style address are unique and registered in the DNS.
3. The envelope of a UUCP message is always touched as a message transits
a system, by prepending the transited systems name to the front.
Header Treatment Rules:
1. Headers are treated the same regardless of transport.
2. Headers should not be touched as messages transit systems UNLESS
the message is transiting from the UUCP(!) to the SMTP(@) environment.
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;
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;
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.
Notes:
DNS = Internet Domain Name System.
rfqdm = Registered Fully Qualified Domain address in the DNS.
An (@) style address is an address with an @-sign in it.
You cannot assume an (@) style address is a rfqdm name without checking its
validity with the DNS when transiting messages from UUCP -> SMTP, as there
are hosts which will assign themselves a DNS style name without registering
it in a DNS server connected to the Internet. (Use of the PSEUDODOMAIN
function in IDA Sendmail permits bypassing DNS lookups on bogus top-level
domains such as .uucp, .bitnet, .janet, et al and then proceed
directly to rule 3b).
Some systems prepend their name to headers as a message transits them
(in violation of rule 2). This inconsistiency is fixed by copying
the envelope "From ", which is always augmented as a message transits
a system (assumption 3) into the "From:" header field (rule 3c).
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).
Some Rule Examples (fernwood.mpk.ca.us is the UUCP -> SMTP gateway host)
2. z!foo --> z!foo
x!y!z!foo --> x!y!z!foo
x!y!z.com!foo --> x!y!z.com!foo
3a. foo@z.com --> foo@z.com
3b. foo@z.uucp --> foo%z.uucp@fernwood.mpk.ca.us
bar@z.bitnet --> bar%z.bitnet@fernwood.mpk.ca.us
foo@z --> foo%z@fernwood.mpk.ca.us
foo@bogus.com --> foo%bogus.com@fernwood.mpk.ca.us
3c. Envelope: x!y!z!foo
Header: x!z!foo --> x!y!z!foo@fernwood.mpk.ca.us
Envelope: x.com!y!z!foo
Header: x.com!y!z!foo --> x.com!y!z!foo@fernwood.mpk.ca.us%%%lear%%%@NET.BIO.NET (07/13/89)
[In reply to Geoff Goodfellow's message, <1368@fernwood.MPK.CA.US>] This is not really a criticism on your suggestions for gateways, but more a point on interprotocol routing, in general. It is up to a gateway to decide how it will handle a protocol conversion. That site must perform some manipulation on the header (as specified by what protocol exists at the far end). So long as the message is delivered, the gateway's responsibility is discharged. It would also be nice, if at all possible, if the gateway presents a replyable message. For example, BITNET was in past well known for its limitations on usernames and hostnames. DECNET is even worse. -- Eliot Lear [lear@net.bio.net]
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (07/14/89)
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.