paul@vixie.UUCP (Paul Vixie Esq) (06/29/87)
In article <8120004@hpfclp.HP.COM> diamant@hpfclp.HP.COM (John Diamant) writes: >All these [RFC{822,920,976}] >standards explicitly require "@" precedence, and indeed, the whole point of >SMAIL was to make the UUCP world RFC compliant. This was my observation; I want to quote it here to help drill in two points: 1- every known Internet RFC that mentions it at all requires @-precedence; 2- SMAIL is compliant with the RFC's -- that's its reason for existing. >[Paul Vixie writes:] >> There is also no need rewrite the envelope unless the destination CANNOT >> deal with it, so only gateways should have to do it, right? And a UUCP to >> RFC822 gateway can always produce a <> route, and a RFC822 to UUCP gateway >> can always produce a ! route, right? > >I wish it were that simple. Obviously, this is what you would have in an >ideal world (only gateways worry about address translation), but it isn't >that simple, unfortunately. > >First of all, RFC-822 source routes can only be >used if each element is a registered domain (there are subtle points in the >wording of RFC-822 which mandate this). This means, unregistered UUCP hosts >cannot be put in source routes. Feh. I hadn't read this anywhere, but it sounds like a nasty. I gateway between UUCP and SMTP internally all the time, and I certainly don't check any list to see if the site is registered before writing it into an RFC822 route-addr. Perhaps this restriction only applies to real live Internet mail, and is a political thing meant to keep DDN from being used as a carrier for non-DDN-destined messages? I know that that political restriction exists (though it is widely, er, "bent" :-)); is this just another form of it? I expect that a lot of sites use RFC822-style route-addrs at some point in their internal networks without checking to see that each element of the route is a registered domain. Thanks for bringing this up, John. Now, can we discuss it some? >One more problem is how to handle "%." Since >it isn't specified by any standard, it must remain untouched, which might work >O.K. if the precedence everywhere were always "@", "!", any other characters >(including "%"), but some sites don't know anything about "!" and so interpret >"%" as higher precedence than "!." Gag me with a hetrogeneous network. This IS a problem -- % is widely used, but undocumented. This is a major hole in the Internet mail standards, and it's what lets SMTP be ambiguous about what it will do with an address. Still, the % operator is not absolutely neccessary in a pure RFC822 or UUCP world -- there is a way in each standard to specify a route unambiguously. Therefore a gateway from a net that had local usage of "%" could do whatever the local users expect when parsing the "%"'s, and put out either a !-path or a route-addr when passing the message into the RFC-compliant network. If there are networks which have members that put out ambiguous addresses, the members should be encouraged not to do that. Internet and UUCPnet differ somewhat in this respect -- UUCPnet is a free-for-all. But even in UUCPland, an address/route that contains only words, dots, and bangs will be very hard to misunderstand. A gateway (or even a single site) that wants to be able to accept addresses with @'s or %'s in it can rewrite according to local customs when putting the message out onto the UUCPnet. Or the Internet. >When you translate from "!" addresses to >RFC style addresses, how do know whether to use a source route or a "%?" I'd say always use a source route. Is this unfeasable? Are there Internet sites (here I mean DDN-only sites) that don't grok source-routes, and need %-routes? This sounds like the point to push, if so. >[Paul Vixie again:] >> It is much more likely that we can get fixed gateways than asking all >> sites in the universe to perpetuate the confusion between a route and an >> address. What Rahul is asking is a new way to write routes, and we already >> have perfectly unambiguous ways to do that. > >It certainly would be easier if all we needed is to get only gateways fixed, >but I don't know how to hide all this from the non-gateway machines. If we take "gateway" to mean a mail transport program on some host that generates messages into a network (UUCP or SMTP, in this discussion) where the source of the messages is either a local user or a non-public (i.e., internal) network, then the "gateway" is responsible for rewriting the source and destination addresses into something acceptable to the public network (UUCP or SMTP). The major public networks, UUCP and SMTP, have (as far as I know) unabiguous syntaxes for full source routes -- either UUCP: host1!host2!host3!finalhost!user or SMTP: <@host1,@host2,@host3:user@finalhost> Addresses containing operators or combinations of operators which have no standard meaning in the public network (like %, or combinations of %/@, or %/!, or !/@) can rewrite according to local (host or internal network) custom. Okay, pour it on: what am I missing? >John Diamant >TSBU UUCP: {hplabs,hpfcla}!hpfclp!diamant >Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM >Fort Collins, CO -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013
diamant@hpfclp.HP.COM (John Diamant) (07/01/87)
> / hpfclp:comp.mail.misc / paul@vixie.UUCP (Paul Vixie Esq) / 6:28 pm Jun 28, 1987 / > In article <8120004@hpfclp.HP.COM> diamant@hpfclp.HP.COM (John Diamant) writes: > > Feh. I hadn't read this anywhere, but it sounds like a nasty. I gateway > between UUCP and SMTP internally all the time, and I certainly don't check > any list to see if the site is registered before writing it into an RFC822 > route-addr. Perhaps this restriction only applies to real live Internet > mail, and is a political thing meant to keep DDN from being used as a > carrier for non-DDN-destined messages? I know that that political restriction > exists (though it is widely, er, "bent" :-)); is this just another form of > it? I expect that a lot of sites use RFC822-style route-addrs at some point > in their internal networks without checking to see that each element of the > route is a registered domain. It is not a political restriction. It is to avoid having things that look like domains but can't be replied to because they aren't properly registered (in other words, machines won't know who they are or be able to look them up). Allow me to quote from RFC-822: route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom ; symbolic reference [...] 6.2.1. DOMAINS A name-domain is a set of registered (mail) names. A name- domain specification resolves to a subordinate name-domain specification or to a terminal domain-dependent string. Hence, domain specification is extensible, permitting any number of registration levels. Notice that the syntax specification refers to the word domain and that the definition of domain says "registered." This is pretty explicit. If it isn't registered, it isn't legal in a source route. > > Thanks for bringing this up, John. Now, can we discuss it some? Sure. > > Gag me with a hetrogeneous network. This IS a problem -- % is widely used, > but undocumented. This is a major hole in the Internet mail standards, and > it's what lets SMTP be ambiguous about what it will do with an address. Yup! It is, however, compatible with the RFCs. The "%" is part of the local part, and thus subject to interpretation by the final destination only. That's what makes it lower precedence. > > Still, the % operator is not absolutely neccessary in a pure RFC822 or UUCP > world -- there is a way in each standard to specify a route unambiguously. > Therefore a gateway from a net that had local usage of "%" could do whatever > the local users expect when parsing the "%"'s, and put out either a !-path > or a route-addr when passing the message into the RFC-compliant network. I'm not sure this is right. It depends what you mean by local user. The "%" has to be interpreted as part of the "local part" of the address, by the destination machine. In other words, with local-user%localhost@domain, the "%" must be interpreted by domain, not by the sender's machine. It sounds like you are advocating having the sender's machine attach an interpretation to "%," which is wrong, I think. > > If there are networks which have members that put out ambiguous addresses, > the members should be encouraged not to do that. Internet and UUCPnet differ > somewhat in this respect -- UUCPnet is a free-for-all. But even in UUCPland, > an address/route that contains only words, dots, and bangs will be very hard > to misunderstand. A gateway (or even a single site) that wants to be able > to accept addresses with @'s or %'s in it can rewrite according to local > customs when putting the message out onto the UUCPnet. Or the Internet. Again, I don't think you are allowed to apply local interpretation to "%" since only at the point where you are ready to interpret the local-part (on the final destination) can you break it apart. > > >When you translate from "!" addresses to > >RFC style addresses, how do know whether to use a source route or a "%?" > > I'd say always use a source route. Is this unfeasable? Are there Internet > sites (here I mean DDN-only sites) that don't grok source-routes, and need > %-routes? This sounds like the point to push, if so. Well, one of the main reasons for using "%" is for unregistered machines. Given what I said about source routes not allowing unregistered domains, this creates a bit of a dilema. Also, if a "%" came in and was translated to "!" and then left again, but was now as source route, then you've illegally applied an interpretation to it. I think there are many machines that don't handle source routes properly. However, that by itself is only an argument to get those machines fixed, not a reason to use "%." The reason "%" appears to be needed is to handle unregistered hosts. > > If we take "gateway" to mean a mail transport program on some host that > generates messages into a network (UUCP or SMTP, in this discussion) where > the source of the messages is either a local user or a non-public (i.e., > internal) network, then the "gateway" is responsible for rewriting the > source and destination addresses into something acceptable to the public > network (UUCP or SMTP). The major public networks, UUCP and SMTP, have > (as far as I know) unabiguous syntaxes for full source routes -- either > UUCP: host1!host2!host3!finalhost!user > or SMTP: <@host1,@host2,@host3:user@finalhost> If you are allowed to randomly switch back and forth between source routes and UUCP routes (when you switch transports, of course) and "%" aren't allowed, then I think this would work. But again, this requires that unregistered hosts be allowed in source routes. > > Addresses containing operators or combinations of operators which have no > standard meaning in the public network (like %, or combinations of %/@, or > %/!, or !/@) can rewrite according to local (host or internal network) > custom. See objection above. > > Okay, pour it on: what am I missing? I gave it a shot. What do you think now? This situation is deceptive. Scott McGregor (also of HP) and I tried to write an RFC to clarify this problem and we discovered the deeper we got, the more complicated the RFC got, and the worse the problem became. We did convince Mark Horton (author of RFC-976) the a real problem did exist with "%" and some ambiguities in RFC-976, but we never came up with a satisfactory additional RFC to resolve the issues (though we did write one that isn't satisfactory). The basic problem was that no matter how you looked at it, you needed to know too much about your next hop machine to know how it would interpret addresses (foo!bar%baz@foobar -- is the "%" interpreted before or after the "!"?). > > >John Diamant > >TSBU UUCP: {hplabs,hpfcla}!hpfclp!diamant > >Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM > >Fort Collins, CO > > -- > Paul A Vixie Esq > 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul > San Francisco ptsfa!vixie!paul@ames.arc.nasa.gov > CA 94116 paul@vixie.UUCP (415) 864-7013 John Diamant again -- see signature above!
paul@vixie.UUCP (Paul Vixie Esq) (07/12/87)
>> = Paul Vixie > = John Diamant >>[Paul Vixie wonders why every host in a route-addr needs to be registered. >>Suggests that it may be a political thing, because ARPA dislikes being >>used as a transport for non-ARPA mail (that originates and terminates on >>non-ARPA hosts).] > >It is not a political restriction. It is to avoid having things that look >like domains but can't be replied to because they aren't properly registered >(in other words, machines won't know who they are or be able to look them >up). Allow me to quote from RFC-822: [relevant quote omitted] >Notice that the syntax specification refers to the word domain and that >the definition of domain says "registered." This is pretty explicit. If >it isn't registered, it isn't legal in a source route. It seems unnecessary, since nobody needs to reply to anyone in the middle of a route -- just the first. The others are relative. If they all have to be registered, then one assumes that every host will know how to get mail to them, and wouldn't need route-addrs. Still, I agree with your interpretation of RFC-822 in this respect. I guess this IS a valid reason to use %@ instead of <@,:@>. But it seems like a gratuitous restriction, for the reason I stated above. >> Still, the % operator is not absolutely neccessary in a pure RFC822 or UUCP >> world -- there is a way in each standard to specify a route unambiguously. Well, even I disagree with this now. The only routing syntax available in the SMTP world is %@, apparently; if there is no standard that specifies "%", then routes cannot be rewritten between UUCP- and SMTP-based networks, and gateways between them will necessarily not be perfect. >> >When you translate from "!" addresses to >> >RFC style addresses, how do know whether to use a source route or a "%?" >> >> I'd say always use a source route. Is this unfeasable? Are there Internet >> sites (here I mean DDN-only sites) that don't grok source-routes, and need >> %-routes? This sounds like the point to push, if so. Again, critiquing myself, I'd now say to use "%" for routes rewritten from a UUCP network that will be forwarded on an SMTP network ... >Well, one of the main reasons for using "%" is for unregistered machines. ... and that's why. >Also, if a "%" came in and was translated to >"!" and then left again, but was now as source route, then you've illegally >applied an interpretation to it. The envelope address in the UUCP network should always have a pure !-route in it (if it doesn't, then is still SHOULD :-)). When a gateway host gets a message from its UUCP side, and detects that it needs to be forwarded to an SMTP network, it can rewrite the envelope address as much as it wants to do. The header address may be in normal, domain form, in which case it should be left alone so that replies can use a new (and perhaps better) source route; if the header addresses are in !-form, well, they aren't protected by RFC-822 (the whole thing would be a local part), and can be re-written into the routing syntax of the new network (SMTP, in this case). The fact that SMTP doesn't have a routing syntax (route-addrs need registered hosts only, and % is non-standard) stops this scheme in its tracks. Can we bend or push either of those restrictions? >I think there are many machines that don't handle source routes >properly. However, that by itself is only an argument to get those >machines fixed, not a reason to use "%." The reason "%" appears to be >needed is to handle unregistered hosts. Well, if a route is to contain (potentially) the contents of a UUCP path (after it passes through a UUCP->SMTP gateway), we need a routing syntax that can handle unregistered hosts. >I gave it a shot. What do you think now? This situation is deceptive. >Scott McGregor (also of HP) and I tried to write an RFC to clarify this >problem and we discovered the deeper we got, the more complicated the >RFC got, and the worse the problem became. We did convince Mark Horton >(author of RFC-976) the a real problem did exist with "%" and some ambiguities >in RFC-976, but we never came up with a satisfactory additional RFC >to resolve the issues (though we did write one that isn't satisfactory). >The basic problem was that no matter how you looked at it, you needed to >know too much about your next hop machine to know how it would interpret >addresses (foo!bar%baz@foobar -- is the "%" interpreted before or after the >"!"?). I think you're right about % being insufficient, and you seem to be right about <@,:@> being insufficient, and I'm not sure what to suggest. Maybe we can remove the registration restriction on route-addrs -- as I stated way up there, it doesn't seem to be necessary (and it certainly isn't helpful in this case!). Alternatively, an RFC that specified "%"/"@"/"!" and their relationship to eachother would make "perfect" UUCP/SMTP gateways possible. You can send me your unfinished RFC, if you think it will enlighten me... -- Paul A. Vixie, Esq. "A viler evil than to throw a man into a paul%vixie@uunet.uu.net sacrificial furnace, is to demand that he {uunet,ptsfa,hoptoad}!vixie!paul leap in, of his own free will, and that he San Francisco, (415) 647-7023 build the furnace, besides." (Ayn Rand)
ambar@athena.mit.edu (Jean Marie Diaz) (07/14/87)
In article <715@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: > >It seems unnecessary, since nobody needs to reply to anyone in the middle of >a route -- just the first. The others are relative. If they all have to be >registered, then one assumes that every host will know how to get mail to >them, and wouldn't need route-addrs. Well, in the Arpanet world at least, that's a nice theory. But quite often these days, the ONLY way for me to get mail to a given machine on the west coast is to route through ucbvax: foo%decwrl.dec.com@ucbvax.berkeley.edu This isn't a matter of us not "knowing" decwrl -- the problem is that the net is so overloaded that we can't stay connected long enough to get a mail message through! AMBAR ARPA: ambar@bloom-beacon.mit.edu UUCP:(get smail!): {mit-eddie,husc6,garp,bu-cs}!bloom-beacon!ambar
jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) (07/14/87)
Jean Marie Diaz <ambar@athena.mit.edu> writes:
... quite often these days, the ONLY way for me to get mail
to a given machine on the west coast is to route through ucbvax:
foo%decwrl.dec.com@ucbvax.berkeley.edu
This isn't a matter of us not "knowing" decwrl -- the
problem is that the net is so overloaded that we can't stay
connected long enough to get a mail message through!
WHOA ... let's hold on there for a minute. The reason that ucbvax
happens to have a good connection to decwrl is not because it's
"on the west coast" but rather that DEC pays for a dedicated PRIVATE
leased line between UCB and DEC ... normally sending mail to decwrl
via any other west coast ARPANET site will result in similar delays,
as decwrl.dec.com is on the NASA/Ames MILNET PSN, and is subject
to getting it's packets via an ARPANET/MILNET gateway ... in general,
routing through ucbvax is a bad idea ... especially for destinations
on MILNET, due to low processor bandwidth (it's a VAX-11/750 with
no cycles to spare).
Congestion on ARPANET is bad (MILNET sees much less congestion),
and the gateways are clearly overloaded, but let's not make things
worse by encouraging bad habits ...
/jordandiamant@hpfclp.HP.COM (John Diamant) (07/21/87)
Sorry for the late reply, but with net delay and my being out of the office for a week and a half, these things happen. >>> = Paul Vixie >> = John Diamant > = Paul Vixie again > >>>[Paul Vixie wonders why every host in a route-addr needs to be registered. >>>Suggests that it may be a political thing, because ARPA dislikes being >>>used as a transport for non-ARPA mail (that originates and terminates on >>>non-ARPA hosts).] >> [ some discussion about RFC-822 wording omitted] > >Still, I agree with your interpretation of RFC-822 in this respect. I guess >this IS a valid reason to use %@ instead of <@,:@>. But it seems like a >gratuitous restriction, for the reason I stated above. I agree. My understanding of the reason for the restriction was that the author of the RFC wanted to actively discourage use of source routes and expected them to be almost totally unnecessary. This hasn't happened yet, but because of his restrictions, they aren't very useful. > >The only routing syntax available in >the SMTP world is %@, apparently; if there is no standard that specifies "%", >then routes cannot be rewritten between UUCP- and SMTP-based networks, and >gateways between them will necessarily not be perfect. A catch-22! > >>Also, if a "%" came in and was translated to >>"!" and then left again, but was now as source route, then you've illegally >>applied an interpretation to it. > >The envelope address in the UUCP network should always have a pure !-route in >it (if it doesn't, then is still SHOULD :-)). When a gateway host gets a >message from its UUCP side, and detects that it needs to be forwarded to an >SMTP network, it can rewrite the envelope address as much as it wants to do. >The header address may be in normal, domain form, in which case it should be >left alone so that replies can use a new (and perhaps better) source route; if >the header addresses are in !-form, well, they aren't protected by RFC-822 >(the whole thing would be a local part), and can be re-written into the >routing syntax of the new network (SMTP, in this case). Agreed. It is SMTP -> UUCP where the problem occurs, I think. Regarding your comment about local part, I would say that is only true if it wasn't an RFC976 style address that was translated at an SMTP -> UUCP gateway already. > >The fact that SMTP doesn't have a routing syntax (route-addrs need registered >hosts only, and % is non-standard) stops this scheme in its tracks. Can we >bend or push either of those restrictions? I think there really is nothing forcing the source routing requiring registered domains except for the wording of RFC822. I don't think there is anything fundamental that would break if that were ignored. But realize that this requires a new RFC obsoleting RFC822 and explicitly allowing this before consistent acceptance of this could be obtained. See my comments above for an explanation of why the restriction came about (at least what I've heard). The problem with the % non-standard handling is that RFC976 hosts could be required to handle precedence as follows: "@", "!", anything else ("%"), but RFC822 hosts could not be expected to take "!" over "%." > >>I gave it a shot. What do you think now? This situation is deceptive. >>Scott McGregor (also of HP) and I tried to write an RFC to clarify this >>problem and we discovered the deeper we got, the more complicated the >>RFC got, and the worse the problem became. > >I think you're right about % being insufficient, and you seem to be right >about <@,:@> being insufficient, and I'm not sure what to suggest. Maybe >we can remove the registration restriction on route-addrs -- as I stated >way up there, it doesn't seem to be necessary (and it certainly isn't >helpful in this case!). Alternatively, an RFC that specified "%"/"@"/"!" >and their relationship to eachother would make "perfect" UUCP/SMTP gateways >possible. You can send me your unfinished RFC, if you think it will >enlighten me... When I find my most recent copy, I will send it by email. I don't think it is appropriate for wide distribution as it has several problems (that's why we stopped working on it -- we didn't seem to be getting closer to a solution). I'm not sure if it will help clarify things for you or confuse them more. However, I am coming into this discussion already having attempted to hash this out once before unsuccessfully (the attempted RFC) and am not overly confident. >-- >Paul A. Vixie, Esq. "A viler evil than to throw a man into a >paul%vixie@uunet.uu.net sacrificial furnace, is to demand that he >{uunet,ptsfa,hoptoad}!vixie!paul leap in, of his own free will, and that he >San Francisco, (415) 647-7023 build the furnace, besides." (Ayn Rand) >---------- Good quote ^ John Diamant TSBU UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
chris@mimsy.UUCP (Chris Torek) (07/24/87)
>In article <715@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >>It seems unnecessary, since nobody needs to reply to anyone in the middle of >>a route -- just the first. The others are relative. If they all have to be >>registered, then one assumes that every host will know how to get mail to >>them, and wouldn't need route-addrs. (This makes sense. An example: <@athena.mit.edu,@hiddengate,user@hiddenhost> The sending mailer need only be able to figure out the part between `<' and `,'; the fact that `hiddengate' and `hiddenhost' are not registered does not have to matter. Despite this, RFCnnn [fill in the n's] says it does.) In article <1130@bloom-beacon.MIT.EDU> ambar@athena.mit.edu (Jean Marie Diaz) writes: >Well, in the Arpanet world at least, that's a nice theory. But quite >often these days, the ONLY way for me to get mail to a given machine on >the west coast is to route through ucbvax: > >foo%decwrl.dec.com@ucbvax.berkeley.edu But since decwrl.dec.com *is* a registered domain name, you could use <@ucbvax.berkeley.edu:foo@decwrl.dec.com> >This isn't a matter of us not "knowing" decwrl.... If you were sending to an unregistered host, <@berkeley.edu:him@bouncy.ucb-test> would be officially illegal. Nonetheless it would probably work. The string him%bouncy.ucb-test@berkeley.edu would be legal. Why, then, is the <route-addr> version illegal? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
mcgregor@hpsmtc1.HP.COM (Scott McGregor) (07/27/87)
>(This makes sense. An example: > > <@athena.mit.edu,@hiddengate,user@hiddenhost> > >The sending mailer need only be able to figure out the part between `<' >and `,'; the fact that `hiddengate' and `hiddenhost' are not registered >does not have to matter. Despite this, RFCnnn [fill in the n's] says >it does.) That's correct. But now consider what athena.mit.edu needs to do. (The following does not represent opinion as to what *should* be done only an analysis of what *is* done in the Internet Community.) Athena must send to hiddengate. This is fine if we insist that hiddengate is a neighbor machine to athena. But the @ source routing in RFC 822 doesn't require that. It only says that the mail should travel through hiddengate on its way to hiddenhost. There may be other not specified hosts along the way between athena and hiddengate, and there may be multiple hosts between hiddengate and hiddenhost too. What if there are TWO machines called "hiddengate"? How does athena know which one to send to? To avoid this ambiguous possibility (which Unix users accept but which the Internet has constantly fought), Crocker "solved" it by defining which one to send to: namely the registered one. Since the Internet has a managed namespace there can be one and only one "hiddengate.???.???" site and the possibility of ambiguity is eliminated. Also note, that if hiddengate and hiddenhost are registered and for some strange reason the path to hiddengate is down, but there is an alternate path to hiddenhost, then some helpful mail administrator can clear their mail queue by rerouting your mail directly to hiddenhost. If you don't really care how the mail gets there then this will be a win for you. If you really did care that it went through hiddengate you also wouldn't care because of the lack of a path from athena to hiddengate (i.e. you'd recognize that you had asked for the impossible). If hiddengate and hiddenhost were NOT registered such a "helpful" action on the behalf of some intermediate mail administrator might actually cause MISDELIVERY of your mail. So having registered hosts allows more robust recovery from network mail problems, whereas duplicate unregistered mail can lead to undeliverable or misdelivered mail. >If you were sending to an unregistered host, > > <@berkeley.edu:him@bouncy.ucb-test> > >would be officially illegal. Nonetheless it would probably work. Yes, you are right, it would probably work (unless your mail happened to travel through some host that explictly filters out mail with unregistered hosts in it. ) Is there a chance that your mail might be mis-delivered? Sure, especially if rather than bouncy.ucb-test you have a name like "bilbo" that is more likely to have name conflicts. >The string > > him%bouncy.ucb-test@berkeley.edu > >would be legal. Why, then, is the <route-addr> version illegal? If you consider what the above discussion you can see that the first one would be subject to possible misdelivery whereas the latter is not. This is because the latter absolutely insists that the mail be given to berkeley and no helpful mail administrator should redirect it any otherway, while the former represents itself as being a registered address that is capable of redirected delivery if the path to berekeley.edu is blocked. > Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Everyone reading this note can decide on their own whether the benefits of enforced registration outweigh the benefits of avoiding %-style gateways. In fact each reader WILL decide on their own, and it has been my experience that there is little in terms of argument that can be done to bring all into agreement. Scott McGregor Hewlett-Packard Company