vixie@decwrl.dec.com (Paul A Vixie) (12/04/88)
Since it is essentially on my advice that pacbell does what it does, I'd better answer this before David gets worried... Note the Followup-To: and please respect it. [Kantor] # Nearly every one of the bounced messages turns out to be a reply to mail # that passed through host 'pacbell' before it got to ames. 'pacbell' # doesn't add its sitename to the "From:" line in mail, but does add it to # the "From " line. # [...] # The system administrator at host 'pacbell' claims he's doing the right # thing. I think he's wrong. There it stands. And I think he's right. Is that as far as we're going to get? Some sites add their names to From: lines, some don't. All (uucp) sites add their names to From_ lines. Mailers that depend on being able to send back to a From: line will run into many RFC976-compliant mailers out there that leave it in "user@dom.ain" format -- so they'd better run routers of some kind -- and many other mailers that break a perfectly good "user@dom.ain" by prepending their hostname and a bang to it, thereby creating a mixed address. Third order effects of this are far and wide -- like mailers that try to "fix" mixed addresses for you, etc. My assertions on this topic: (1) smart mail user agents or mail user agents that can depend on a smart transport (that is: elm or any user agent that knows it's talking to smail) should reply to "From:" addresses, since they _are_ supposed to be addresses. (2) dumb user agents or any user agent that knows it's talking to a dumb transport should use the From_ retuyrn-path (since it _is_ a path). (3) mailer user agents that cannot be made to do the right thing should be fixed. (4) the non-gateway transports that modify "From:" addresses should be rm'd. (5) given that some transports modify "From:" and some do not, the direction we need to move toward is getting them all (except gateways) to _not_ modify "From:". -- 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
brian@ucsd.EDU (Brian Kantor) (12/05/88)
The point is that pacbell, like many many other uucp-world-only hosts, isn't running the standard sendmail mailer, nor a mailer which understands From: lines. The uucp standard is to use and update the "From " line, and since pacbell is a uucp-world-only site (for now, anyway), they don't see any need to do anything about what (to them) is a meaningless line in the header. And I can't fault them for their logic, only for their world view. My comment "there it stands" represents that Dave St. Pierre and I have agreed to disagree, not that no further words can be said on the subject. Since we at UCSD gateway between uucp, bitnet, span, and the internet, and thus live in the uucp, decnet, and RFC822 worlds, the way we handle From: lines is somewhat complicated, but the relevant part is: if the From: line has an '@domain' in it, leave it alone, else if the mail is going out via uucp, then prepend 'ucsd!' to it. else append '@ucsd.edu' to it. There are additional rules having to do with hiding local campus machine names, and other network vagaries, but you get the idea. I think this does the most practically-correct thing, rather than hope for some change to a massive base of installed software that is already mostly compliant to RFC822. Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu ucsd!brian BRIAN@UCSD
vixie@decwrl.dec.com (Paul A Vixie) (12/05/88)
I think we will end up agreeing to disagree. As I understand pacbell's mailer, it is not quite "standard uucp-world-only". They run smail. Smail does the "right" thing according to RFC976, which is: don't mess around with From: lines unless you are acting as a gateway. Since the "From_" line has the information in it, it makes a lot of sense to leave the "From:" line in its original form, hoping that it was modified by the gateway into "your" domain such that if you can get it back to that gateway, the gateway can get it back to the sender on the "other side". Of course, this doesn't mention or deal with "Cc:" or "Reply-To:", but let's not muddy the waters all at once. I can see the reasoning behind your "From:" modification strategy, and I could even argue in favor of it with very little provocation. One thing to keep in mind when thinking about heterogeneous mail networks is that although there are many "wrong" ways to do something, there is no single "right" way. My "right" way is to do for the most part what the RFCs can be read as suggesting, and hoping that any inconvenience I cause by doing so will cause either greater compliance to existing RFCs or new RFCs. Getting my own mail delivered takes precedence over this, of course :-) -- meaning that if breaking an RFC is the _only_ way to get mail to stop bouncing, I grit my teeth and pull out the hacksaw. I prefer to yell at the admins of offensive sites, though, and maximizing my compliance with RFCs tends to strengthen my position when I have to do that. -- 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
brian@ucsd.EDU (Brian Kantor) (12/06/88)
The crux of the matter is that RFC976 is a Request for Comment. I have commented upon it; I think its treatment of the From: line processing is wrong. My comment has had the resounding impact of a feather on a snowbank: no one has claimed that I was misguided, no one has said "right on" either. I think it's time to review RFC976 carefully and issue a revised version. The From: line stuff isn't the only flaw in it, but it is, in my opinion, the most harmful error in the RFC. As a minor note, we're in the process of revamping RFC977 (NNTP) as well, since experience has proven that we blew it in a couple of places. No matter that it took us over a dozen drafts, over six months, and had input from and were reviewed by MANY news gurus. Stepwise refinement, I think they call it. I refer to it as "trial and error". Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu ucsd!brian BRIAN@UCSD
dg@lakart.UUCP (David Goodenough) (12/06/88)
From article <VIXIE.88Dec3171712@bacchus.pa.dec.com>, by vixie@decwrl.dec.com (Paul A Vixie): > Since it is essentially on my advice that pacbell does what it does, .... > [Kantor] > # Nearly every one of the bounced messages turns out to be a reply to mail > # that passed through host 'pacbell' before it got to ames. 'pacbell' > # doesn't add its sitename to the "From:" line in mail, but does add it to > # the "From " line. > # [...] > # The system administrator at host 'pacbell' claims he's doing the right > # thing. I think he's wrong. There it stands. > > And I think he's right. Is that as far as we're going to get? > > Some sites add their names to From: lines, some don't. A world first :-) :-) :-) I agree with Mr. Vixie. I agree that the From line should be altered by sites that got the stuff along the way, but the From: line should be left alone. If this were the case (TAKE NOTE xait.xerox.com) then my conversations with servers on the Internet would be a lot less painful, and xait would be bouncing a lot less mail. Since servers tend to use the From: line, and I go in and manually add the correct From: line (From: dg%lakart.uucp@harvard.harvard.edu) If it were left alone, then everything would be fine. As it is, things wind up addressed to xait!dg%lakart.uucp@harvard.harvard.edu which becomes: xait!lakart!xait!dg Can you cay OOPS. I'd use lakart!dg@harvard.harvard.edu, but have you any idea how fragile a ! is in a return path with a @ in it as well ..... -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@harvard.harvard.edu +---+
werner@utastro.UUCP (Werner Uhrig) (12/06/88)
> My "right" way is to do for the most part what the RFCs ...[say] ..
I don't care about who's right and who's wrong. If it's broken
and causes mail or replies to mail not to get through, then
it's time to find a fix... and it would be best if all cooperate
and not insist on right or wrong.
I know for a long time that there is some kind of trouble "near"
ames and if it is not the fault of "ames" but of someone else
(pacbell?) then the folks at ames could do us all a favor and
not handle mail from pacbell anymore....
FCOL .... (for crying out loud)
--
--------------------> PREFERED-RETURN-ADDRESS-FOLLOWS <---------------------
(ARPA) werner@rascal.ics.utexas.edu (Internet: 128.83.144.1)
(INTERNET) werner%rascal.ics.utexas.edu@cs.utexas.edu
(UUCP) ..!utastro!werner or ..!uunet!rascal.ics.utexas.edu!wernerpeter@ficc.uu.net (Peter da Silva) (12/06/88)
Perhaps RFC976 needs a Path: line, which everyone diddles, and a From: line, which only gateways diddle. As a further refinement, if the gateway knows how to get to the existing From: line, it might be advisable for it to clear the Path: line, or add a new empty one. That way you can use the Path: line (if needed) to get to the gateway, and trust the gateway to get it back past that. Only if the gateway can't get back to the original machine should it migrate the Path: line into the From: line. I hink this should cover most everything... -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.net
randy@cctb.mn.org (Randy Orrison) (12/07/88)
In article <2379@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: |Perhaps RFC976 needs a Path: line, which everyone diddles, and a From: |line, which only gateways diddle. Why should gateways mess with the from line? One specific 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? IMVHO: NO ONE should touch the From: header at all. I'll put my address in there when I send mail, and nobody knows better than I what my address is. If the receiving site doesn't know where to send mail for .mn.org to, that's THEIR problem (they haven't been paying attention to the maps). A Path: header is a nice idea to help people with problems like that, but a better idea is for them to set their stuff up correctly. (What? You don't get the maps? Neither do I. I don't have any problems.) -randy -- Randy Orrison - Chemical Computer Thinking Battery - randy@cctb.mn.org (aka randy@{umn-cs.uucp, ux.acss.umn.edu, umnacvx.bitnet, halcdc.uucp}) "Blow a lawyer to pieces / It's the obvious way Don't wait for a thesis / Do it today" - Al Stewart
dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/08/88)
In article <152@cctb.mn.org> randy@cctb.UUCP (Randy Orrison) writes: >Why should gateways mess with the from line? Gateways don't know how much you know about the originating network, so they mangle the From: header. If domains such as .BITNET and .DECNET were recognized by Internet software, most of this mangling would no longer be needed. What we really need are Originally-From: and Originally-To: headers that nobody, not even gateways, will ever, ever change. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
dtynan@sultra.UUCP (Der Tynan) (12/09/88)
In article <4999@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > > If domains such as .BITNET and > .DECNET were recognized by Internet software, most of this mangling would > no longer be needed. > > Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi Ah yes, but as stated many times before, .BITNET and .DECNET (and, for that matter, .UUCP) are not domains. The NIC *does not* want any domains which are specific to certain network types. - Der -- dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!Tynan.COM!dtynan --- If the Law is for the People, then why do we need Lawyers? ---
vixie@decwrl.dec.com (Paul A Vixie) (12/10/88)
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
batie@agora.UUCP (Alan Batie) (12/13/88)
In article <152@cctb.mn.org> randy@cctb.UUCP (Randy Orrison) writes: >In article <2379@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >|Perhaps RFC976 needs a Path: line, which everyone diddles, and a From: >|line, which only gateways diddle. > >Why should gateways mess with the from line? Because you don't want to see addresses like: vms-gateway::"uucp!bang!path" appearing on your system. I'm trying to set up a mail gateway that will do the "right thing" in dealing with mail from stock VMS (system::user), BSD Unix, stock Xenix (which uses delimiters for transport selection, i.e. any of "system:user", "system%user", "system@user" or "system!user", depending on the communication link), and whatever else someone decides to hook into our network. It ain't pretty... -- Alan Batie +1 503 640-4013 batie@agora.hf.intel.com "He was born on third base... tektronix!tessi!agora!batie and thought he hit a triple"