Xref: utzoo comp.mail.misc:1199 comp.mail.sendmail:61 comp.mail.uucp:1684 Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!vixie From: vixie@decwrl.dec.com (Paul Vixie) Newsgroups: comp.mail.misc,comp.mail.sendmail,comp.mail.uucp Subject: Re: smail query Message-ID: <67@volition.dec.com> Date: 22 Aug 88 05:16:33 GMT References: <605@bnlux0.bnl.gov> Distribution: na Organization: DEC Western Research Lab Lines: 116 WARNING: this is very long and overly verbose. Skip to the summary at the end if you want to know what I'm talking about without reading the whole thing. # What would be the advantage, if any, of implementing smail on our system? Smail is linked functionally into your MTA by replacing or front-ending two other components: /bin/rmail This is run whenever a mail message comes in over UUCP, with command line arguments giving the "envelope recipients" of the message, and the standard input set to the message text itself. As part of the installation of Smail, you do something like this: mv /bin/rmail /bin/rmail.old ln /bin/smail /bin/rmail This causes "smail" to be run for incoming mail messages, except that it can check its argv[0] to see that it was actually executed as "rmail". In this mode, it looks at the envelope recipients and tries to see if they are destined for one of your direct UUCP neighbors. (Wait. Does it do a lookup on /usr/lib/mail/paths here? I forget.) If so, smail ("rmail") calls "uux" to queue the message up for the "rmail" command on your UUCP neighbor. If not, it calls "sendmail", which will either deliver the message locally (by calling /bin/mail) or queue it up for some other mail transport, possibly UUCP but more likely SMTP if it isn't local and it got that far. This first link is basically a performance improvement, since the sendmail program is very large and if pass-through UUCP mail can be passed through without starting up sendmail, it's less work for your system. If you don't replace "rmail" with a link to "smail", all your incoming mail will go to sendmail, which is a performance hit but causes no loss of function. /bin/smail This is run in sendmail.cf instead of running "uux" in the "Muucp" or "Muux" or whatever you call your UUCP mailer. Its arguments and options are a little different from uux, which is why the "smail" kit comes with its own sendmail.cf. (You can just grab the relevant lines from smail's sendmail.cf if you have a sendmail.cf of your own that you like; this is often needless paranoia, since the sendmail.cf that comes with smail does pretty much everything you could want.) This gains you two things, one incredibly important, one merely convenient. I'll list incredibly important one first, in great big capital letters, since many people don't know it's even an issue: SMAIL DOES NOT REWRITE THE HEADER SENDER ("From:" line) Sendmail, unless hacked, cannot treat the "From:" line differently than it treats the "From " line. (The "From:" line is in the headers, and the "From " line is the first line of the message, neither a header nor message text. We call the "From:" line the "header sender" and the "From " line the "envelope sender". The "From " line is often written as "the From_ line" to save on quote-marks). Because sendmail treats the envelope sender and the header sender the same way, it causes Bad Things to happen to mail as it is sent out over UUCP. The envelope sender, you see, has to have the system's UUCP name added to the front of it, in case the message has to be returned to the sender. So if a message comes into site "decwrl" with a From_ line of From vixie!paul Sun Aug 21 22:03:00 PDT 1988 (please, nobody yell because the date is in the wrong format!) It has to be changed to read: From decwrl!vixie!paul Sun Aug 21 22:03:00 PDT 1988 But we don't want to do this to the "From:" header. Imagine: From: paul@vixie.sf.ca.us (Paul Vixie) becomes: From: decwrl!paul@vixie.sf.ca.us (Paul Vixie) This is wrong, for many reasons, which I will not detail here. So, why is smail important? Because when you use smail, it can change the envelope sender without mucking up the header sender. This is the most important reason to use smail. I recommend installing smail even if you have no better reason and don't use any other feature. There is another feature, though. Automatic routing. Once you get smail hooked into your sendmail.cf file, you tell your sendmail.cf to send not just UUCP traffic, but all non-local traffic that you can't think of a good reason to hand off to SMTP or BITNET or which- ever. So, with sendmail handing off all to smail non-local traffic it can't deal with any other way, smail gets to look for a route to anything that your system doesn't talk to directly. So you can send mail to "decwrl!vixie" (or vixie@decwrl, but that's another battle for another day) and even if (as is likely) your system doesn't talk to "decwrl" directly, smail will poke around in its routing database and discover that although you don't talk to "decwrl", you do talk to "lll-winken" (or whatever) who talks to "pacbell" (or "ames") who in turn talks to "decwrl". So the "uux" command that smail runs for you (that's the point, remember: to run a "uux" command) says something like uux - -r -z (lll-winken!pacbell!decwrl!vixie) You need a pathalias database for this. Ask in a separate note if you need to know what this is and how to get one on your system. Summary: Sorry this is so long, I've had too much sugar tonight. But the short version of the answer to "why should I install smail" is: (1) to save CPU cycles on pass-through UUCP traffic (OPTIONAL) (2) to make your system able to get mail to any registered UUCP site as though you had a direct UUCP connection to them (OPTIONAL) (3) to keep sendmail from destroying mail headers (VERY IMPORTANT) There is no other easy way to accomplish (3). (1) and (2) are nice to have but you can live without them, even if you install smail to fix (3) but don't want (1) and (2). -- 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