On Wed, 8 Nov 2006, Brian Thompson wrote:
I guess that's what confuses me... I'm not seeing how a server can simply
be an imap server.
That's a good question, and all too easily overlooked by those of us who
resolved it years ago.
The email needs to get onto the server somehow (in
our case sendmail/mail.local). In the delivery process there might be
additional milters in use (in our case Spam Assassin and ClamAV). Then
at the user level there are email related dot files for those who choose to
play with their forwarding (.forward), vacation messaging (.vacation*), or
additional filtering (.procmailrc). We would prefer that all users have open
shell access in order to personalize their email configuration/make changes
to their dot files if desired.
As Nancy Lin suggests, the answer is to split the services. At UW, we
have separate:
. SMTP servers for incoming messages. These servers do not require
authentication, but also do not relay; they only accept inbound UW
traffic.
. SMTP/submit servers for outgoing messages. These servers require
authentication and relay.
. IMAP servers
Looking at the broad picture, an incoming message hits one of the incoming
SMTP servers. Any SMTP-level processing, including such things as RBLs,
is done there.
Whether the message is virus/spam-scanned at the incoming SMTP server, or
if that is passed to yet another server, all depends. The higher your
load, the more that you want to have multiple servers taking on pieces of
the overall problem.
Once the message has been accepted and spam/virus-scanned, it is then
dispatched to the appropriate destination IMAP server. The mechanism by
which this is done can vary; you may use SMTP (perhaps over a path that
only the incoming SMTP servers can use), or something like LMTP, or some
private mechanism. You don't want spammers being able to SMTP to the IMAP
servers...
There is no particular reason why your incoming SMTP servers/virus
scanners can't have access to the users' file home directories for things
like .forward, .procmailrc, .vacation, etc. The cautionary note is that
you need to consider what happens if there is an NFS fault during mail
delivery, and that fault is interpreted by mail delivery as meaning "no
.forward, etc. exists". If, on the other hand, you allow a fault to block
until the fault is resolved, that can hang your incoming mail facility.
However, as Nancy also suggested, users these days are much more
accustomed to using web based tools to configure these things, and the
traditional UNIX files such as .forward, .procmailrc (especially
.procmailrc!!), and .vacation just confuse them. We live in a different
world, as appalling as it may be for us "old farts".
Part if the advantage to using UW imap over Cyrus for example is that it's
not a black box and plays well with the rest of the software that might or
might not be installed. We're still using pine in traditional unix mode, so
that's what I was thinking when I used pine as an example. Forgot that it
can also be used as an imap client.
The advantage of playing well with traditional UNIX mail software makes
for easy deployment for small sites, and I agree that this is an advantage
of UW imapd.
However, for large sites, you have to give up interoperability with
traditional UNIX mail software. UW imapd lets you do it gradually and
incrementally, while Cyrus forces the issue.
Traditional UNIX mail software was designed in a time when a large mailbox
was a few hundred Kbytes and the network was largely spam-free. Today's
world is very different.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
