Re: checking for new mail / $HOME delivery

[James S MacKinnon <jmack@Phys.UAlberta.Ca>]

Regarding Mark Moraes' comments about home delivery in a highly 
heterogenous environment, I thought I would add my own observations about 
our subnet here in Physics at the U of A.

Our environment here consists of about 120 smtp-deliverable hosts, also
loosely coupled, i.e. some are clustered, with those users sharing a 
common filesystem, but the vast majority are isolated entities - far from
any user having access to all machines. About 10 are across slip-links
or UUCP paths, where delivery must be delayed for some period (up to days)
until the lines come up. Another 40 or so machines are primitive (Macs
and PeeCees), which rely on POP, Eudora, or LeeMail transfer agents.

Historically, the subnet has evolved in separate niches, so there has
never been overwhelming homogeneity. In fact, the only single commonality 
that they all share is the wire.

$HOME delivery in this type of environment would be absurd, and hardly
worth even thinking about. Perhaps other sites see $HOME delivery as a way
to avoid a certain weakness in a tightly coupled NFS environment, but
one must also remember that home directories can suffer the same 
fate as the mail spool directory. You can just as easily jump from
the pan into the fire any way you look at it.

I run ZMailer on only two machines (one is primary, the other is a
standby in case of a fatal crash on the first), but use the standard
sendmail on all the other hosts (ZMailer is not run in server-client 
mode).

Here, our relay machine acts primarily as a mail gateway more than a local
user delivery agent. I kind of get the native functionality of the 
traditional sendmail at the local host level but with the power behind it in 
ZMailer at the LAN level. I let the 'provided' sendmail on each host worry 
about the handling of file-locks, and generally let each host's system do
it's own natural work letting people be notified about new mail - no 
conflicts. I have encouraged the use of pine (3.87) as a reader, since 
this version does file-lock transference, and avoids lockup where it could
occur.

Where small clusterings occur and a handful of hosts do share a spool, I
ensure in the routes db that only a single target machine acts as the
acceptor for mail for those subsidiaries. File-locking is not a problem,
since simultaneous access to a user's mail file can't occur.

Filled up spool directories are always a major potential problem on
any machine, but in our environment, those chances are minimized with
dispersion across the hosts, rather than a single-point of access
(this later admin or convenience "feature" can easily become a dangerous
single-point of failure, and this is why I chose not to run ZMailer
homogenously). Sometimes system admins dig their own hells in this 
area...

Architectural heterogeneity (NeXT,DEC-mips,DEC-VAX,Sun,HP,SGI) also
make it difficult to provide ZMailer on all machines, although I do
have great working binaries for NeXT and mips-Ultrix. The cost of 
re-building ZMailer on all these diverse types (and any new future ones) 
is just too high. I prefer to let the native architectures' mail daemons 
and agents handle mail in their own native way.

The primary relay machine databases all users, and provides a single SMTP
router path to a user's 'office' or most regularly used machine. Hosts
like Macs or PeeCees are regarded as 'localname' machines, so the relay
proxies for all of them, and POP or Eudora etc. transports can be optional
secondary agents if desired. But for any user on the entire subnet, there
is 1 and only 1 initial delivery target and it is always a host capable
of SMTP reception on demand from ZMailer.

Argueably, this requires a visit to ZMailer's db files whenever a new
host or user is added to the subnet, but so be it. Given that I provide
alias variants and fullname data, I'm doing this anyway. Not much 
additional work, and it pays off in reliability.

.forward files are never a system/zmailer problem. Sometimes they are a 
user problem though, with mis-spellings and circularity on another 
outside domain ;-). Not something I can do much about...

The main relay machine is set to accept 'generic' or host-hidden mail
address forms, and all subnet machines are MX'd to it, so that all
Phys.UAlberta.CA mail must pass through it. The other hosts all have
their sendmail.cf's set up to pass all outgoing traffic through this
relay, and do rewrite's to a host-hidden header format, so that all
reply-delivery decisions by ZMailer are based on the username rather
than by target host for the subnet. I encourage users to advertize
their host-hidden e-mail address in any correspondence. Mail delivery
through this method is highly reliable (given the setup here).

If the primary relay dies, everyone has an equal chance of getting
no mail (for a short while, until I swap in the backup), but I'd rather
have that scenario than spreadout breakage elsewhere - equal bias that 
way.
This is also a single-point of failure, but is is centralized - 
not too different functionally than if the nameservers go down, or
if the LAN router packs it in (far less catastrophic though, since
I can just swap in the 'shadow' machine).

The time granularity and long queue time (3 days) have almost never
let me down - if there is an obvious problem with a downed host, I
can always re-route in time before a delivery failure of this type.
ZMailer's routing capability is superb.

In short, without ZMailer, I'd be sunk. I would never be able to do
this on a sendmail.cf type mail relay gateway.

--
James S. MacKinnon             Office: P-139 Avahd-Bhatia Physics Lab
Computing/Networking           Voice : (403) 492-8226
Department of Physics          email : Jim.MacKinnon@Phys.UAlberta.CA
University of Alberta                : jmack@Phys.UAlberta.CA
Edmonton, Canada T6G 2N5       bitnet: jmack@triumfcl