reid@sask.UUCP (01/16/87)
A couple of recent postings (sorry, I don't have references) have brought up
two points about the mail routing system. One poster suggested the
possibility of using brackets to force the mail system to parse addresses
the way the sender meant them, and another wondered about the possibility of
forcing sites that usually re-route mail to refrain from doing so.
First, I know from maintaining a mailing list and having to debug the paths
how frustrating it can be to have another site re-route mail when you don't
want it to. I would like to see an extra field added to the "Received:"
header (which gets added by every site the mail goes through) so that we can
tell if bounced mail was re-routed, and if so where.
Getting back to the point:
The mail standard which seems to be in use here is described in the RFC822
document. Section 6.2.3. of this document, along with the sections that
describe syntax, allow for "domain literals", which are strings enclosed in
square brackets ("[", "]"). These are supposed to be passed uninterpreted
to the destination host. Thus, [user@host_a]@host_b should be routed to
host_b, which will then deliver it to user@host_a (if it can). As far as I
can tell, these should nest correctly.
To bypass sites that automatically re-route mail, try:
...!re-routing-host!next-host![path-you-don't-want-re-routed!user]
or
[path!user]@first-host-after-re-routing-host
If the mail systems are RFC822 compliant (big if, in some cases) the
re-routing host can only mess with the path as far as the next site on the
line; since it would have sent it there anyways your path comes out the way
you wanted.
RFC822 makes it clear that this is a hack added to allow people to work
around bad mail systems; seems like they designed it for just this case. Of
course, all of this depends on sites along the line being properly RFC822.
- irving "the best I can give you is a wild guess" reid -
--
reid@sask.uucp {alberta, ihnp4, utcsri}!sask!reid
East is East and West is West and maybe their agents will get in touch and
the twain shall do lunch.gds@sri-spam.istc.sri.com (The lost Bostonian) (01/20/87)
In article <577@sask.UUCP>, reid@sask.UUCP (Trying to stay warm) writes: > First, I know from maintaining a mailing list and having to debug the paths > how frustrating it can be to have another site re-route mail when you don't > want it to. I would like to see an extra field added to the "Received:" > header (which gets added by every site the mail goes through) so that we can > tell if bounced mail was re-routed, and if so where. Add this to your sendmail.cf and it will tell you what your mailer thinks the destination address is when it receives a message: ############################# ### Format of headers ### ############################# ... HReceived: $?sfrom $s $.by $j ($v/$V) id $i for $u; $b ... $u is the recipient user. If mail is rerouted and is returned to you, you'll be able to tell which machine changed the recipient. --gregbo
jc@cdx39.UUCP (01/21/87)
> > The mail standard which seems to be in use here is described in the RFC822 > document. Section 6.2.3. of this document, along with the sections that > describe syntax, allow for "domain literals", which are strings enclosed in > square brackets ("[", "]"). These are supposed to be passed uninterpreted > to the destination host. Great. Now if any of our neighbors implemented it... There's also the point that other brackets "(){}<>" should also be recognized. Mathematicians long ago learned that this improves the readability of complicated expressions. I've gotten several letters explaining that this was considered and rejected in favor of domain notation. I haven't yet seen any of the discussion, and would be interested in seeing the justification. It seems to me that domain notation just made things worse, because it introduced more operators (or new meanings to old operators), without doing anything to the fundamental problem of many operators and no universally-accepted precedence rules. [Note that I'm not saying domains are a bad idea; I agree it is a good idea. But the notation added severely to the confusion and the difficulty of explaining to a novice user how to respond to mail.] > To bypass sites that automatically re-route mail, try: > ...!re-routing-host!next-host![path-you-don't-want-re-routed!user] > I've tried this a few times, and gotten back complaints like Unknown host: [path-you-don't-want-re-routed > [path!user]@first-host-after-re-routing-host > This usually gets something like Unknown user: [path!user] > > RFC822 makes it clear that this is a hack added to allow people to work > around bad mail systems; seems like they designed it for just this case. This is the wrong attitude, just like it would be wrong for a compiler writer to say that you don't need parentheses because you can always do a calculation without them. That's not the point. Grouping notation makes for easier reading. Multiple types of brackets makes for even easier reading. As long as we have more than one mailer, brackets would be a great aid to the poor users trying to navigate the net. Anyhow, if anyone has any of the discussions explaining why email notation is better without brackets, I'd like to get a copy. -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: If we can't fix it, it ain't broke.
diamant@hpfclp.HP.COM (John Diamant) (01/22/87)
> The mail standard which seems to be in use here is described in the RFC822 > document. Section 6.2.3. of this document, along with the sections that > describe syntax, allow for "domain literals", which are strings enclosed in > square brackets ("[", "]"). These are supposed to be passed uninterpreted > to the destination host. Thus, [user@host_a]@host_b should be routed to > host_b, which will then deliver it to user@host_a (if it can). As far as I > can tell, these should nest correctly. First of all, domain literals are not "strings enclosed in square brackets," they are 32-bit Internet addresses (the 4 numbers separated by dots). Host names (and UUCP paths) are not allowed. Second of all, square brackets may not be nested (section 3.4.6 of RFC822). Your idea will not work based on RFC822 standards. Sorry, we will have to come up with something else -- or extend some standards to handle it. > reid@sask.uucp {alberta, ihnp4, utcsri}!sask!reid John Diamant Systems Software Operation UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO