Newsgroups: comp.mail.sendmail
Path: utzoo!utgpu!jarvis.csri.toronto.edu!neat.ai.toronto.edu!rayan
From: rayan@ai.toronto.edu (Rayan Zachariassen)
Subject: home delivery non-standards, followup
Message-ID: <88Nov27.125307est.6152@neat.ai.toronto.edu>
Date: Sun, 27 Nov 88 12:52:57 EST

[ The questions was whether there was a standard filename for UCB-Mail format
  message delivery to the recipients' home directory. ]

Based on the responses, there is obviously no overwhelming favorite:

.maildrop	1	(RPI)
.mail		2	(MMDF; Australia: Rourke mail & their local Upas)
.mailbox	1	(Brunel U, UK)

Mailbox/	1	(Andrew Message System, a directory)
don't-do-it	1

Based on this meagre tally,  I suggest ~/.mail be used in the future.

Here are some (paraphrased) comments and my thoughts on them:

John Mackin @ Basser U, DCS:

   The local delivery program needs to be robust: "the last thing you want to
   do is bounce the mail because the user's home directory happens to be
   unavailable" (in the context of backups done with homes unmounted).
   One solution is to deliver to an alternate location in that case (e.g.
   the traditional mail spool area).

I would prefer a delivery program that refused to deliver and just left
the messages queued.


Karl Owen @ Data General:

   There are good reasons to keep a "super" mailbox (/usr/[spool/]mail) concept:

   The home directory may temporarily disappear for various reasons, for
   example because it is a remotely mounted filesystem and the server is down.
   The delivery agent may not be able to distinguish between such a temporary
   condition and a permanent situation.

This is quite true.  I would not recommend delivery to a remotely mounted
filesystem unless if the machine you're delivering from is 100% dependent
on the (one) remote server.  This is also a problem with .forward files.

There are three reasons I can think of why one might want to deliver to a
home directory file:

- avoid dependency on a mail server
- move file space from system to user area, get people to police themselves
- aesthetics

You have to balance these off against the robustness of your environment
and your mailer.  In our case, we have twin machines of which one was the
mail/network box.  People on the second machine couldn't read or send mail
when the mail server was down.  We first considered delivery to home
directories to solve the access problem, but that doesn't address the
problem of mail coming in for someone whose home directory is remotely
mounted on the mail server, whose home dir server is down, and the mailer
trying to read their .forward file.  Instant hung mailer.  We now run a
mailer on the secondary machine and do mutual forwarding based on where
people's home directory is.  In the long run, this isn't very satisfactory.
In the short run it has proven slightly unstable due to the cruft people
put in the .forward files ("oh, forward to the mail server" MS:"oh, his home
isn't here, forward to the other machine" OM: "oh, forward to the mail server",
etc.)  Back to Karl:

   Many mail readers will have to be redone or some compatibility mode
   must be introduced during the migration.

Use symlinks: /var/mail/rayan -> ~rayan/.whatever


Craig F. Everhart @ ITC, CMU (about the Andrew Message System):

   Each message is delivered as a separate file in a known (system-wide
   configurable) directory (~/Mailbox/).  Such directories have equivalent
   of `world-writable w/ sticky bit set' permissions, meaning local mail
   is trivially authenticated (owner of the file).

There are a lot of advantages to a scheme with one file per message.
However, very few user agents are prepared to deal with that yet.  I would
be interested in determining a standard for that situation as well.  How
about the following (screwy) scheme?:

stat ~/.mail

If it is a file, deliver in UCB-mail/MMDF format to that file.

If it is a directory, create a new file in that directory and deliver
the raw message to it.  The algorithm that generates the file name is
guaranteed to produce unique names consisting of all-digits.  The algorithm
is free to maintain state between invocations but doesn't need to.

Two issues: should creation of a Return-Path (a la From_ line) be mandatory?
	what happens if the "unique" filename that is generated already exists?

If you care to shoot this down or make suggestions, feel free.

rayan

