Sendmail Question

[Joseph S. D. Yao]

In article <111 at funvax.UUCP> bhoward at funvax.UUCP (Bruce Howard) writes:
>Would someone please explain the order in which sendmail.cf
>rulesets are called?
>	...  I've looked at the config files for several sites
>and most of them seem to call ruleset 3 from ruleset 0 before
>resolving addresses to a specific mailer.
>...decvax!ittatc!funvax!bhoward  Bruce Howard @ Fairfield University
>...ihnp4!itivax!funvax!bhoward   Located in Scenic Fairfield, CT 06430

Having recently wrestled with the demon Sendmail on Ultrix 1.1
(essentially unmodified 4.2), I may be able to help.

As the documentation says or hints (for those not as lucky as
Bruce), there are essentially three major paths through the
rule sets.  They are:
	3 -> 0 -> 4		[the doc forgets 4]
	3 -> D -> 1 -> S -> 4
	3 -> D -> 2 -> R -> 4
S and R are different for each mailer, and are specified as
part of the M mailer specification.  I have not been able to
figure out what D is: nothing like that gets called by the
sendmail on which I was working.  1 and 2 each consist of a
commented-out rule.  This leaves us with, really:
	3 -> 0 -> 4
	3 -> S -> 4
	3 -> R -> 4

Now, who gets called where and when, and whence come S and R?

The mail consists of: a header, a body, and external information.
The body is the message per se.  The header contains (among other
things) From-type lines and To-type lines, containing addresses.
The external information contains such goodies as who really sent
the message, to whom it is really being sent, etc.  This is NOT taken
from the header, (a) to save re-scanning; and (b) to help prevent
cycles of inter-machine mail ping-pong, such as has happened in
the past.  (Perhaps someone at UCB or the NIC wants to tell about
this; I don't know enough.)

When sendmail is called in mailer mode (did you know how many
programs are inside its skin?), it calls 3-0-4 and then 3-1-4
on the sender address.  I am not entirely certain why.  It
then calls 3-0-4 on each to-address in the external information.
This generates, for each address, two or three things:
	(1) a mailer name for that address;
	(2) a name to pass that mailer to make it work; and
	(3) for non-local mailers only, a host address.

Each mailer may require To- and From-type lines to be editted
slightly differently.  For instance, if I send mail via UUCP,
I will want mail to say From: hadron!jsdy; but if I send it
via ARPA net (in theory only! we are not on the DDN!) I will
want the mail to say From: jsdy at hadron.COM.

DIGRESSION:  If Unix mail goes entirely domainist, the latter
form will be universal.  Strictly, a name of the form
name-or-whatever at host[.DOMAIN]* shouldn't be messed with; but
reality intrudes.  (I.e., the world will NOT go domainist all
at once; especially not the Unix world!)

Anyway, IF we want to edit these lines, we find that a different
copy of the message is being made for each mailer.  (Not per host,
if you ever wanted to try that -- and I did.)  If your mailer
specification says:

Mmailer ... S=n1 R=n2

then editting is done to the From-type lines via 3-n1-4, and
editting is done to the To-type lines via 3-n2-4.  E.g.:

Mlocal,	P=/bin/mail, F=rlsDFMmn, S=10, R=20, A=mail -d $u
Mprog,	P=/bin/sh,   F=lsDFMe,   S=10, R=20, A=sh -c $u
Muucp,	P=/usr/bin/uux, F=sDFMhuU, S=13, R=23, M=100000, A=uux - $h!rmail ($u)

Well, what are all those other rule sets?  Whenever you have
a rule of the form:
R<pattern>		$>N<pattern>
then, if the left pattern matches, the rule set N is called
with the right pattern as its initial pattern.  A rule set
returns either the pattern that results after each of its
rules has been applied, in turn, as many times as possible;
or whenever it encounters a right-hand side that is preceded
by $@ -- at which it returns the pattern generated by the
right-hand side.

[Bit of trivia -- the LHS and RHS  m u s t  be separated only
by one or more TABs: any spaces will be interpreted as part
of the rule to which they're attached!  If you have in the
middle a <TAB><SP><TAB>, then your RHS will be interpreted
to be just that <SP>, and you will never figure out what your
problem is!]

We are now back to the question:
>	...  I've looked at the config files for several sites
>and most of them seem to call ruleset 3 from ruleset 0 before
>resolving addresses to a specific mailer.

S0
# first make canonical
R$*<$*>$*		$1$2$3				defocus
R$+			$:$>3$1				make canonical

[The $: on the RHS says do this once only.  This is needed because
the LHS matches all except the null string.  The RHS takes that
string and calls ruleset 3 on it.]

This seemed senseless to me, at first.  After all, 3 just got
called, didn't it?  Why call it again, and waste the gobs of
time (really!) that that takes?  Well, it turns out that later
on in ruleset 0 we find rules:

R<@>:$*			$@$>0$1				retry after route strip
R$*<@>			$@$>0$1				strip null trash & retry

What are these doing?  Right, they are returning the value of
ruleset 0 called on the first wildcard pattern ($* matches all
patterns including the null string).  BUT, before we call 0, we
want to call 3!  So, we call 3 in 0!  Brilliant, no?  I didn't
think so.  I got rid of the $>3 rule, replaced the latter two
RHS's with:
			$@>29$1
(only 30 sets are allowed: 0-29), and constructed rule set 29:

S29
R$+			$:$>3$1
R$+			$:$>0$1

This, as you can now tell, just calls 3 and 0 once each, and
returns whatever pattern results from that.  This was entered
in file zerobase.m4, just before S0, so that any use of S0
perforce includes S29.

I hope this helps.  Any comments, flames, or additions should
double to e-mail as well as to news, as I don't always have time
(between bouts with various demons) to get through this newsgroup.
-- 

	Joe Yao		hadron!jsdy at seismo.{CSS.GOV,ARPA,UUCP}
			jsdy at hadron.COM (not yet domainised)