>- It seems that there is an implicit assumption that a mail spool area
>should consist of a single directory which contains a single file per
>user, which contains that user's mail. This is a holdover from
>antiquity, and clearly does not scale well to systems which support
>thousands of users. Furthermore, it's ridiculously simple to change to
>a hierarchical model, in which case, the issue of file-level access
>control becomes rather moot.
This is exactly what we do. While we are not large enough to have
scaleability problems, it was trivial to move our mail store from
/usr/spool/mail into a hierarchical structure. This not only gives
us the ability to scale (should we ever need to), but since we have
the mail in AFS, it is simple for us to provide multiple servers
for POP, mail delivery, etc. to improve performance and scaleability.
>> The one unavoidable bottleneck in distributing a large-scale mail
>> service within DFS might be in serializing new mail delivery.
>> Optimally, you'd like to use a single address for mail delivery, which
>> means that a single host would be responsible for injecting everybody's
>> new mail into DFS. I'd think that this could still scale to thousands
>> of uses -- but tens of thousands?
>
>I don't see why you would need (or want) to serialize mail delivery, or
>why a single address is optimal, or... We actually have two mail
>servers now.
I can understand why a single address is desireable, but I don't think
that this implies a single mail server. If you provide a single
globaly visable space to spool mail (not necessarily meaning a single
/usr/spool/mail directory), and a file system that handles locking
properly (unlike NFS for example), I don't see any reason that a site
couldn't provide two or more servers to spool the incoming mail.
Same goes for hosts who read email through POP (or similar protocols).
We allow users to choose how they get their email. If they _like_ to use
Unix machines (which most don't for some reason), they can use any of the
standard Unix mail progs (expect for one that comes with Solaris which
seems to be broken) and read directly from their spool area. If they use
a Macintosh or a PC, we gave up on file service translators and provide them
a kerberized POP service that could be distributed across servers should
there be a load to necessitate this. The only bad side effect for us
is that these users send their password across the net...fortunately
we have the means to educate our users to the point where they will not
do this outside our internal network, so we are less prone to breakins
than some some places.
-matthew