Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucsfcgl.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!whuxlm!harpo!decvax!ucbvax!ucsfcgl!gregc From: gregc@ucsfcgl.UUCP (Greg Couch%CGL) Newsgroups: net.mail Subject: parsing uusite!local@domain-spec - a partial solution Message-ID: <423@ucsfcgl.UUCP> Date: Wed, 9-Jan-85 03:59:12 EST Article-I.D.: ucsfcgl.423 Posted: Wed Jan 9 03:59:12 1985 Date-Received: Fri, 11-Jan-85 23:47:35 EST Organization: UCSF Computer Graphics Lab Lines: 83 How to generate uucp return addresses from the RFC 822 world The basic problem: People want to use the RFC 822 domain addressing standard for all mail addressing. Most unix sites support uucp mail and many now support the RFC scheme as well. Return addresses given to uucp sites are often generated assuming that the uucp site doesn't know about RFC 822, which leads to an ambiguity when the uucp site does try to follow RFC 822. The return addresses is often generated as uusite!local@domain-spec. It is parsed, ()'s for grouping: uusite!(local@domain-spec) by uucp-only sites (wanted behavior) (uusite!local)@domain-spec by RFC 822 sites - RFC 822 overrides (i.e. uusite!local is the local part) Return addresses need to be generated without assuming that uucp sites know or don't know about RFC 822. The only solution which is compatible with uucp and RFC 822 is not to give uucp sites addresses with @'s in them. I am proposing the following syntax for uucp return addresses from RFC conforming machines: uusite!domain-spec!local e.g. ucsfcgl!Berkeley.Arpa!gregc or ucsfcgl!ucsfmis.ucsf!gregc (local top level domain) or ucsfcgl!gregc (no domain-spec) Why this particular syntax? It is a normal uucp address up to the first !. It's a RFC 822 conforming address (all local). It preserves the locality of the orignal local part. ! is already special, why use another character? It avoids any problems a different special character would create since it may mean something special to some other site. It's easy to reconstruct the domain address. It doesn't break uucp mail. It appears to be what usenet uucp-mail project has decided upon (we will know soon, I hope). What this fixes: Uucp return addresses are legal for both uucp-only sites and RFC conforming sites. What this breaks: It may break sites that try to shorten chains of uucp addresses. Sites that use . as a special character with higher precedence than !. Any other program that parses uucp mail addresses as site!site!.... What this doesn't fix: The RFC 822 routing syntax isn't handled correctly, since routes can have more than one @. The hack solution is to strip routing information until only one @ is in the address and hope that is a good enough (should be, but...). Uucp routing isn't solved. Mail that goes through sites that don't munge the From: and To: fields to RFC conforming site will still cause the mail to be unreplyable to. In short: This proposal is only for generating return addresses for consumption by uucp, it is not a general solution of mail addressing problems. It is designed for backward compatibility with uucp-only sites, but at the same time, for compatibility with sites that are switching to the RFC notation. I have a generic uucp/ethernet sendmail.cf file with this implemented and tested, if anyone would like a copy, just send me mail. Comments to: Greg Couch ucbvax!ucsfcgl!gregc ucsfcgl!gregc@Berkeley.Arpa gregc@ucsfcgl.Arpa (as soon as we're published)