Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!mailrus!husc6!purdue!decwrl!vixie From: vixie@decwrl.dec.com (Paul A Vixie) Newsgroups: comp.mail.uucp Subject: Re: "From:" vs. "From_" Message-ID: Date: 10 Dec 88 07:52:00 GMT References: <1297@ucsd.EDU> <1299@ucsd.EDU> <2379@ficc.uu.net> Sender: vixie@decwrl.dec.com Organization: DEC Western Research Lab Lines: 81 In-reply-to: peter@ficc.uu.net's message of 6 Dec 88 12:57:54 GMT Three-in-one special today: [de Silva] # Perhaps RFC976 needs a Path: line, which everyone diddles, and a From: # line, which only gateways diddle. That is easily the best header enhancement idea I've heard in quite some time. There are people around who want to update RFC976; I hope one or more of them sees this. There should be a way for smart agents to find their own way back to the sender, and for dumb ones to go back along the original path. Since not all MTA/MUA interfaces preserve the envelope sender address and even if they did it is not guaranteed to be in any particular format, some kind of "Return-Path:"-like entity inside the headers looks like a good idea. The RFC976++ crowd ought to plan on something that will address this hetero- geneous, chaotic, anarchic mess we call a "network" in its real form with all the unregistered sites, all the non-standard and incompatible syntaxes &etc. If you start now and finish before 1995, you will still beat the X.400 design people by five years and you will have something that people will actually _use_ instead of another design-by-committee, ivory-tower lamp-post that we can all glance at on our way to whatever we _really_ do every day. I'm not volunteering, just kibitzing. [Orrison] # counter-example: If I receive mail from a bitnet site at my "internet" # site, I just want "joe@site.bitnet" because I've got a good, close, # bitnet gateway that probably wasnt used when the mail came to me. Why # should whatever gateway it came through on the way to me assume that it # has to go back the same way? A good question with a sad but simple answer: .BITNET isn't on the list of approved top-level Internet domains. Put another way: you may know a way to get back to .BITNET, but I don't think there's a *.BITNET "MX" record in the core name servers and I think Jon Postel likes it that way. Since you are on the Internet you have to take the lowest common denominator, which is that a gateway between a non-internet site and an internet site has to dink the From: line such that the prototypical "average" internet site will be able to "reply" to the message with no special intelligence. The UUCP map has entries for .BITNET and, for that matter, .UUCP. But those are just not going to make it into the core name servers, ever. Both of these networks are collapsing into internet subsets with oddball transport media -- it is common for BITNET and UUCP sites to have internet names, which means that in what Dr. Reid likes to call the "fullness of time", you won't have to see .UUCP or .BITNET and will be able to treat all hosts identically since they will all have internet domain names. There is nothing keeping you from peeking ahead in locally-generated or locally received mail and saying, in effect, "ah, this came from .BITNET and I'm going to short-circuit the route". Please don't do this to pass- through mail, though. [rja@edison] # If BITNET and DEC were to convert to the domain-name standard that is # now used world-wide, none of that mangling would occur. BITNET is changing over to use internet domain names. They told me that they were something like 1/3 or 1/2 done and expected 90% conversion by 1990. Most BITNET sites are IBM and VMS, neither of which are known for being willing to update their software very often. 1990 is _quick_, in other words. DEC, on the other hand, already puts their internal easynet mail into internet domain name format when it passes through the decwrl.dec.com gateway. If you see a From: line like "user@host.DECNET", that was done by some random DEC customer who didn't know how to set up their sendmail.cf file to rewrite things that came from the Mail-11 side into something that the Internet side would find palatable. Unfortunately, DEC doesn't offer a great deal of help to customers who want to do this kind of thing. ***As always, I am not speaking as a DEC employee! I don't set or ** publicize DEC policy in this or any area! All opinions are my own, ** do not reflect corporate policy! I don't even _know_ what corpor- ** ate policy is in this area! *** -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013