qmail to exim migration (thoughts and not commands)

qmail to exim migration (thoughts and not commands)

I’ve using Qmail since 2013 and it was a great companion. I’ve added so many custom scripts in it(or in this ecosystem) that it will take me days just to write about it.
Unfortunately for some time already I’ve started to feel the end is near for Qmail.  Here is way(just few of them):

  • A lot of packages are not maintained or things are maintained by different group of people who don’t use the same patches as you.
  • It’s becoming really hard to keep track when you install a new server which patch to apply and at which step(for example i used tap patch but this is rarely used).
  • Often you need to understand and adapt the patches to your situation because some might include(partially or fully) other patches that you need also to apply. Basically in the end you start to write your own set of patches which obviously contains pieces of code from there of there. If you forgot something it might break or not work as intended.
  • Quite often as well you need support for new technologies and there fewer and fewer people who want to support this.
    For example: if you want ipv6 there is a way via fehQlibs, ucspi-tcp6 and ucspi-ssl but there is no clear indication this will work as intended from the beginning with your own version(i mean your own set of patches) since the owner has his own Qmail version named s/qmail.
  • After a long ride with qmail-scanner i went to simscan. This one can support only spamassassin and clamav.(or you start coding at it as well). For most of you it will be enough but if you want better antivirus(yes, commercial) than you’re out of luck. Yes, clamav-unofficial-sigs might give you  a great boost but it might not be sufficient if your client wants the best.


Why Exim ?

Simply because is highly configurable, is popular and you find tons of information. This flexibility might come with a price but at least those are “hopefully” treated fast.
For example i really liked qmail-spp patch and i heavily used(unfortunately this patch is again not included to a lot of different qmail projects available on the market) with a lot of perl scripts and the same principals can be used in exim acl which is great.

Learning curve to exim might be hard. Because of that I’ve encourage you to use in the beginning and old but good ecosystem named exim4u.
You will definitely need to add/modify ACL protections, to change the behavior of the DKIM for forwarded messages(because the default exim4u install want to sign also the forwarded messages which is wrong) and things that you will “learn by doing it”. Again, it’s far from perfect but it’s a great start and i recommend it.

Things not to miss on your migration:

– Compile exim with the support for maildir. In this way you can keep the same structure that you had with vpopmail.(keep in mind that exim4u for you use Maildir instead of .maildir directory so you need to tune a little bit the php files if you use the GUI to create domains/emails/etc.)
– Migrate the users from vpopmail database to exim4u database – i suggest to make your own scripts to do this. Doing it manually it’s taking too much time.
– Don’t forget about greylist db ; exim4u use sqlite3 in /var/spool/exim/db/greylist.db. You need to create the file and the tables.
– Don’t forget to change in dovecot(or the IMAP app used) to use the new database
– If you are using an webmail adapt it and his plugins(for example: if you are using Roundcubemail with password plugin you need to change to reflect the new sql/db)
– If older clamav version is used you might need to use AllowSupplementaryGroups but this should not be case for version above 0.100.(they just announced version 0.103 RC)
– migrate the TLS (server.cert, server.pem)
– migrate the DKIM certifications
– as I’ve already mentioned several times above, exim4u is far from perfect but from my point of view it has a really nasty bug IF you are (still ???) using not encrypted passwords. Please check how eq and crypteq are used in server_condition. More info on the exim manual.

2 Replies to “qmail to exim migration (thoughts and not commands)”

  1. Hi,
    using your own set of patches for any (open source product) is not a good choice IMHO.
    s/qmail does not need the qmail-spp patch. It provides those functions out of the box.
    Of course, any new product has its strong learning curve. (–eh).

    1. Thanks for writing. I am not an expert on s/qmail and if i said something which is not true I prefer to that everyone will raise a flag and i will correct it asap.
      Now, regarding s/qmail and qmail-spp functionality i usually use my own scripts/logic on different stages.
      Just some examples:
      1) i want to reject connections if HELO/EHLO is not RFC2821 and i want to do this as soon as possible ( connection/helo stage)
      2) for some reasons (maybe better logging) i will temporary move the same on the [mail] stage or even when [rcpt] is presented.
      3) maybe i don’t want to use RBL on connection because i want better logging (ex: who send to whom, etc)
      4) maybe based on some other checks executed on earlier stages i want to tarpit / greylist / whatever before going further.

      Those can be easily achieved in exim and even with qmail/qmail-spp. If you said that you can implement the same with s/qmail than i am very happy to hear and i will obviously change what i wrote months ago.

      Btw, do you plan to include it in distros where anyway software is compiled when install ? (ex: Gentoo )

Leave a Reply

Your email address will not be published. Required fields are marked *