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