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]

Speaking of mail etc



On Thu, 2003-07-24 at 15:28, miah wrote:

[snip]


> So my vote is for postfix.  The postfix team has designed a great and
> secure MTA.  The only reason I'd run sendmail is if I wanted to get
> owned.

  Dem's fightin' words, bud.  ;-)  Just kidding.  I agree that sendmail
has quite the sordid security history, but for over four years there
were no remotely exploitable security holes in it.  It wasn't until
earlier this year that two more cropped up.  I'd say that's a pretty
darned good *recent* track record given how many security
vulnerabilities are reported for many Free Software packages these days.
  That said, to each his own.  I've no real bias other than the fact
that I know sendmail really well and know how to lock it down.  I've
been running it for many years and, as far as I can tell, have never
been owned.  Unless the one who's owned me is hiding really good (I
check for problems often.)

> For IMAP, I've used courier and cyrus, courier is much easier to
> setup/configure.  It works well with users that want to login and
> check their mail with pine.

  I'd caution against courier for anyone who uses multiple IMAP
clients.  The lead developer of courier has a penchant for not
implementing standards according to RFCs he believes are broken.  Nor is
he willing to participate in the standards process to fix the standards
he believes are broken.  It's not a criticism, just a note to be aware
that you will likely encounter some problems with email clients that
follow the RFCs strictly in the areas where courier doesn't.
  Of course, even if unintentional in other IMAP servers, you may run
into a different set of problems regarding standards.  *sigh*

>   CYRUS is great too, but it stores all the mail in its own
> proprietary db format, which means users logging in to check mail will
> be out of luck.  Maybe you can configure around that now, but thats
> how it worked last I checked

  Well, I wouldn't exactly call Cyrus' database proprietary.  After all,
the source code *is* available.  But I think understand your point.  It
'sorta' uses the maildir format.  Most cyrus users are not likely to run
into the problem above because the typical way of running cyrus is as a
sealed server: users don't have shell accounts (nor do they need them)
on the mail server.  They must access mail via IMAP (or POP if it's
enabled).
  It does requires a bit of work to configure.  I highly recommend Simon
Matter's rpms available at http://home.teleport.ch/simix/ as src rpms. 
Grab the cyrus-imapd-2.1.14-4.src.rpm file and run 'rpmbuild --rebuild
cyrus-imapd-2.1.14-4.src.rpm' on it.  (You'll need to run that as root
unless you set up a .rpmmacros file in your home directory to change the
location of various directories.)
  Cyrus is a bit overkill if you are the only user, but it's worth
setting it up for the learning process alone.  I'm using it for myself
and my brother and haven't had any issues with it, even when switching
between various mail clients (mozilla, evolution, kmail, mutt have all
connected and listed all my mail messages and folder list fine).
  For the original poster, I think the components you listed are a good
selection: postfix, cyrus-imapd, and squirrelmail.  I've set up STARTLS
and SMTPAUTH with sendmail, but I believe it's possible with postfix as
well.  My only gripe with squirrelmail is it's claim of modularity when
every time I grab a module that I want to incorporate, it seems that
some core (php) source file gets modified as well.  That ain't modular
and causes grief when you need to update the core squirrelmail due to
some security hole.  If you don't use any of the add on modules, you
should be fine.  I was just a little annoyed because I started using it
specifically for the sieve module and then I discovered how unmodular it
really was.


-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets





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