page@swan.ulowell.edu (Bob Page) (12/07/88)
brian@ucsd.edu (Brian Kantor) wrote: >'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. You should never edit a From: line. Never. Most sendmail sites add their hostname to the front of the From: line, which is wrong for two reasons: - address info is *not* routing info. - not everybody does it! That means you get lines like: From host5!host4!host3!host2!host1!host!user From: host4!host1!host!user >There is no quick fix. You have been warned. The 'smail' package fixes this errant sendmail behavior. However it requires that mail admins believe From: munging is a bad thing, which is damn near impossible. Also, the latest available version of smail has enough problems for sites with complex configurations. Maybe smail 3.0 fixes everything but I haven't seen it yet, and I don't know about the IDA sendmail patches. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
david@pacbell.PacBell.COM (David St.Pierre) (12/07/88)
brian@ucsd.edu (Brian Kantor) wrote: >'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. Um Brian, you're taking liberty with what I said. I didn't say I was doing the right thing - I did say that traditional System V mailers didn't attempt to support RFC822 and didn't really support "headers". System V behavior is to prepend a From_ to each message. That's it. That's what I do here. I understand that most sendmails rewrite the From: line - I don't really agree with that. I'd rather have a destination address and use pathalias. But that's a different discussion. When you get all those sendmails out there to support MX records (we're an MX record and a lot of mailers can't reach us), then I'll start getting concerned. But neither sendmail nor smail 3.x are my idea of a lot of fun. I use pathalias heavily and will re-route the next hop if I don't talk to them directly. Maybe an interim solution would be for ames to send all their uucp bounces to a site which uses pathalias and actively reroutes. Or hack another flag into sendmail (:-) to continually consolidate From_ lines. -- David St. Pierre 415/823-6800 {att,bellcore,sun,ames,pyramid}!pacbell!david
arnold@vdelta.volt.com (Dave Arnold) (12/08/88)
In article <10510@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > brian@ucsd.edu (Brian Kantor) wrote: >>'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. > > You should never edit a From: line. Never. Most sendmail sites > add their hostname to the front of the From: line, which is wrong for It seems to mean we are getting From: lines and From_ lines confused. RFC976 says that you *SHOULD* add your 'site' to the beginning of the From_ line. The From_ line is used for routing. It's part of the UUCP transport envelope.
henry@utzoo.uucp (Henry Spencer) (12/09/88)
In article <504@pacbell.PacBell.COM> david@pacbell.PacBell.COM (David St.Pierre) writes: >System V behavior is to prepend a From_ to each message. That's it. In fact, this considerably pre-dates System V, and RFC822 (although not its predecessors) as well. This is the *standard* mailer behavior for uucp mail, dating back to V7. Any mailer that can't cope with other mailers doing it has broken backward compatibility, a very stupid thing to do in this network. >... Or hack another flag into sendmail (:-) to >continually consolidate From_ lines. Actually, the only program that should ever consolidate From_ lines is the user agent at the receiver. Consolidation removes information, and should not be done gratuitously by relay sites. (We won't even mention that 4.1 and, I think, all its successors, have bugs in the consolidation code...) Alas, there are a lot of misguided mailers that do consolidation at the drop of a hat... -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
brian@ucsd.EDU (Brian Kantor) (12/10/88)
In article <504@pacbell.PacBell.COM> david@pacbell.PacBell.COM (David St.Pierre) writes: >Um Brian, you're taking liberty with what I said. I didn't say I was >doing the right thing - I did say that traditional System V mailers >didn't attempt to support RFC822 and didn't really support "headers". You're right, David, and I apologize for misquoting you - I must have some missing bits in the wetware. But as we discussed over a beer two days ago, the difficulties of combining two networks with essentially different addressing semantics make any definitive answer difficult to achieve. I hope your suggestion to ames helps this situation. (BTW, wasn't it nice of Sun and AT&T to pay for the drinks and munchies while we discussed this in person?) The key here is that the From: line in a uucp world is a strange beastie: it has no meaning to sites which run pure uucp mail. Yet this mail network is no longer pure uucp; even if it only used uucp as a transport mechanism, the thousands of sites using sendmail (even those not connected to the internet) are using internet semantics and we must, as a practical matter, cope with that. In the pure uucp world, there are no addresses, there are only paths. In the internet world, there are normally no paths, just addresses. When you mix these worlds together, you get problems, and to solve the problem you have to process the address according to the semantics which apply. Luckily, it is often possible to decide which is the correct set of rules, because the addresses/paths contain clues which most of the time will allow you to guess correctly whether what you are looking at is an address or a path. And that's what we do with From: lines, and that's what I advocate others to do with From: lines. Those who say that one should never touch the contents of a From: line would seem to be those who believe that the From: line always contains an address. Regrettably, that is not always true, and sometimes the From: line contains a path, which must, by definition, be updated. Brian Kantor UCSD Postmaster UCSD Office of Academic Computing UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu BRIAN@UCSD ucsd!brian
vixie@decwrl.dec.com (Paul A Vixie) (12/10/88)
[Kantor]
# Those who say that one should never touch the contents of a From: line
# would seem to be those who believe that the From: line always contains
# an address. Regrettably, that is not always true, and sometimes
# the From: line contains a path, which must, by definition, be updated.
I am one who has advocated leaving From: lines alone wherever possible, and
I find that I agree with this exception. The sendmail.cf running at UB.COM
and FAI.COM will assume that a From: line with only one "host/domain" in it
is an address and should be left alone, whereas something with more than one
"host/domain" is probably not an address, and is probably either hopelessly
screwed up because not everybody has updated it (in which case updating it
won't make it worse) or it has been correctly updated so far (in which case
updating it will still not make it worse). There are other details involved,
but that's the general approach. I havn't heard any complaints so far...
The trick is to leave them alone if they don't appear to have been dinked
with already. If everybody did that, they would never get dinked with at
all.
Except when passing through a network gateway, which breaks this whole
scheme into a million shards. Hopefully a fully domainized internet will
make most of the things we think of as "gateways" disappear either by
hiding the whole "other network" in a domain tree ("sxn@ingersoll.sun.com"
is on "another network" but I don't have to treat it that way), or by
hiding all recipients on the "other network" behind a generic domain name
(I'm not really "vixie@decwrl.dec.com" but you don't have to know 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 7013page@swan.ulowell.edu (Bob Page) (12/13/88)
brian@ucsd.edu (Brian Kantor) wrote: >Those who say that one should never touch the contents of a From: line >would seem to be those who believe that the From: line always contains >an address. I agree. The assumption is everything, right? :-) >Regrettably, that is not always true, and sometimes the From: line >contains a path, which must, by definition, be updated. When it leaves a site with a From: line of user, or host!user, are either of those an address or a path? I say an address. So host1 gets it and makes it host1!host!user. Is that an address or a path? I say it's a path. I also say it was wrong for host1 to assume it was a path when it got it. I still say leave it alone under all circumstances. There's no reason you should propagate someone else's error. Keep the path info in From_. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
henry@utzoo.uucp (Henry Spencer) (12/15/88)
In article <10670@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >>Regrettably, that is not always true, and sometimes the From: line >>contains a path, which must, by definition, be updated. > >When it leaves a site with a From: line of user, or host!user, are >either of those an address or a path? ... >I still say leave it alone under all circumstances. There's no reason >you should propagate someone else's error. Keep the path info in From_. I have to agree with this. The first and foremost principle of mail relaying is (should be!) what it says in the Hippocratic Oath: "First, Do No Harm". Corollary: it is much more important that mail relaying be predictable than that it be smart. The receiving and transmitting ends can always add smartness, but they can't restore lost predictability. Trying to guess whether a From: line is an address or a path violates both of these rules. It introduces unpredictable behavior, since by definition it's guesswork. And it has the potential to do major harm, because an address which is misinterpreted as a path will probably cause later sites to guess "path" too, resulting in an indecipherable mess in the situation (our current one) where some sites munge paths and some don't. The most predictable, and least harmful, approach is to prepend a new From_ line and leave From: alone. (Trying to stuff your site name into an existing From_ line rather than just prepending a new one is not as safe, but it's better than a lot of the alternatives.) -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu