paul@frcs.UUCP (Paul Nash) (12/03/90)
We have a dispute between the administrators of a few local machines. One of the machines runs `sendmail' (for bizzare reasons), and has a `sendmail.cf' file that re-writes the `To:' and `From:' fields in all forwarded mail. The effect on the headers is roughly as follows (`gatebox' is the [ficticious] `sendmail' pervert): incoming outgoing To: user@toaster To: toaster!user@gatebox From: me@tinytoy From: tinytoy!me@gatebox The administrator of this particular machine feels that this is perfectly reasonable, and even desirable, so that mail gets routed the way that they think fit. However, others of us think that this is not terribly sociable, and want our addresses left alone. I have tried digging through RFC822, but it has cast no light on the subject. My gut feel, though, is that each mailer should only rewrite the `Path:' field (and add a fifteen-line `Received:' field). The rest should surely be left alone (after all, _I_ know who I am). Are there any Mail Gurus out there who can elighten us? ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Flagship Wide Area Networks (Pty) Ltd paul@frcs.UUCP ...!uunet!ddsw1!proxima!frcs!paul
time@tbomb.ice.com (Tim Endres) (12/05/90)
In article <208@frcs.UUCP>, paul@frcs.UUCP (Paul Nash) writes: > The administrator of this particular machine feels that this is > perfectly reasonable, and even desirable, so that mail gets routed > the way that they think fit. However, others of us think that this > is not terribly sociable, and want our addresses left alone. > Disclaimer: I am no email guru, just been into it a long time. This is one of the longer standing debates in mail history. The original philosophy in electronic mail design was that a mailer look at the "envelope address" to work with a piece of mail and *never* touch the "envelope contents". This was fine with a single mailer and a single transport, but alas, along came other mailers and transports. With the divergence of mail mechanisms came the realization that the "envelope address" was sometimes inadequate. To solve this, some mailers began to look at the internals of the "envelope contents" to view the header information and better perform their task. While this was viewed as "wrong", it solved the problem at hand and created few of its own. Then, along came sendmail! The dark force of the mail universe! :^) For some reason, which I have never had fully explained, sendmail found it not only necessary to view headers to determine the means of transporting the letter, but to modify these headers in order to assist in the routing and reply routing of the letter through other sendmails. Mailer purists will tell you that sendmail is evil and breaks the most fundamental of rules. This is my attitude. However, sendmail administrators often have good and valid reasons for doing what they do. Clearly, sendmail performs its duties at many locations without complaints. I guess the bottom line is this: I have *never* met a sendmail installation that did not create problems by munging headers. This is a headache for the administrator as much as the mail user. Now granted, it may be only one problem out of thousands of letters, but sooner or later it happens. As an aside, my mail server recently tossed sendmail away for smail3. This was because 30% of the mail I sent bounced going out, and 40% of the replies never made it back. I am sure that had the sendmail been configured a little more the problem could have been fixed. BUT smail3 fixed the problem right away. It left the headers alone! tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uunet!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | (313) 449 8288
les@chinet.chi.il.us (Leslie Mikesell) (12/08/90)
In article <1CE00001.p376wj@tbomb.ice.com> time@tbomb.ice.com writes: >As an aside, my mail server recently tossed sendmail away for smail3. >This was because 30% of the mail I sent bounced going out, and 40% >of the replies never made it back. I am sure that had the sendmail >been configured a little more the problem could have been fixed. BUT >smail3 fixed the problem right away. It left the headers alone! Even smail3 will mung the the header lines by prepending its own uucp name if they are already in "!" notation. I ripped this part out because someone is likely to reverse user@domain into RFC976'ish domain!user when they pass the message off to uucp mailers. This would be reasonable (since reasonable uucp mailers treat the two forms interchangably) except that it encourages sites along the path to prepend their own name, and not all of them do. Thus the final recipient is likely to see x!y!domain!user where x is neither a neighbor nor a fully qualified domain. Les Mikesell les@chinet.chi.il.us
barnett@grymoire.crd.ge.com (Bruce Barnett) (12/08/90)
In article <1CE00001.p376wj@tbomb.ice.com> time@tbomb.ice.com (Tim Endres) writes: > Then, along came sendmail! The dark force of the mail universe! :^) > For some reason, which I have never had fully explained, sendmail > found it not only necessary to view headers to determine the means > of transporting the letter, but to modify these headers in order to > assist in the routing and reply routing of the letter through other > sendmails. The reason sendmail does this is because it is necessary. Not all addresses that come into our machine are valid. Not all are fully qualified domain names, or RFC822 addresses. The addresses user@machine or user@machine.UUCP are not valid Internet addresses. If I deliver mail to another internet site, it must be replyable. The above addresses are NOT. If we get such an address, and we send it to another internet site, we MUST convert it into the form: machine!user@crdgw1.ge.com To do anything else would be wrong. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
chip@tct.uucp (Chip Salzenberg) (12/11/90)
According to les@chinet.chi.il.us (Leslie Mikesell): >Even smail3 will mung the the header lines by prepending its own >uucp name if they are already in "!" notation. I ripped this part >out because someone is likely to reverse user@domain into RFC976'ish >domain!user when they pass the message off to uucp mailers. Of course, if a header field contains user@valid.domain.name, then any mailer mangling that header field into valid.domain.name!user is being Evil and Rude. In any case, you're quite right; Smail 3's behavior in prepending its host name is also Evil and Rude, and should be stopped forthwith. Perhaps a public patch posting would be appropriate. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "What's that thing, when people die, they take apart the body to see why?" -- St. Theresa of the Net
fair@Apple.COM (Erik E. Fair) (12/13/90)
In the referenced article, time@tbomb.ice.com writes: > >Disclaimer: I am no email guru, just been into it a long time. > [...] >I guess the bottom line is this: > I have *never* met a sendmail installation that did not create > problems by munging headers. This is a headache for the administrator > as much as the mail user. Now granted, it may be only one problem > out of thousands of letters, but sooner or later it happens. This is because there are entirely too many people who believe that because they have read chapter 5 of the Sendmail Installation and Operation Guide that they are qualified to modify sendmail configuration files. Wrong. You must have a deep understanding of the E-mail system as a whole, and how all the parts interact with each other (and there are some cases in which you just can't win, due to the ignorance of other mail system implementors. There is a special place in Hell for them). Sendmail is typical of most tools for UNIX: it gives you plenty of rope, with which you may accomplish your task, or hang yourself, if that is what you desire. Smail is a win for most people because it is simple, and has wired assumptions for common cases. Don't try anything complex with it, and it will serve you well. That was why it was designed. However, I wouldn't try to run a medium-complex mail installation (e.g. Apple Computer) without sendmail on the key systems because there are no alternatives with its power and flexibility, for those who are competant enough to make correct use of it. Erik E. Fair apple!fair fair@apple.com
les@chinet.chi.il.us (Leslie Mikesell) (12/18/90)
In article <47340@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: >However, I wouldn't try to run a medium-complex mail >installation (e.g. Apple Computer) without sendmail on the key systems >because there are no alternatives with its power and flexibility, for >those who are competant enough to make correct use of it. Have you investigated smail 3.1 (a very different thing than smail 2.5)? My impression (without much exposure to sendmail) is that it is more powerful than standard sendmail, especially in a uucp environment, but perhaps less flexible than sendmail + IDA. I'd like to see a real point by point comparison, though, if anyone has had the fortitude to tackle both in depth. Les Mikesell les@chinet.chi.il.us
jdeitch@jadpc.cts.com (Jim Deitch) (12/19/90)
In article <1990Dec18.045058.18758@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <47340@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: > >>However, I wouldn't try to run a medium-complex mail >>installation (e.g. Apple Computer) without sendmail on the key systems >>because there are no alternatives with its power and flexibility, for >>those who are competant enough to make correct use of it. > >Have you investigated smail 3.1 (a very different thing than smail 2.5)? >My impression (without much exposure to sendmail) is that it is more >powerful than standard sendmail, especially in a uucp environment, but >perhaps less flexible than sendmail + IDA. I'd like to see a real >point by point comparison, though, if anyone has had the fortitude >to tackle both in depth. > >Les Mikesell > les@chinet.chi.il.us You are partly right. Smail 3.1 is VERY nice, easy to configure, easy to maintain. Your normal system manager can have it running from source in about 2 hours. The hardest part is editing the config file. They even have a test configuration that you build, the system installs in a place you specify, then you can test it at your leisure. When you are satisfied that all is well, remake without the test config flag set and install. Real simple. Out of the box the configurations supplied will not have to be modified except for weird circumstances, arcnet, bsmtp over uucp, etc. My only gripe is that when using smtp you start it just like sendmail (sendmail -bd -q30m), but you need to have an entry in your cron file to check for mail that has been delayed and re-try delivery. Other than that, the documentation is good, it is easy to maintain, and bug-free. Just my 2 cents worth. Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch