Re: Building a mail server

From: Jeremy Gaddis (jeremy_at_gaddis.org)
Date: 07/30/03

  • Next message: Alan Shutko: "Re: Building a mail server"
    To: debian-user@lists.debian.org
    Date: 30 Jul 2003 16:05:57 -0500
    
    

    My highly biased opinion in favor of qmail and friends. Comments
    inline:

    On Wed, 2003-07-30 at 14:37, Jeffrey Hartmann wrote:

    > Requirements (mostly standard stuff):
    >
    > 1) maildirs - I've been told that maildirs is less CPU intensive since the MUA
    > doesn't have to scan through huge mailbox files. I also like that one mangled
    > message isn't going to corrupt a whole mailbox. The other option I was
    > thinking about was Cyrus or maybe find something that stores mail in mySQL,
    > but many people seem to talk badly about 'proprietary' mail storage formats.

    qmail uses Maildir exclusively. Maildir == good.

    > 2) virtual domain support
    > specifically I like the sendmail style virtusertable:
    > bob@domain.com: user1
    > @domain.com: user2

    vpopmail supports virtual domains and you can set catch-all accounts
    on the domain level.

    > 3) imap - Cyrus or Courier seem to be the current top contenders.

    Courier-IMAP is used here, supports Maildir (and possibly *only*
    Maildir, don't remember right off-hand).

    > 4) webmail - I like openwebmail, but it only does mbox mail spools.
    > Squirrelmail seems to be the most popular here.

    I use sqwebmail, personally. It's compiled C, reads email directly
    from Maildirs, has calendaring, GPG support... SquirrelMail can be
    used also, as it just connect to an IMAP daemon (a.k.a Courier).

    > 5) smtp auth - Sendmail had a patch/configuration option for this.
    > pop-before-smtp is an option, however I like the smtp auth method better.
    > It'd be nice if I could have everything behind SSL and still have it
    > compatible with the popular windows MUAs.

    qmail has patches available to make it support SMTP AUTH. I use
    POP-before-SMTP here, personally. With this method, the end user
    doesn't have to do any special configuration (which may result in
    more phone calls to you), you just have to tell 'em to retrieve
    their mail before they can send (which isn't really a problem, as
    most POP3 clients will connect as soon as they start up).

    > 6) pop3 - pretty standard, just needs to work.

    qmail comes with its own POP3 daemon, or you can use the one from
    Courier (like I do).

    > Now the optional requirements. These are things I would REALLY like to see,
    > but I could live without. So any suggestions that could get me the closest to
    > all of these is best.
    >
    > 1) Server based filtering, What I'm really looking for here is the ability to
    > sort all my mail by domain. So maindomain.com mail would end up in INBOX/,
    > but domain1.com mail would end up in INBOX/domain1.com/. This really ties to
    > the IMAP, as those are the folders I would be sorting into, and I'd like the
    > filtering to happen on the server so it's already filtered no matter what MUA
    > I'm connecting with. It could also be used for just general mail filters like
    > filters mailing lists to different folders. Right now I color code my
    > messages in OE so I know what mail server it came from, but I can't seem to do
    > that in IMAP.

    This is easily accomplished by "dot-qmail" files on the server. I
    use .qmail-* files for filtering mailing lists into separate Maildirs
    here. As an example, I'm subscribed to debian-user from debian-lists
    at gaddis.org:

    # cat .qmail-debian-lists
    /usr/local/vpopmail/domains/gaddis.org/jeremy/Maildir/.Debian/

    As you may or may not be able to tell, anything sent to debian-lists
    at gaddis.org gets delivered straight into the appropriate Maildir.
    Makes filtering waaaay easy, and gets rid of things like procmail.

    > It would be nice to be able to setup the filters from the MUA, but I'm
    > guessing thats going to be pretty rare or impossible to find. It wouldn't be
    > too horrible to have to do it manually from a shell, as the people using this
    > feature would be the more advanced users.

    Most MUAs allow you to filter client-side, but since I use different
    email clients depending on where I'm at (home, school, friend's house,
    etc.), I prefer to do it server-side.

    > Along this line also the POP3 server shouldn't distinguish between the
    > filtered mail and just kick it all out like a normal pop3 server. (The filter
    > could possibly add some X- header to signify the sorting for pop users.)

    I don't use POP3 personally, so I can't really comment on how it handles
    the separate Maildirs. POP3 is running and used here, but not by me or
    anyone that does any server-side filtering. Most people use IMAP (it's
    better anyways). :)

    > 2) virtual users. Currently everyone has thier own account on the system, and
    > mail is delivered according to the virtusertable. I have some family members
    > that don't really know how to use a shell account, so I'd like the ability to
    > not have to open that account for them. I'd rather have virtual users than
    > having to take measures to lock the account. So I would still need that
    > virtusertable functionallity, but it would have to be able to deliver to
    > virtual accounts as well.

    With the exception of myself and one other person, nobody who I host
    email for has a system account. Everything is managed by vpopmail.

    > 3) spam and virus scanning. This seems pretty trivial to implement. Mainly
    > I'd like to have the spam filters, but virus scanning is a plus as well.
    > SpamAssassian looks good, but I'm not sure if there are any virus scanners
    > that wouldn't cost too much for a small server like this.

    I have virus scanning implemented here, but not spam filtering (at the
    moment). SpamAssassin is a bit too much for my little mail server to
    handle, so it's currently disabled. The anti-virus software that I'm
    using is Clamav (open-source). It can be updated by its own auto-
    updating daemon or via a cronjob. I run the daemon here, which checks
    for updates every two hours. (SpamAssassin is easily integrated into
    all of this, but it's currently disabled).

    If you look at the headers on this message (assuming Debian's list
    software doesn't strip 'em out), you'll notice that I do virus scanning
    on outgoing as well as incoming mail. This prevents any of my users
    from sending out virii (which hasn't ever happened, but never say
    never.) :)

    > 4) fetchmail or something like it that could run globally for all users like
    > every hour and inject the messages into the maildir/IMAP. Again if I could
    > filter this so messages from myisp.com went into INBOX/myisp.com/ I would be
    > happy.

    Yep, I run fetchmail also, to retrieve email from a couple of "off-site"
    POP3 accounts for people who would rather it come to their account here.

    > At this point I know I'm going to have to change webmail systems, and I need
    > to decide on an IMAP server. Not even sure what's available for a server-side
    > filter, and what MTAs it's compatible with. Sendmail is the tried and true
    > proven system, but from what I understand it doesn't support maildirs, which
    > makes postfix look good, as postfix also seems very popular. Courier-IMAP
    > seems to be popular, but I'm not sure what the difference is between that and
    > Cyrus. The whole Courier mail system (mainly the MTA) doesn't seems to be
    > very popular in general, and I have yet to figure that out.
    >
    > So can anyone give me some idea of what they run, or suggestions of what to
    > use that could be configured to do a lot of this stuff? Ease of install isn't
    > really an issue, as I really don't have to do that very often. Ease of use
    > and maintenance is a big issue, as I don't want to have to go through a 50
    > step process every time I add a new user.

    Okay, so what is all this magical software I'm running, you ask? :)

    In a nutshell, qmail (SMTP), vpopmail (virtual domains/users), Courier-
    IMAP (IMAP/POP3), ezmlm-idx (mailing lists), tcpserver ({x}inetd
    replacement), clamav (anti-virus scanning), SpamAssassin (currently
    disabled), sqwebmail (webmail, obviously), vqadmin (add/delete/modify
    virtual domains), qmailadmin (add/delete/modify virtual users), and
    fetchmail (for bringing remote email to here).

    I might try in the fact that with this setup, you can delegate control
    for virtual domains to individual users, allowing them to manage their
    own virtual domains. For example, if you host email for your buddy
    Joe's "joe.com" domain, you can get him control of that domain, and
    he can log into qmailadmin and add/modify/delete virtual users, aliases/
    forwards, mailing lists, autoresponders, etc. (up to preset limits
    imposed by you, of course). The whole setup supports quotas too, so
    you can limit joe.com to, say, 100 MB of disk space.

    (Oh, and you can throw Apache-SSL into the mix also. The webmail
    and web-based management tools all run over SSL here.)

    I won't lie and say that all this is the easiest to implement. All
    of the software for the "virtual stuff" comes from inter7.com, however,
    and *everything* integrates *perfectly*. I haven't had a bit of
    trouble out of it since I set it up, FWIW. My mail server runs on
    FreeBSD, not Debian, but the software is still the same.

    If you're the type of person who wants to issue a few apt-get's and
    have a semi-working email server, this software is not for you. If,
    however, you have $clue and can read and follow directions, you'll
    have no problem getting this up and running. I spent roughly six
    hours going through the installation on a "test box" for the first
    time. It took me maybe two hours to get it working on the "real"
    server, though most of that was spent compiling.

    Total time spent working on the server since all this was installed
    (excluding software updates): nil.

    HTH.

    Sitting back and waiting for the flames for using qmail...

    j.

    -- 
    Jeremy L. Gaddis   <jeremy@gaddis.org>   <http://www.gaddis.org>
    -- 
    To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    

  • Next message: Alan Shutko: "Re: Building a mail server"