Getting a new server

Ted Mittelstaedt tedm at
Sat Feb 4 00:54:30 PST 2006

>-----Original Message-----
>From: owner-freebsd-questions at
>[mailto:owner-freebsd-questions at]On Behalf Of Chad
>Leigh -- Shire.Net LLC
>Sent: Friday, February 03, 2006 11:19 PM
>To: Lisa Casey
>Cc: Free BSD Questions list
>Subject: Re: Getting a new server
>On Feb 1, 2006, at 9:56 AM, Lisa Casey wrote:
>> Hi Gabor,
>>> I'd suggest using courier-imap or something else instead of
>>> qpopper. Afaik, qpopper supports only the mailbox format, which is
>>> slower and less secure than the maildir format used by modern pop3/
>>> imap servers. Courier-imap has a pop3 and an imap part, both of
>>> them have SSL support and are easily configurable. Your company
>>> migth benefit from running an imap server too. It has a bunch of
>>> advantages over pop3, so this might make your users feel more
>>> appreciated.
>> I agree you have a pointg here, my main concerns are:
>> 1) I'm used to Sendmail/Qpopper. I'm used to installing these,
>> maintaining these and troubleshooting these. I also want changing
>> over the mail server to be as seamless as possible for our
>> customers. So I don't really want to add a Courier-imap learning
>> curve (for both myself and my customers) right on top of things.
>It is easy and the customers don't have to know you made the change.
>They still access everything over pop the sme way they always have.
>I made the change about 4-5 years ago and no-one knew the difference.
>> 2) I also am used to (and kind of like) having all of the mailboxes
>> in one location on the system (/var/mail/). How much of a
>> performance hit is there in mbox mailboxes vs mdir format mailboxes?
>You can do that.  maildir uses a dir as a cirtual mailbox so you
>would have (in a simple case -- you can make it more hierarchical)
>where user1 and user2 and userN are all dirs instead of monolithic
>files.  maildir has the advantage that you can easily go in and fix
>issues in a users mailbox without disturbing the single monolithic
>file, which no longer exists.
>courier-imap (which supports both pop and imap in the package) can be
>configurede to put your mail anywhere you darn well please.

I frankly think a lot of this concern is redicoulously overrated these
Modern disks and hardware being what it is, compared to the speed of
the network that the users are tied to the server with, pretty much means
your going to get the same performance out of a maildir or mailbox
I have one mailbox for example, that is accessed via IMAP, that has over
16 THOUSAND messages in it.  (the max displayable limit of e-mail
messages in Outlook is 16384, by they way)  This is mailbox format and
access to this box is production-quality speed.

Having a hierarchical directory structure was much more of a concern
ago but FreeBSD has directory caching built in now and doesen't suffer
scanning large directories.

A much more important issue with e-mail is the issue of supporting IMAP.

If you are an ISP and your users are NOT demanding IMAP (ie: they are a
bunch of home endusers) then qpopper/sendmail combo is perfectly fine
and will kick ass.  It also has a big advantage in that it makes the mail
directory self-cleaning.

But if your users are corporate types with a need for multiple accesses
their mailbox (webmail for example) then you need to get into IMAP.

Furthermore, we stopped doing the "go into users mailbox and fix issues"
a while ago because of support concerns.  Today, if a user's mailbox gets
corrupted and they call in, I make them to go into our Horde/IMP webmail
interface and clean their own damn mailbox out.  I don't have time for it
IMP has never failed to digest the most corrupted mailbox imaginable.
once they learn how to do it themselves, the next time it happens they
don't call in, they just fix it themselves.  Given a choice most users
would much
rather know how to fix it themselves rather than call us anyway.  Some of
like IMP enough so that they give up Outlook or whatever and just use the
webinterface all the time, which suits me fine.


More information about the freebsd-questions mailing list