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?
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... Code: 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
ISPConfig uses amavisd (which internally uses the spamassassin libraries) for mail filtering and you can plugin dspam as amavisd / spamassassin plugin: http://wiki.apache.org/spamassassin/CustomPlugins
Excellent, thanks. I should try this out. The project has moved to Github... https://github.com/elubow/dspam-spamassassin 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. Code: ~ 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.
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.
