vixie@palo-alto.DEC.COM (Paul Vixie) (08/06/88)
[ By the way, I'm sure Sun is grateful for my decision. They pass an awful lot of mail for free there, and they don't need my traffic at all. ] I ran a test tonight to see how Sun.COM's MTA was behaving. The results are unsurprising. I sent three messages from my home machine, vixie.UUCP, to myself on decwrl.dec.com. I used this path in all three: pacbell!sun!decwrl!vixie. I edited the messages in the UUCP spool directory before they were sent to pacbell, so I could try several different "From:" lines. The original text of the "From:" line is duplicated in the "Subject:" line -- luckily, Sun.COM does _not_ rewrite "Subject:" lines -- yet :-). Note that in all three cases, the "Return-Path:" header has the correct contents. (For those not in the know, Return-Path: is where MH puts the UUCP From_ line.) A value of "sun!pacbell!vixie!paul" is correct because this is in fact an exact reverse of the route the message took to get here. Note also that the "To:" line is in its original form, which is correct. Many MTAs incorrectly strip their own name out of the To: header; one can probably assume that if "sun!" had been on the front of the "To:" value, it would have been stripped. Since it was hiding behind a "pacbell!", it was safe. :::::::::::::: inbox/140 :::::::::::::: Return-Path: sun!pacbell!vixie!paul Received: from SUN.COM by decwrl.dec.com (5.54.5/4.7.34) id AA17907; Fri, 5 Aug 88 20:33:51 PDT Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA11577; Fri, 5 Aug 88 20:31:54 PDT Received: from pacbell.UUCP by sun.Sun.COM (4.0/SMI-4.0) id AA07135; Fri, 5 Aug 88 20:35:22 PDT Received: by vixie.UUCP (5.51++/smail2.3/02-18-87) id AA12696; Fri, 5 Aug 88 19:12:47 PDT Message-Id: <8808060212.AA12696@vixie.UUCP> To: pacbell!sun!decwrl!vixie Subject: test, From: line in @ notation (From: paul@vixie.uu.net) Date: Fri, 05 Aug 88 19:12:42 PDT From: Paul A Vixie <sun!vixie.uu.net!paul> --- This first one is replyable, though for a strange reason. decwrl would send it to "sun!" who would see "vixie.uu.net!" and say "ah, uunet.uu.net is the MX for *.uu.net, so I'll send it to uunet.uu.net who will deliver it further." The message didn't come through uunet to get to decwrl; why should it have to go back that way? If decwrl were running a passive router, the message would still have to go to "sun!" since passive routers (as I define the term) will only route to the first host/domain in a path. Perhaps hosts like Sun.COM are the reason why hosts like Rutgers.EDU exist? (Rutgers is an active rerouter, it will start on the right end of a path and route to the first thing it recognizes; this is evil and rude, as I explained yesterday). :::::::::::::: inbox/141 :::::::::::::: Return-Path: sun!pacbell!vixie!paul Received: from SUN.COM by decwrl.dec.com (5.54.5/4.7.34) id AA17905; Fri, 5 Aug 88 20:33:51 PDT Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA11571; Fri, 5 Aug 88 20:31:48 PDT Received: from pacbell.UUCP by sun.Sun.COM (4.0/SMI-4.0) id AA07126; Fri, 5 Aug 88 20:35:15 PDT Received: by vixie.UUCP (5.51++/smail2.3/02-18-87) id AA12667; Fri, 5 Aug 88 19:09:42 PDT Message-Id: <8808060209.AA12667@vixie.UUCP> To: pacbell!sun!decwrl!vixie Subject: test, From: line in @ notation (From: paul@vixie.UUCP) Date: Fri, 05 Aug 88 19:09:37 PDT From: Paul A Vixie <sun!vixie!paul> --- This message is unreplyable. This is why I have "-d sun" in my makepaths script. I can't fault Sun.COM for rewriting u@h.UUCP to h!u since they mean the same thing; adding "sun!" to the front of the result is just plain wrong and there is no modern defense for the practice. :::::::::::::: inbox/142 :::::::::::::: Return-Path: sun!pacbell!vixie!paul Received: from SUN.COM by decwrl.dec.com (5.54.5/4.7.34) id AA17906; Fri, 5 Aug 88 20:33:51 PDT Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA11574; Fri, 5 Aug 88 20:31:52 PDT Received: from pacbell.UUCP by sun.Sun.COM (4.0/SMI-4.0) id AA07131; Fri, 5 Aug 88 20:35:19 PDT Received: by vixie.UUCP (5.51++/smail2.3/02-18-87) id AA12677; Fri, 5 Aug 88 19:10:23 PDT Message-Id: <8808060210.AA12677@vixie.UUCP> To: pacbell!sun!decwrl!vixie Subject: test, From: line in ! notation (From: vixie!paul) Date: Fri, 05 Aug 88 19:10:20 PDT From: Paul A Vixie <sun!vixie!paul> --- See comments from #141. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
david@ms.uky.edu (David Herron -- One of the vertebrae) (08/07/88)
In article <3703@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: >I ran a test tonight to see how Sun.COM's MTA was behaving. The results >are unsurprising. Yeah, but none of the results came up with vixie!paul@sun.com like you claimed it would ... hmmm I'm not real sure how the mail got from sun to decwrl. In all the cases the Received: line has full.domain.names for both sun and decwrl, something which I assume would happen only when it's being delivered over the internet. But the From: and To: lines are in bang format, something I would expect for mail delivered over a uucp link. Perhaps sun is putting a sun.com in the From_ lines of uucp mail? Oh, MH may put uucp routes into Return-Path:. What it's *really* for is in the SMTP protocol, for recording the path the message took through the network. When a message arrives at some place with SMTP you add your own hostname to the Return-Path: line. So, in the general case, Return-Path: means the return-path in the 'envelope'. For UUCP mail the 'envelope' is the From_ line(s) and the command line given to rmail. (forward-path). >Return-Path: sun!pacbell!vixie!paul >Subject: test, From: line in @ notation (From: paul@vixie.uu.net) >From: Paul A Vixie <sun!vixie.uu.net!paul> > >--- >This first one is replyable, though for a strange reason. decwrl would send >it to "sun!" who would see "vixie.uu.net!" and say "ah, uunet.uu.net is the >MX for *.uu.net, so I'll send it to uunet.uu.net who will deliver it >further." The message didn't come through uunet to get to decwrl; why >should it have to go back that way? Why are you surprised at this? Maybe you haven't read rfc976? Though I'd be surprised if you hadn't. Anyway, this is a classic case of garbage-in garbage-out. You told it to do something (i.e. that you're part of the uu.net domain) so it's merely doing the right thing for what it knows. If you were to advertise in the uucp maps that you are the gateway for vixie.uu.net, AND your mailer is ready to accept vixie.uu.net as an alias for itself, THEN sun would know some path which merely went through the bay area and would reach you. >Return-Path: sun!pacbell!vixie!paul >Subject: test, From: line in @ notation (From: paul@vixie.UUCP) >From: Paul A Vixie <sun!vixie!paul> > >--- >This message is unreplyable. This is why I have "-d sun" in my makepaths >script. I can't fault Sun.COM for rewriting u@h.UUCP to h!u since they >mean the same thing; adding "sun!" to the front of the result is just >plain wrong and there is no modern defense for the practice. If they are running a passive re-router then it would be replyable. I do not know what they are running, but passive re-routing (to use your terms) is simple to put up -- even under sendmail :-) -- and does wonders for the usability of the system. I agree that simply prepending sun! to a From: line is *wrong*. emory used to (still does?) get this very wrong ... They'd prepend emory! to the beginning of From: & To: lines which went out via uucp. So we'd end up with messages From: emory!speck@arizona.edu (I forget the exact address, but it was Don Speck I think ...). -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Looking forward to a particularly blatant, talkative and period bikini ...
wisner@killer.DALLAS.TX.US (Bill Wisner) (08/08/88)
According to RFC822, the Return-Path header is added by the final mailer that delivers the message to its recipient. It's supposed to contain definitive information about the route back to the originator. It's not supposed to appear in a message until the very end of that message's travels. It's not supposed to be added to as a message wends its way through the network. The only MTS I know of that handles this correctly is Smail 3.1, which puts a copy of the From_ line into a Return-Path line if a message is being delivered by the "local" transport. There is a compile-time option to MH that makes it transform From_ lines into Return-Path lines.
vixie@palo-alto.DEC.COM (Paul Vixie) (08/08/88)
In article <10139@g.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: # In article <3703@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: # >Return-Path: sun!pacbell!vixie!paul # >Subject: test, From: line in @ notation (From: paul@vixie.uu.net) # >From: Paul A Vixie <sun!vixie.uu.net!paul> # > # >--- # >This first one is replyable, though for a strange reason. decwrl would send # >it to "sun!" who would see "vixie.uu.net!" and say "ah, uunet.uu.net is the # >MX for *.uu.net, so I'll send it to uunet.uu.net who will deliver it # >further." The message didn't come through uunet to get to decwrl; why # >should it have to go back that way? # # Why are you surprised at this? Maybe you haven't read rfc976? Though # I'd be surprised if you hadn't. Anyway, this is a classic case of # garbage-in garbage-out. You told it to do something (i.e. that you're # part of the uu.net domain) so it's merely doing the right thing for # what it knows. Nope. If something comes in from the outside in user@dom.ain format, RFC82{1/2} says that the "dom.ain" part must be registered with the NIC. Therefore it makes no sense to rewrite into "sun!dom.ain!user" UNLESS THE MESSAGE IS GOING INSIDE SUN'S INTERNAL NETWORK and even then it's of questionable value. user@dom.ain is replayable on its own, I tell you! RFC82{1/2} _demands_ that it be replyable on its own. One could charitably assume that Sun.COM sees the bang-path in the "To:" or envelope recipient and decides that it is gatewaying between two different networks -- except that the message _came in_ from the same network it would be leaving on: UUCP. What's actually going on is that Sun.COM doesn't run IDA or any other variant of Sendmail that lets you rewrite the envelope differently than you rewrite the headers. They don't see this problem as important enough to justify the extra headache of not doing unto the "From:" line as they do to the "From_" line. Pfaa. I obviously disagree. I could almost make a case for them rewriting "vixie!paul" into "sun!vixie!paul" since the next site in the path might not know what "vixie!" means. But they could at least see if Sun.COM (itself!) knows what "vixie!" means, since they are _mandating_ that the reply come back through them. # >Return-Path: sun!pacbell!vixie!paul # >Subject: test, From: line in @ notation (From: paul@vixie.UUCP) # >From: Paul A Vixie <sun!vixie!paul> # > # >--- # >This message is unreplyable. This is why I have "-d sun" in my makepaths # >script. I can't fault Sun.COM for rewriting u@h.UUCP to h!u since they # >mean the same thing; adding "sun!" to the front of the result is just # >plain wrong and there is no modern defense for the practice. # # If they are running a passive re-router then it would be replyable. # I do not know what they are running, but passive re-routing (to use # your terms) is simple to put up -- even under sendmail :-) -- and # does wonders for the usability of the system. True, _if_ they ran a passive router, the message would be replyable and I would not be bitching as loudly as I am. They don't. The message is not replyable -- "sun!" bounces it on the way back through. Note that running a passive router doesn't make it okay to rewrite headers that don't belong to you; it just makes the crime less heinous (sp?). The only time when the header sender or recipient can be correctly rewritten is when the message is crossing the boundary between one network and another -- and that is decidedly not the case here. # I agree that simply prepending sun! to a From: line is *wrong*. The implication is that rewriting into a homogenous form and adding one's host name in that form would be okay -- and it's not. That is, rewriting vixie!paul into sun!vixie!paul or paul@vixie.uucp into paul%vixie@sun.com is no better than rewriting vixie!paul into vixie!paul@sun or paul@vixie.uucp into sun!paul@vixie.uucp In _neither_ case is it okay to mess around with the header addresses AT ALL. They can do this if the message is bound for BITNET or the inside of their own network; they cannot do this when the message is passing from one Internet site to another with Sun.COM as simply an intermediary. The assumption is that if it comes in over UUCP or is going out over UUCP then it's not Internet traffic. This is false. UUCP is one of several common transport mediums over with Internet mail can flow. So by all means, do unto the envelope sender and recipient what you must do to make the message palatable to the medium it's going out over. But please leave the header sender and recipients alone! (Unless you're a gateway, as I said.) -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013
david@ms.uky.edu (David Herron -- One of the vertebrae) (08/08/88)
Paul, I think we really do agree (now that we've iterated the argument
a couple of times) ... Possibly there's a slight disagreement over exactly
when it's kosher to rewrite things and when it's not. But then the system
I oversee *is* a gateway between uucp/bitnet/internet. I view my internal
network as not being part of the internet and EVERY piece of mail which
comes from the outside has to be converted to proper rfc82{2,1} format.
But then MMDF makes that real nice to because it does such a good
job at rewriting headers and keeping envelope information seperate
from header information.
I am curious why nobody from Sun is here defending their honor.
Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail
configuration there?
I tried a test message to you at vixie!paul@sun.com just to see what
would happen. Here's the result:
Oh well. I had a higher opinion of the people at sun... A place
that can make a >$1 billion company off of 4.3bsd (not to mention
become a major player in the computer biz) *ought* to have better
talent than this in their e-mail department.
] Received: from e.ms.uky.edu by g.ms.uky.edu id ad09659; 7 Aug 88 22:16 EDT
] Received: from sun.com by g.ms.uky.edu id aa26747; 7 Aug 88 11:13 EDT
] Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0)
] id AA21400; Sun, 7 Aug 88 09:13:59 PDT
] Received: by sun.Sun.COM (4.0/SMI-4.0)
] id AA17601; Sun, 7 Aug 88 09:17:24 PDT
] Date: Sun, 7 Aug 88 09:17:24 PDT
] From: Mail Delivery Subsystem <MAILER-DAEMON@SUN.COM>
] Subject: Returned mail: Host unknown
] Message-Id: <8808071617.AA17601@sun.Sun.COM>
] To: david@ms.uky.edu
] MMDF-Warning: Parse error in original version of preceding line at e.ms.uky.edu
]
] ----- Transcript of session follows -----
] bad system name: vixie
] uux failed ( 68 )
] 550 <vixie!paul>... Host unknown
]
] ----- Unsent message follows -----
] Return-Path: <david@ms.uky.edu>
] Received: from Sun.COM (sun-arpa) by sun.Sun.COM (4.0/SMI-4.0)
] id AA17599; Sun, 7 Aug 88 09:17:24 PDT
] Received: from g.ms.uky.edu ([128.163.128.7]) by Sun.COM (4.0/SMI-4.0)
] id AA21397; Sun, 7 Aug 88 09:13:47 PDT
] Date: Sun, 7 Aug 88 12:13:02 EDT
] From: David Herron E-Mail Hack <david@ms.uky.edu>
] To: sun!vixie!paul@ms.uky.edu
] Subject: this is a test
] Message-Id: <8808071113.aa04242@g.g.ms.uky.edu>
]
] to see if I can send mail to a supposedly unmailable route
] --
] <---- David Herron -- The E-Mail guy <david@ms.uky.edu>
] <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
] <----
] <---- Looking forward to a particularly blatant, talkative and period bikini ...
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<----
<---- Looking forward to a particularly blatant, talkative and period bikini ...bill@ssbn.WLK.COM (Bill Kennedy) (08/08/88)
In article <5124@killer.DALLAS.TX.US> wisner@killer.DALLAS.TX.US (Bill Wisner) writes: >[ explanation of Return-Path According to RFC822 ] > >The only MTS I know of that handles this correctly is Smail 3.1, >which puts a copy of the From_ line into a Return-Path line if a >message is being delivered by the "local" transport. Has anyone seen smail 3.1? I was able to find 3.0 in killer's archives but it appears not to be any substantial change over 2.5. The dates and version numbers are the same as 2.5 anyway. This Return-Path looks like a nice new wrinkle. It also looks like something worth adding into the "reply" function of something like Berkeley mail. What are the new features of smail 3.1? Where can we get it? Is it worth having smail look for "Return-Path" instead of re-routing if the last site!user is the same as the one in the From:? Don't shudder too hard on the last one, I know the snake population and depth of that pit :-) -- Bill Kennedy usenet {killer,att,rutgers,sun!daver,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM
nowicki%rose@Sun.COM (Bill Nowicki) (08/09/88)
In article <10141@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > I am curious why nobody from Sun is here defending their honor. > Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail > configuration there? Sure, we are home, but only have time to deal with Usenet flames about once a week. Most time is spent supporting paying customers. :-) I realize that some people will NEVER be satisfied, but please try to understand the problem from both sides. We rewrite "From: sitename!user" into "From: sitename!user@Sun.COM" because we want to comply with the Internet standards for domain names. "sitename!user" is NOT a valid domain name, nor is "user@sitename.UUCP". The primary standard that we support is the domain name system, and if you use proper domain names then the From: line should not normally be touched. However, all our internal names are converted into domain format, and we have several gateways to the outside world to hide internal complexity, so sometimes even if it LOOKS like a message is sent from UUCP to UUCP, it often gets converted into domain format and then back out again. > I tried a test message to you at vixie!paul@sun.com just to see what > would happen. It is not suprising. We run standard (now System Vr3) UUCP software, and do not do any routing of UUCP names. So any mail to site!user@Sun.COM will only work if the site is a direct UUCP neighbor. I have requested that we be taken out of the "d.Top" file as a top-level domain router, in case that will help. We already forward several thousand mail messages per day between UUCP and the Internet, so would not mind at all the reduction in traffic. Unfortunately your claim that "all rewriting of From: lines is wrong" is not correct unless EVERYONE is doing UUCP routing. For example, consider: siteA --uucp--> sun --uucp--> siteB The From: line starts out as "From: siteA!user", and we rewrite it as "From: siteA!user@Sun.COM", which then gets rewritten going out as "From: sun!siteA!user". The flamers are saying this is "RUDE". But if we did NOT do it, then when the recipient at siteB replied to the message, it would fail unless siteB were running UUCP routing software. Since the standard UUCP software from AT&T (AND BERKELEY!!) DOES NOT support UUCP routing, this is usually not the case. Thus we try to be conservative, so that the recipient can reply if they do UUCP routing or not. Since almost all of our mail is either directly to us, or relayed through one hop, or relayed from all machines that rewrite the header (i.e. standard Sun-issue software), we chose to have a policy that causes these paths to generate replyable headers. As you discovered, if you are NOT a direct UUCP neighbor of Sun, but instead relay through a site that does NOT rewrite, e.g.: siteA --uucp--> siteB --uucp--> sun --Internet--> siteC Then our scheme breaks down. My response is that "siteB" is at fault, since it did not rewrite the From: line as "siteB!siteA!user". If it did, then replies would work fine. Another solution would be for siteA to use a different path to the Internet. We could just reject mail relayed through these "non-rewriting" sites, and just do it for neighbors. Of course, we could also install the UUCP routing software, but so far nobody has had the time to test, maintain, and document it. If you can convince AT&T or Berkeley to put it in their releases, it might help the situation. Remember: just because YOU might run UUCP routing software, it does not imply that everyone else is. -- Bill Nowicki Sun Microsystems (nothing official, of course, just personal opinions)
david@ms.uky.edu (David Herron -- One of the vertebrae) (08/09/88)
In article <63372@sun.uucp> nowicki%rose@Sun.COM (Bill Nowicki) writes: >In article <10141@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >> I am curious why nobody from Sun is here defending their honor. >> Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail >> configuration there? >Sure, we are home, but only have time to deal with Usenet flames about >once a week. Most time is spent supporting paying customers. :-) uh, well, goshy gee whillickers. I look around the cs dept and see a *few* Sun's so we must be paying customers ... hmmm. :-) We even have at least one of them nifty keano new and improved Sun 4's! (big) :-) (Not here in CS, but there is >=1 on campus) >Unfortunately your claim that "all rewriting of From: lines is wrong" >is not correct unless EVERYONE is doing UUCP routing. For example, >consider: > > siteA --uucp--> sun --uucp--> siteB I didn't claim that. This site rewrites From: lines all the time. If anybody claimed that it was Paul. Any claim I would have made is that if you're going to rewrite From: lines then DO IT RIGHT! >The From: line starts out as "From: siteA!user", and we rewrite it >as "From: siteA!user@Sun.COM", which then gets rewritten going out >as "From: sun!siteA!user". The flamers are saying this is "RUDE". >But if we did NOT do it, then when the recipient at siteB replied >to the message, it would fail unless siteB were running UUCP routing >software. Since the standard UUCP software from AT&T (AND BERKELEY!!) >DOES NOT support UUCP routing, this is usually not the case. Thus we >try to be conservative, so that the recipient can reply if they do >UUCP routing or not. Since almost all of our mail is either directly >to us, or relayed through one hop, or relayed from all machines >that rewrite the header (i.e. standard Sun-issue software), we chose >to have a policy that causes these paths to generate replyable headers. It sounds to me as if the short version is this paragraph is We run primitive software! Nyahh! Nyahh! Look. Communications is important. One of the large reasons for the existance of the computers we have *here* (at UK) is for e-mail with colleagues. I suspect that any site which takes part in Usenet also would like to have a good e-mail system. As would most other places where you guys sell computers. Saying that standard software doesn't do good e-mail is not a good excuse. For one thing I was under the impression that you guys were going to be able to make some strong influences on the next version of the Standard Software. Tho' that was described as putting BSD features in -- like the fast file system and some other niceties... Be that as it may. How are things to improve if a major player is saying "we won't improve things"? I, a customer speaking here, would love to see you guys (not just Sun but AT&T, BSD, DEC, etc) to provide capable e-mail software with your systems. One *really* *GOOD* way of testing the e-mail software before letting your customers at it is to run it in house in a production environment for awhile. I once defended Sun's honor to a DEC salesman who was claiming that DEC had far better communications capabilities than Sun did. I knew fully well that Sun has all sorts of capabilities and that it's the equal of the capabilities in VMS. At least, give each their intended environment (DECNET || INTERNET) and they'll have equivalent capabilities. But now that I see this attitude I'm not so sure. At least with DEC's "primary" OS they deliver a mailer that can route mail world-wide ... :-) (sort of) >[Just because you're running UUCP routing software doesn't mean > everyone is ...] To which I say .... *SO*??? Now. Don't take me wrong. I'm mostly happy with the Sun equipment we have. It's good reasonable stuff. The software is a little strange sometimes, but then every company puts out strange stuff sometimes. I just want to see the world improve is all. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Looking forward to a particularly blatant, talkative and period bikini ...
jordan@zooks.ads.com (Jordan Hayes) (08/10/88)
David Herron <david@ms.uky.edu> writes:
Look. Communications is important.
Clearly.
/jordanwcf@psuhcx.psu.edu (Bill Fenner) (08/10/88)
In article <63372@sun.uucp> nowicki%rose@Sun.COM (Bill Nowicki) writes: |In article <10141@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: |> I am curious why nobody from Sun is here defending their honor. |> Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail |> configuration there? | |Sure, we are home, but only have time to deal with Usenet flames about |Unfortunately your claim that "all rewriting of From: lines is wrong" |is not correct unless EVERYONE is doing UUCP routing. For example, |consider: | | siteA --uucp--> sun --uucp--> siteB | |The From: line starts out as "From: siteA!user", and we rewrite it |as "From: siteA!user@Sun.COM", which then gets rewritten going out |as "From: sun!siteA!user". The flamers are saying this is "RUDE". |But if we did NOT do it, then when the recipient at siteB replied |to the message, it would fail unless siteB were running UUCP routing |software. Since the standard UUCP software from AT&T (AND BERKELEY!!) |DOES NOT support UUCP routing, this is usually not the case. Thus we |try to be conservative, so that the recipient can reply if they do |UUCP routing or not. Since almost all of our mail is either directly |to us, or relayed through one hop, or relayed from all machines |that rewrite the header (i.e. standard Sun-issue software), we chose |to have a policy that causes these paths to generate replyable headers. The From_ line behaviour is exactly what he is describing. Unfortunately, applying From_ line behaviour to From: lines mess things up badly. | |As you discovered, if you are NOT a direct UUCP neighbor of Sun, |but instead relay through a site that does NOT rewrite, e.g.: | | siteA --uucp--> siteB --uucp--> sun --Internet--> siteC | |Then our scheme breaks down. My response is that "siteB" is at fault, |since it did not rewrite the From: line as "siteB!siteA!user". If it No, but it most likely rewrote the From_ line as siteB!siteA!user. I have yet to see a host that improperly rewrote (or didn't rewrite) the From_ line. The From_ line *should* have an accurate indication of the path the message took and how to get back where it came from, unless it goes through a host like psuvax1 which breaks the From_ line. By the From_ line I mean the line that says From wcf (date) remote from psuhcx Bill -- Bitnet: wcf@psuhcx.bitnet Bill Fenner | Internet: wcf@hcx.psu.edu | This space UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf | for rent Fido: Sysop at 263/42 |
jsol@bu-cs.BU.EDU (Jon Solomon) (08/12/88)
I just want to put my two cents worth into this discussion. In the current internet (little "i" internet means everybody, Capital "I" Internet means DARPA blessed sites), we cannot reasonably satisfy everyone's complaints about mail header munging. About the only thing that is agreed upon is that some mailers have to rewrite headers or they get into some form of trouble. The most responsible thing you can do is to minimize the trouble. A user of mine got a message from a site: texfoo.crl (I'm paraphrasing, I don't remember the exact site). Clearly the people on this site prefer to hide the domain system from their users, but they neglect to add the appropriate finishing touches (.com, tektronix.com or whatever is right -- I don't know, all I could do is give my user a guess at what I thought it was). Like Bill Nowicki, my site sends out alot of mail every day. Most of it goes to either Internet (large I Internet) or BITNET sites. We have rewriting rules which make this task easy. Also, no header rewriting needs to be done. We have sites on campus which use uucp, but they conform to the domain system addressing scheme and that makes our rewriting lives easier (we don't have to in their case). As more and more uucp sites come up, and their interdependencies with Internet sites increases, the need for a common naming scheme will be ever-increasing. BUT UNLESS WE ACTUALLY MAKE A CERTAIN NAMING SCHEME LAW WITH ITS APPROPRIATE PROTECTIONS, we have no way of truly enforcing the rules. SO, sendmail rewriters do the best they can. Without legal precidence for naming schemes, we will not be able to fully police the network. Flaming and peer pressure do help, but they are not the complete answer. Only laws and lawyers will really help this sort of thing. Personally, I think Sun is doing a great job forwarding mail. They seem to look at the world from the view that I share, which is that the Internet is the center of the world, and uucp has to eventually conform or be ousted. Think of what chaos there would be if the Internet adopted "bang-style" routing (that is ucbvax.berkeley.edu!bu-it.bu.edu!jsol). The Internet tries to make routing work through the use of domains, and not through the use of address munging. I think the powers that be on the Internet consider header munging a bad idea (I agree). On the other hand, the uucp sites would cry murder if we failed to add "buita!" before the headers we pass to them. They already face a number of problems with address resolution because they aren't a connected-all-the-time network. There is also some rule that says we can't tell others how to do their own internal routing and name resolution. We just have to be sure that they follow the protocol. Which brings up a point, is there an rfc covering how routing should be done in the UUCP world? If not then I think there should be. Flaming at Sun without an RFC to point at is like flaming at the devil. It just won't help. --jsol