rayan@ai.toronto.edu (Rayan Zachariassen) (11/27/88)
[ 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.
rayantaylor@cs.glasgow.ac.uk (Jem Taylor) (11/29/88)
In article <88Nov27.125307est.6152@neat.ai.toronto.edu> rayan@ai.toronto.edu (Rayan Zachariassen) writes: >[ The questions was whether there was a standard filename for UCB-Mail format > message delivery to the recipients' home directory. ] >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. I believe this to be the only sensible way to organise a mailbox ! It places concurrency control in the filesystem, and means there can be no problem with several people or processes reading the mail at the same time but closing after deleting different messages. It also eases the 'search for message headers' phase of start-up - the headers are at the fronts of the files. >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. This is a lot like closed-hash - which is well understood. However, I would suggest NOT using a 'random' unique name, because it discards data. One thing a User Agent might like to do, apart from offering messages in CREATION DATE order rather than DELIVERY DATE, is to group messages which reference one another by References: or In-Reply-To: headers. So, either use the Message-ID: in the message (which should be unique) or use the Date:. I prefer Message-ID since it is more likely to be unique; if it exists then compare body parts; if body is the same it is a duplicate -> discard it; if they differ then append (!). If the UA can cope with /usr/spool/mail format then it can also cope with two messages in one file. -Jem Taylor. -- ARPANet:taylor@cs.glasgow.ac.uk | Mail: J.A.Taylor, Computing Science, JANET: taylor@uk.ac.glasgow.cs | Glasgow University, UseNet: mcvax!cs.glasgow.ac.uk!taylor | GB-GLASGOW G12 8QQ