Courier-MTA as alternate mailserver

Discussion in 'General' started by markc, Apr 8, 2013.

  1. markc

    markc Member

    Most folks would be familiar with courier-imap as one of the pop/imap servers available for ISPConfig but not many folks have used the associated courier-mta (mail transfer agent) mailserver instead of postfix. I've used courier-mta for 10 years and only now just started using postfix because it's the only option with ISPConfig. I miss courier-mta so I am just wondering if anyone else using ISPConfig would like to see courier-mta as an alternate mailserver option?

    The latest version of courier-authdeamon can use SQLite as a backend which I would find useful on a small VPS (postfix can too) but the most amazing feature of courier-mta is that it can use real vhosts on separate IPs. I mean totally separate domains can be delivered from courier-mta where the sending IP *AND* the initial EHLO hostname can be configured for an unlimited number of domains on the same host. postfix can kind of emulate this and send from a different IP on the same server but it can't provide a different EHLO hostname without running separate instances of postfix per virtual domain. A courier-mta vhost is completely transparent to the receiver, they cannot tell by looking at the delivered mail headers that this message came from a virtual host and SPF works perfectly.

    This is quite useful, aside from "vanity" vhosts, in that if one clients mailserver gets blacklisted then it doesn't also blacklist all other clients on the same server. Plesk has a trick for doing this for exactly this reason but, as I mentioned, postfix still uses the EHLO hostname from the main server, not the vhost.

    So fully independent multihosted mailservers of interest to anyone?
  2. markc

    markc Member

    FWIW I have now upgraded (IMHO) 2 servers from postfix+dovecot to a full courier-mta+imap system and so far I haven't noticed any drawbacks in day to day usage. I expect some problems when upgrading ISPConfig because it's scripts expect postfix to be installed and in my case I had to remove the postfix package altogether so Ubuntu would install the courier-mta package. A workaround may be to simply leave a copy of /etc/postfix (and maybe some other) directories so the upgrade just thinks that postfix is still available.

    The main reason for me to bother is that I was not happy with the default spamassassin spam filtering system and not being familiar with it, or postfix in general, it was easier and quicker for me to install courier-mta and use it's maildrop local delivery agent with Dspam to get near 99% effective spam filtering.

    On Ubuntu (13.04) this is the magic glue that makes it work with the ISPConfig MySQL auth tables, /etc/courier/authmysqlrc...

    MYSQL_AUXOPTIONS_FIELD  concat('disableimap=',disableimap,',disablepop3=',disablepop3)
    MYSQL_CRYPT_PWFIELD     password
    MYSQL_DATABASE          dbispconfig
    MYSQL_GID_FIELD         gid
    #MYSQL_HOME_FIELD       homedir
    MYSQL_HOME_FIELD        maildir
    MYSQL_LOGIN_FIELD       login
    #MYSQL_MAILDIR_FIELD    maildir
    MYSQL_PASSWORD          x33c6ee08c6e22e7e56619828179c7fx
    MYSQL_PORT              0
    MYSQL_QUOTA_FIELD       concat(cast(quota as char),'S')
    #MYSQL_QUOTA_FIELD      quota
    #MYSQL_SERVER           localhost
    MYSQL_SOCKET            /run/mysqld/mysqld.sock
    MYSQL_UID_FIELD         uid
    MYSQL_USERNAME          ispconfig
    MYSQL_USER_TABLE        mail_user
  3. till

    till Super Moderator Staff Member ISPConfig Developer

  4. markc

    markc Member

    Excellent, thanks. I should try this out. The project has moved to Github...

    One thing I am concerned about, in general, is ram usage and both amavisd and spamassassin use a lot of ram and even though the virus checking is useful for windows based clients I find spamassassin sucks at filtering out spam with it's "Normal" setting (I'm not sure what the other ISPConfig settings actually do). No doubt a lot of RTFM would sort that out and adding even more modules like Dspam would help. However I find an untrained Dspam setup will outperform spamassassin and when trained will get over 99% of spam and can adapt to each user mail patterns.

    ~ ps auxf | sort -nr -k 4 | head -n 4
    clamav   21069  0.0  4.9 468892 199520 ?       Ssl  Apr11   3:38 /usr/sbin/clamd
    amavis   14699  0.1  2.5 304396 103636 ?       S    00:15   0:01  \_ /usr/sbin/amavisd-new (ch1-avail)
    amavis   13259  0.0  2.4 301544 100488 ?       S    Apr17   0:01  \_ /usr/sbin/amavisd-new (ch3-avail)
    amavis   20290  0.0  2.3 221664 96892 ?        Ss   Apr11   0:04 /usr/sbin/amavisd-new (master)
    The above is taking up 500Mb of real ram on my main server compared to Dspam being called from maildrop as needed (no daemon) taking up zero ram except when actually in use. Also, regarding courier-mta, if using courier-imap and it's authdaemon then courier-mta uses the same authdeamon as courier-imap and the couriersmtpd processes use ~1Mb ram compared to posfix at ~5Mb per instance. Same with courier-imap at ~1.5Mb compared to dovecot at around 3Mb per process.

    So, in summary, courier-mta/imap plus Dspam from maildrop can offer significant ram savings for either small servers or run higher levels of service on large servers. Better "bang for buck" IMHO.
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    The score of the nroaml spamfilter setting is very high, to get better results just set spam score 2 in policy settings to a lower value like 3.5.

    amavisd is made for high traffic servers thats why it runs as damon, so it might indeed be a bit overkill on low traffic systems. Starting a dspam process when you filter high amounts of email is not effective and will use a lot of unescessary cpu power.

Share This Page