The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Tag: postfix

Adventures in Linux Mail

Posted in linux by Adam
Posted on

Just an overview of switching to a backend-based mail system for a single user on Linux.

For awhile I had been looking to shake up how I deal with e-mail. For a few years now I’ve used the Evolution mail client. It works pretty well, but for a few reasons I wanted a change.

Leaving Evolution

My reasons behind ditching Evolution (which I may still not do…read on) are twofold:

  1. It’s a gnarly beast, with a lot of things I never touch.
  2. It’s a bit slow in my experience. That means when I run it, and it’s checking mail, it’s basically unusable until the mail is retrieved. This is too much like a game of pool atop a near-frictionless plane, where you’re waiting for the ball to stop so you can take your turn.
  3. Instability. Nothing ever crashes on me. If it does, it must crash in a very friendly way. Several times in the past year, Evolution crashed in an unfriendly way. It’s not common enough to debug; it’s not reliably reproducible. It’s highly likely the direct culprit was not (solely?) Evolution, but the binary blob from nVidia.
    In any case, when you’re knee-deep in code and thinking hard (in the Feynman sense (Wikiquote: Richard Feynman: Quotations about Feynman)), a random crash demoralizes you.

    I’ve kept an eye on Geary, an up-and-coming GTK+ client, but it’s not yet in Debian and I’m not too adventurous with daily kit (or maybe I am…read on).

    Overheard on the Internet

    So I happened to see a recent discussion about Linux mail clients; someone looking for suggestions. For whatever reason it caused me to consider using a local webmail client.

    I dug around and looked at the offerings, and for now I’ve settled on RoundCube. But it’s not that simple. RoundCube, and probably similar webmail clients, are just frontends. A frontend without a backend makes no sense.

    And that’s where the fun begins.

    Backending a Mail Client

    So the good news about the ordeal of gluing together your own mail system out of:

    • Mail User Agent (MUA) [Frontend]
    • Mail Submission Agent (MSA) [Backend]
    • Mail Transfer Agent (MTA) [Backend]
    • Mail Delivery Agent (MDA) [Backend]
    • Mail Retrieval Agent (MRA) [Backend]
    • 3,4-methylenedioxy-N-methylamphetamine (MDMA) [Oh]

    The good news is that now that it’s done, I could keep using Evolution with it. I can use Icedove (Thunderbird on Debian). I could also move my mail gathering to a home server, and have my local IMAP client get the mail from there.

    In my case the backend is currently:

    This set was arrived at after a bit of research and stumbling.

    Stumbling with Exim4, Dovecot-lda, and Migration

    These were my two stumbling blocks.

    Exim4 is just a big bucket of fun, but a bit complex to configure for my needs. I had been using it for some time, merely as a local-only MSA/MTA/MDA. That is, to accept mail from local parts like Cron and add them to my local mail.

    I spent a bit of time trying to reconfigure it for my new backend, but quickly decided it was more trouble than it was worth and decided to use the simpler-to-configure Postfix.

    With dovecot-lda, the problem was permissioning. But from what I could tell I would have to overextend the permission for users (by adding them to the mail group) in order to get it to work. From there I realized getmail doesn’t actually need a MDA, but only if you want the mail to go in a single folder.

    I want some mail sorting (which may be possible with Dovecot‘s Sieve implementation; haven’t looked too hard yet) and Procmail fits the bill for that nicely.

    The final thing was to migrate my mail to the location Dovecot uses. This would have been almost unnecessary if both Dovecot and Evolution were both using the same mail format. I went with mbox for Dovecot, but that was probably a mistake I’ll have to amend later. I ended up using doveadm import to migrate, but there are other options like dsync and strict copying of files, depending on what you’re migrating.

    What’s Left to Do

    My setup works nicely, but I haven’t yet fully-integrated Spamassassin. I’ll do this once I see a lot of spam coming in. Most of my mail providers already eat most spam for me.

    I also setup mail forwarding on a few seldom-used accounts simply to reduce the amount of configuration.

    As I mentioned above, another thing I’ll get around to, moving to Maildir instead of mbox. The former is probably a little more efficient, and has less dataloss potential in the event of a corrupt file (rare anyway, but every bit helps).

    It’s worth pointing out that clients like Evolution and Icedove make setting up a lot easier. A setup like the one I’m describing could be made simpler if you knew which components were in use and had some extra code to help the process along, or if such a program were modular, it could export the proper configurations for each part.

    In reality, few enough people want this type of mail setup that the extra work isn’t a big deal.

    Conclusions

    I would include sample configurations here, but 99% of the work came from default configurations and examples from the various documentation for the various components. If anyone wants any specific detail, I’ll be happy to include that.

    I’m pretty happy with this new setup, using RoundCube for my client for now.