Very Computer

... that is the question.

Assuming a homogenous Sun/Solaris environment, what are
people's opinions of NFS mounting /var/mail on workstations,
as opposed to using IMAP to read one's email.  Assume that
all workstations are on the same LAN.

How scalable is either solution?

TIA,

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

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!) .

One thing that was always a pain with about a billion clients mounting
the mail spool is the potential for stale mounts on the clients if you
were to make some change, like move the mail spool to a different disk
on the server, or change the server's IP address, hostname, etc. You had to
go around unmounting before the change, and remounting after. Or, if the
change was unplanned (like in an emergency) you got to go around and reboot
a lot of sick machines.

I suppose I could have used the automounter to mount the mailspool, and
this would have made some stuff a little easier, but since even with the
automounter, the mailspool tends to stay mounted anyway (biff and friends)
I never got motivated enough to try it.

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.

--
Griff Miller II                   |                                           |
Manager of Information Technology | For every problem, there is a solution    |
Positron Corporation              | that is simple, neat - and wrong.         |

That's the way I am now.

Quote:> One thing that was always a pain with about a billion clients mounting
> the mail spool is the potential for stale mounts on the clients if you
> were to make some change, like move the mail spool to a different disk
> on the server, or change the server's IP address, hostname, etc. You had to
> go around unmounting before the change, and remounting after. Or, if the
> change was unplanned (like in an emergency) you got to go around and reboot
> a lot of sick machines.

Good points.  I guess I'll stick with IMAP, unless someone has a
strong argument not to do so.

Thanks,

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

apart from security issues - if someone breaks a workstation
they get to abuse /var/mail - there are probably good nfs locking
reasons not to export this.

we've tried both - in a technical sense i suppose it'll scale
but IMHO it is not a good idea and much better to leave it local
to a machine and export that data via IMAP.

regards,

-jason

Quote:> 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.

We have used shared NFS mail spools for 12+ years in environments of
ca. 100 machines and 250 users with only very occasional corrupted mail
spool files. Our users use probably 15 different mail clients, but most
of them do not use e-mail a lot (ca. 20 incoming/5 outgoing msg per day
and user on avg.), the users are relatively well educated and probably
half of them know that file locking is advisory on Unix. Some of our
user's favourite mail user agents have only recently learned about
imap.

We also use this in a mixed Solaris, Linux, AIX, HP-UX, Tru64
environment; we made sure all mail clients are *not* suid mail,
/var/mail is 1777 and each maildrop is mode 0600. We mount /var/mail
from the mail server via a direct automount map with
"-noac,nosuid,actimeo=0".

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.

Some of our users download their mail to their laptops using fetchmail;
this works much better with imaps or pop(s).

Quote:> 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.

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.

With IMAP, passwords are a problem: many imap-aware mail user agents store
clear-text passwords in rc files. 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.

 - Andi

[...]

Quote:> Good points.  I guess I'll stick with IMAP, unless someone has a
> strong argument not to do so.

I'm curious (as I don't have any experience with IMAP): Given the IMAP
solution, how would users go about setting up client-independent mail
filters (e.g. procmail)?

Cheerio,

Thomas

Quote:> ... that is the question.

> Assuming a homogenous Sun/Solaris environment, what are
> people's opinions of NFS mounting /var/mail on workstations,
> as opposed to using IMAP to read one's email.  Assume that
> all workstations are on the same LAN.

NFS is useful for jumpstarts - thats about it : >

Quote:> How scalable is either solution?

No limit other than cost for IMAP.. But using /var/mail and huge user
unmaintained INBOXes (like THAT never happens right?) can bog things
down, so youd have to re-engineer with, say, iPlanet for example which
is what I would call scaleable : > Than again you could pony up for
an Auspex : >

Thomas,

depending on which IMAP server you are using, it's eather easy, or a
little difficult, to get procmail working correctly...

UW-IMAP was a little * to setup correctly, as you have to manually
edit the source code to enable certian options, but once it's done, it's
done...

Then you need to setup sendmail to use procmail as a mail agent...

Then you need to download and compile dmail, which is located within
this package:

ftp://ftp.cac.washington.edu/imap/imap-utils.tar.Z

There are some other useful utilities there too...  Take a peek at them...

Then all of your procmail recipies need to do the following to filter
messages correctly:

:0:
* ^Subject.*invest
|/usr/sbin/dmail +spam

The above is assuming you compiled imapd to use the mbx format, and all
of your mailboxes were created correctly...

And the biggest hitch of them all, all of your users need to have their
own home directories to set up their procmail filters...  That's
probably the biggest "political" issue there, apart from the technical
issues of even getting it working in the 1st place.

;-)

I have no experience with other imapd servers, so I can't begin to tell
you if they will work with procmail or not...

Ricardo

NFS mounting the mail spool in a pure Unix environment is still an excellent
solution.  I think that IMAP/POP came about due to MicroSquid failing to come
up with a PC mail solution that was capable of using the mount, no NFS,
the ISP world, etc.  NFS still works great in a LAN environment that is
M$ free.  I think that either will scale well, so I don't think that will be
an issue.

Quote:>One thing that was always a pain with about a billion clients mounting
>the mail spool is the potential for stale mounts on the clients if you
>were to make some change, like move the mail spool to a different disk
>on the server, or change the server's IP address, hostname, etc. You had to
>go around unmounting before the change, and remounting after. Or, if the
>change was unplanned (like in an emergency) you got to go around and reboot
>a lot of sick machines.

If you are running Volume Manager (Veritas, or the older Sun version) then
this will not be a problem.  In a VxVm environment, the major/minor of the
mounted device is that of vxio, and the volume name itself. The physical
devices that underlie the volume are never directly seen.  As such, you can
resize, move, whatever the data with no ill effects on NFS.  We do failovers
from host to host this way, and you don't even have to have the controller
numbers/types match to work (although we do, as a matter of good practice.)

Quote:>I suppose I could have used the automounter to mount the mailspool, and
>this would have made some stuff a little easier, but since even with the
>automounter, the mailspool tends to stay mounted anyway (biff and friends)
>I never got motivated enough to try it.
>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.

I have had different experiences.  The level of complexity to get IMAP/POP type solutions to work is far greater than a simple mount, and although we finally
have it clean, stuck locks, etc. seem to plague the IMAP/POP "stateful" world.

- Tim

--
================================================================================

D-Tech Corporation                                  Voice: (972)-567-9360
Dallas, Texas 75252                                 FAX:   (972)-221-0393
"The world is complex. Sendmail.cf reflects this...."

Quote:> depending on which IMAP server you are using, it's eather easy, or a
> little difficult, to get procmail working correctly...

[...lots of interesting information snipped...]

Thanks a mil! That's lots to think about and experiment with... :-)

Regards,

Thomas

Quote:> Thomas,

> depending on which IMAP server you are using, it's eather easy, or a
> little difficult, to get procmail working correctly...

> UW-IMAP was a little * to setup correctly, as you have to manually
> edit the source code to enable certian options, but once it's done, it's
> done...

> Then you need to setup sendmail to use procmail as a mail agent...

> Then you need to download and compile dmail, which is located within
> this package:

> ftp://ftp.cac.washington.edu/imap/imap-utils.tar.Z

> There are some other useful utilities there too...  Take a peek at them...

> Then all of your procmail recipies need to do the following to filter
> messages correctly:

>:0:
> * ^Subject.*invest
>|/usr/sbin/dmail +spam

> The above is assuming you compiled imapd to use the mbx format, and all
> of your mailboxes were created correctly...

> And the biggest hitch of them all, all of your users need to have their
> own home directories to set up their procmail filters...  That's
> probably the biggest "political" issue there, apart from the technical
> issues of even getting it working in the 1st place.

> ;-)

> I have no experience with other imapd servers, so I can't begin to tell
> you if they will work with procmail or not...

Here's the start of my ~/.procmailrc using a setup pretty much as
described.  The comments assume UW-imapd, not some other like CMU's.
The rest of the file is just more three-line stanzas to deal with
stuff destined for other files.  Each stanza includes comments identifying
the purpose, so that I have some clue why I did what I did (I suppose
if I'd been really wild, I could've also put the unsubscribe address for
each mailing list in as a comment, so I'd remember just how it needed to
be).  Note the use of variables for $DMAIL and such; this makes later
changes (like switching to an alternate version of dmail) easy.

PATH=$HOME/bin:/usr/bin:/usr/ucb:/bin:/usr/local/bin
MAILDIR=$HOME/Mail      # You'd better make sure it exists
DEFAULT=$ORGMAIL        # Note: if $HOME/INBOX exists in mbox format,
                        # imapd will auto-snarf to there from spool file,
                        # otherwise it will leave mail in spool file.

# All other mail boxes should be delivered to via $DMAIL, which will do
# the right thing with various existing mailbox formats.  This allows
# future conversion to mailbox formats that are more efficient or
# support concurrent access.
# Note:  lockfiles have .LOCK suffix because dmail uses .lock suffix and
# there's no way to hand off the lock.

LOGFILE=$MAILDIR/misc/procmail.log
DMAIL=/usr/local/bin/dmail
LOCKSLEEP=5
LOCKTIMEOUT=600

:0:$MAILDIR/shuttle.LOCK        # Anything from shuttle-status mailing list

|$DMAIL +Mail/shuttle           # will go to $MAILDIR/shuttle

--

Procmail is one way. However, if your users are not that techinically
inclined it may be difficult for them.

One way to do it is to set up a webmail interface. SquirrelMail [1]
is one where using a web browser a user can set up filters very
easily. This is of course not client-independent - your client is
SquirrelMail.

[1] http://www.squirrelmail.org/

--
David Magda <dmagda at ee.ryerson.ca>
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

What do mean? Don't you install from tape?! :>

Quote:> No limit other than cost for IMAP.. But using /var/mail and huge user
> unmaintained INBOXes (like THAT never happens right?) can bog things
> down, so youd have to re-engineer with, say, iPlanet for example which
> is what I would call scaleable : > Than again you could pony up for
> an Auspex : >

In IMAP, deleting a message doesn't (necessarily) delete it. You have
to "expunge" it.

--
David Magda <dmagda at ee.ryerson.ca>
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

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)   :)

Quote:> > 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
whole system?

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.

Griff

I'll give you that, so long as there's no requirement for mobile/remote access.
(I forgot to talk about mobile access in my OP)

Quote:> I think that IMAP/POP came about due to MicroSquid failing to come
> up with a PC mail solution that was capable of using the mount, no NFS,
> the ISP world, etc.  NFS still works great in a LAN environment that is
> M$ free.  I think that either will scale well, so I don't think that will be
> an issue.

Let's get one thing straight: IMAP != POP .

There's more to it than what you say. The need for the same "view" of one's
email folders from multiple locations is what drove IMAP into existence.

However, if you restrict the above comments to POP, I'll be more inclined
to agree with you.

Quote:> >One thing that was always a pain with about a billion clients mounting
> >the mail spool is the potential for stale mounts on the clients if you
> >were to make some change, like move the mail spool to a different disk
> >on the server, or change the server's IP address, hostname, etc. You had to
> >go around unmounting before the change, and remounting after. Or, if the
> >change was unplanned (like in an emergency) you got to go around and reboot
> >a lot of sick machines.

> If you are running Volume Manager (Veritas, or the older Sun version) then
> this will not be a problem.  In a VxVm environment, the major/minor of the
> mounted device is that of vxio, and the volume name itself. The physical
> devices that underlie the volume are never directly seen.  As such, you can
> resize, move, whatever the data with no ill effects on NFS.  We do failovers
> from host to host this way, and you don't even have to have the controller
> numbers/types match to work (although we do, as a matter of good practice.)

Oh, yes, and everyone runs VxVm. (ouch! I rolled my eyes too hard)

:)

Quote:> >I suppose I could have used the automounter to mount the mailspool, and
> >this would have made some stuff a little easier, but since even with the
> >automounter, the mailspool tends to stay mounted anyway (biff and friends)
> >I never got motivated enough to try it.

> >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.

> I have had different experiences.  The level of complexity to get IMAP/POP type solutions to work is far greater than a simple mount, and although we finally
> have it clean, stuck locks, etc. seem to plague the IMAP/POP "stateful" world.

> - Tim

Take POP out of the discussion. We're not talking about POP.

I suppose it depends on which server and clients you use, but in my opinion,
IMAP is dead simple to set up. Especially after the first user is done.
It might not be as simple as the NFS spool, but criminy! it has more
features, that most people need and can put to use. It's not like IMAP
capabilities are needed by some fringe group.

Griff