SendMail

[Mechanical]

This is a long message. If your aren't interested in sendmail and large
networks then you might as well skip this message. You may have seen
this message elsewhere as it is being cross posted to big-lan,
sun-spots, nfs, tcp-ip, and unix-wizards.  If there is a more
appropriate list to discuss this in let me know and I will take this
matter there.

We here at the US Naval Academy (USNA) in Annapolis, MD are building a
network. We have been operating an ethernet LAN connecting several
minis and workstations for quite some time. We use thin, thick, and
fiber based ethernet. We are reasonably well versed in TCP/IP and have
experience with mpr's and gateways. Our hosts run the gamut from
Zenith PC AT clones using SUNs PCNFS package to SUN workstations to
VAX and Gould minis. 

We have about 20 hosts on our network that are capable of exchanging
mail via sendmail. We are in a growth process and expect our number
of workstations to increase dramatically as our new network is
installed and more folks buy workstations. It is quite possible that
we will eventually have 4-7k workstations and their servers attached
to our network in the future. 

We currently use MMDF as our mail handler but are in the process of
switching to sendmail as sendmail seems to be emerging as the
"standard" mail handler. I have been selected to work on installing
sendmail and planning our mail routing system. I have spent a
reasonable amount of time working with sendmail and thought I would
ask around to see if what everyone else is doing. 

Here is what I am planning/doing....

Some background...

First, USNA will switch from 2 level domains to 3 level. Currently
hostnames are of the form "machine.USNA.MIL", in the near future
hostnames will change to the form "machine.division.USNA.MIL" (if
necessary we might even switch to 4 level domains-
"machine.department.division.USNA.MIL"). There will be an
authoritative host named USNA.MIL. There will also be a host (or
possibly an alias pointing to a host) for each sub-domain, ie there
will be a sub-domain named "math.USNA.MIL" with a primary server named
"math.USNA.MIL". 

Second, every user's home directory will be made available to him on
every workstation in the yard. The goal is to allow any user to sit
down in front of any workstation in the yard and be able to login and
have his files available. Yes, I realize that will involve a tremendous
amount of NFS cross mounts and may not actually be feasible but that
is the plan for the time being. How the password file updates will be
made has not yet been determined. Ideally I would like to use SUN's
Yellow Pages to handle all of the password mess. I am not sure how may
vendors do/will support YP but I will worry about that problem later.

I have come up with the following tenets that I think are wise.  If
you disagree then send me mail and we can discuss it- maybe we all can
learn something new about sendmail. I would prefer that all responses
come straight to me and I will summarize to the net if there is
interest. Maybe there is enough interest to start a sendmail interest
group (provided there isn't already one that I don't know about). 

Sendmail workstation/server configuration philosophy: 
(aka "the gospel according to tim")
-------------------------------------------------------

-All mail should live on a sub-domain host. Individual workstations
should never receive incoming mail- there WILL NOT be a mailer daemon
running on the workstation to receive incoming mail. Whether mail will
live in /usr/spool/mail or the user's home directory is yet to be
decided. I am leaning towards hacking sendmail to put mail in the
user's home directory.

-Workstations punt all mail to their sub-domain server. Workstations
exchange mail only with their sub-domain server. Only outgoing mail is
handled by workstations.

-Workstations should have very minimal configuration files on them.
Workstations should have a sendmail.cf that is virtually identical to
all others in the yard. Workstation sendmail.cf's should essentially
be "maintenance free". 

-The address data in intra-USNA messages will never contain a
workstation hostname- only sub-domain names will be used. (There will
be a host or host alias with the sub-domain name.)

-Inter-sub-domain mail (ie intra-USNA) can be directly routed from one
sub-domain server to another.

-Mail bound for destinations outside USNA will be routed from the
sub-domain host to the USNA.MIL server. This mail will have USNA.MIL
in the address lines. Sub-domain names will never appear in outgoing
message address lines. This will allow USNA.MIL to reliably accept
mail from the outside world regardless of the status of the internal
USNA network.

-Mail arriving at USNA.MIL from outside hosts will be forwarded to the
proper server using a large central data base of aliases on the
USNA.MIL server. Individual users will also be able to forward their
mail via the .forward file in their home directory.

---------- End of Philosophy Statement--------------------


Here is a typical scenario that I imagine...

User "joe" invokes the sending front end to sendmail on his workstation.
He composes and addresses a message to user "mike" and hands it to his
mail agent to pass to sendmail. Sendmail on the local workstation
starts up and the following takes place:

1) The workstation punts the message to the sub-domain server.

2) The sub-domain server tries to deliver the mail. If the
sub-domain-server finds that "mike" is a user who gets his mail on
this server then the mail is delivered as per sendmail's local mail
delivery procedures. If the sub-domain-server finds that "mike" is a
user who gets his mail on another sub-domain-server then the mail is
passed to that server. If the local sub-domain-server cannot determine
where "mike" gets his mail then the message is punted to USNA.MIL (the
next level up the domain ladder).

3) USNA.MIL gets the mail and tries to deliver it. If USNA.MIL
knows who the user is the mail will get delivered- if USNA.MIL
doesn't know who the user is then that user doesn't exist and
an error should be returned to the sender.

What needs to be done to make all this happen is not yet known. 

SUN's Yellow Pages service either complicates or simplifies this whole
issue. Do we expect all the machines in the yard to understand YP (it
would sure be nice if they did!)? I doubt that I can count on all of
the yard understanding YP. I am open to suggestions/opinions, one way
or another.

------------------------------------------------------------
Problems I for see:

-All sorts of "odd" cases...

A user could be logged into a workstation in a division other than his
own sending mail to anyone. 

Not a major problem but something to keep in mind when "Reply-To:" and
"From:" lines are being set up. What should the "Reply-To:" and
"From:" lines say? Should they list the sub-domain server that the
user is sending from?  Should they list the user's "home" sub-domain?
(I would tend think so.)

If the mail is addressed to someone outside of USNA then the problem
will go away since (according to the tenets above) all mail leaving
USNA should have its "Reply-To:"  and "From:"  fields rewritten to the
form "user at USNA.MIL". 

A user may prefer to receive his mail on a machine other than his
"home" sub-domain server. No big deal, a .forward file should handle
this without any problems (I think).

Where do aliases get expanded? I have just about ruled out an alias
expansion on each workstation. I would think that they could be
expanded on either the sub-domain server or on USNA.MIL (or maybe on
both). 

-Conflicts over file locking and simultaneous access to the user's
mailbox.

Here is a possible scenario of locking problems...

User "joe" is reading his mail on workstation "xxx.math.USNA.MIL".
joe's workstation is diskless and mounts its files from his sub-domain
server. In order for this to happen the directory that joe's mailbox
lives in will have to be NFS mounted on his workstation. For joe to be
able to delete messages from his mailbox he will need write
permissions on his mailbox. Thus the NFS mount of the directory
containing joe's mailbox will have to be mode "rw". I see a potential
problem here. If joe is has just finished deleting messages from his
mailbox and is updating it when a new message comes in (ie 
math.USNA.MIL tries to deliver it) there could be an ugly scene as the
process trying to purge the deleted messages from the mailbox and
the delivering agent fight over who gets to write in the mailbox file.

So what happens in the above case? 

-Where do users mailboxes live?

If I already have all sorts of home directories NFS cross-mounted all
over the place I certainly don't want to add to the mess by cross
mounting /usr/spool/mail all over. Not to mention what do I call the
directories? I would be NFS mounting several different /usr/spool/mail
directories from several different servers. I have already ruled out
the idea of a single machine with a massive /usr/spool/mail for
several reasons. Ideally I would like to have each user's mailbox live
in his home directory.

--------------------------------------------------
Sendmail Gripes:

-sendmail.cf cannot find out its domain (or subdomain) internally (at
least I can't figure out a way to do this). This would be a nice
feature to have so we don't have to hard code this info into each
sendmail.cf. (Isn't there a system call that returns the domain name
of a host? How about adding an internal macro to sendmail to add this
feature.)

-It should be possible to configure sendmail to have the user's mailbox
live anywhere (Like maybe their home directory).


Well that is about it. I would like to hear from others- sendmail
experiences, solutions to my problems, ideas about what to do next, or
just commiseration would all be appreciated. 

NOTE: I LIKE SENDMAIL! I think it is very flexible and powerful. I am
simply pointing out my difficulties (and non-difficulties) and asking
whatcha'all think. So please spare me any flames telling me I don't
appreciate sendmail and that I should be condemned to an afterlife in
a post office in hell doing "manual mail routing". OK?

Looking forward to hearing from everybody,
	Tim Smith		
US mail:CADIG mailstop: 11G	E-mail:
	US Naval Academy	internet:tsmith at USNA.MIL
	Annapolis, MD 21402	uucp	:...!uunet!usna!tsmith
MaBell :(301)267-4413