Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Mail Servers



My $.02 on the mail server topic:

- I've been using sendmail approximately since the dinosaurs walked the earth.
 The rate of bug-fixing for most software trends downward over time.  Sendmail
seems to remain constantly buggy year after year after decade.  The Chicxulub
comet has yet to hit, but someday sendmail will hopefully be taken out back
and shot.

- When I upgraded to sendmail 8.12.10 Thursday night, I experienced a silent
failure of all outbound mail.  Somehow the previous 8.12.9 config worked, I
have no idea why, despite the fact that on 9/1 Suse 8.2 installed a submit.cf
file that didn't match (at all) my custom confiugration.

- Somebody needs to invent a robust regression-test for MUA and MTA software
configurations.  Then it won't be so frustrating whenever the obligatory CERT
patches come out every 6 days.

- If the rate of software patching keeps up at this rate, ISPs are lockly to
block port 25 as aggressively as they do port 135 (the Windoze file-sharing
port).  Then we'll all have to forward our email through a server farm located
in John Ashcroft's basement.  The question of running one's own mail server
will be a moot point.

- Even if sendmail does get put out of our collective misery, black-hat
hackers are going to continue to find bugs in any software that becomes
popular for listening on SMTP port 25.  I refuse to believe any of the
alternatives are fundamentally less-buggy than sendmail, at this date, given
their limited operational maturity.

- I suspect the comments about UW imap are on-target.  I've had a little
flakiness in my own system, even though it's essentially standalone and
shouldn't suffer resource-contention issues.

- Since my prefered email MUA for searches is emacs, I vastly prefer Unix mbox
format so I can search email quickly & easily, and can move folders around in
an archives quite easily.  The maildirs format strikes me as cumbersome. 
Perhaps I'm old-fashioned?  I'd love to see some arguments from folks who have
made the switch from mbox to maildirs.

- For those of you thinking of setting up email for an office, consider
Squirrelmail running under Apache with secure-HTTP.  Users can then get access
from anywhere and there is practically no administrative headache.  And since
it runs over imap, users can select any alternative MUA that supports imap, if
they prefer that to the Squirrelmail interface.

- Another tool to consider is gotmail.  A user who wants to collect mail from
a variety of services into a single mailbox may need a server-based tool like
this.  The problem this addresses is that services like hotmail don't support
email forwarding (for marketing reasons, not technical ones).  You have to
configure a server to poll the remote mailboxes periodically.

- SpamAssassin works well on any Linux box with any MTA.  And if you install
MySQL with it, you can provide an interface for users to manage their
whitelists from within Squirrelmail.  (However, I did have to code my own
address-book--the built-in address book isn't integrated into spam checkers.) 
You don't need MySQL if your users can handle editing a userpref file from the
Unix comand line.

I have thought of packaging a canned mail server that contains all the tools
I've tweaked, and making it available somehow.  But it would take a lot of
work to keep it maintained--seems like a business rather than a hobby pursuit
(I would need to develop the QA suite mentioned above).  Anyone done any
software distribution lately?  Does it manage to at least pay for itself?

-rich





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org