> > NFS mounting the mailspool is old hat, in my opinion. All my users are on
> > IMAP, and that works/scales just fine. I don't mount the mailspool anywhere
> > anymore (except the mail server!) .
> Old hat, true, but also a hat that worked for a long time before IMAP
> came along and still works.
I'm not contesting that. I still miss elm! But elm couldn't do anything
for me when I wasn't on the LAN.
Quote:> Several of our users use IMAP(S) for some years now because it allows
> them to use the same mail folder structure at work, from home and, on
> trips, through a webmailer (IMP mail). The reason to use IMAPS was the
> added features, not because the shared NFS mail spool would not work.
I never said NFS mailspool didn't work! Though I admit that I failed to
bring up the issue of mobile access - I should have and meant to - this may
have made it look like my "old hat" claim was based mainly on the issues
I did bring up: managing lots of vfstab's, etc.
Quote:> Some of our users download their mail to their laptops using fetchmail;
> this works much better with imaps or pop(s).
See, the NFS method *lacks features* that are needed by most of today's email
users. OLD HAT. (couldn't resist, sorry) :)
> > I can't comment much on the scalability of either, since the farthest
> > I've scaled either one is to about 250 users. However, my feeling is that
> > IMAP is more scalable and more easily managed.
> It depends on what you mean by "scale".
> Sharing /var/mail becomes unmanageable around 1000 machines and tends
> not to work across administrative boundaries. The protocol itself is
> fast, most of it is handled by the kernel and works even under heavy
> load; for most installations, mail traffic is only a fraction of the
> total NFS load.
OK. 1000 workstations means about 1000 users.
Quote:> IMAP, on the other hand, generates an imapd process on the server for
> each user (maybe there are implementations unbeknownst to me where this
> is not true); because of the way imap works this process hangs around
> between imap commands and uses memory. This is generally not a problem
> with 250 users, but it may become one with 2500 or more; in this
> respect, imap does not scale as well as NFS. With 25000 users that use
> IMAP to check for mail every 30 seconds, context switching, filesystem
> response and processor speed may become a problem; NFS is known to
> handle such loads gracefully.
OK, IMAP *may* become a problem at 2500 users. Hmm, 2500 > 1000 in my book.
I'm not seeing your point.
Quote:> With IMAP, passwords are a problem: many imap-aware mail user agents store
> clear-text passwords in rc files.
Which ones are those? None of the ones I or my users use are this stupid.
Quote:> IMAP delegates the problem to the and
> user (and away from the admin), but the end user may not be very
> knowledgeable about proper care and handling of passwords and may thus
> compromize security of the whole system.
Whole system? How is one user's compromised IMAP passwd going to effect the
Besides, my users don't get to pick their IMAP client, nor do they get to
set it up. That my team's job.
Since you bring up security, what about packet sniffers on the LAN? With email
flying in the clear, it would be pretty easy to see what the company president
is saying. With IMAPS (port 993) this is harder.
Look, I'm not trying to make a case against NFS. If that meets your needs, fine.
I'm just saying that most people need more than NFS mailspools can give these
days. I look at NFS mailspool and don't see anything it brings to the table
that IMAP doesn't.