my preferred mail installation would be to use the qmail package patched with john simpson's combined patch, authenticating against vpopmail. This way of doing things encourages security by default, with the login command only allowed to be transmitted once the user is on a secure (SSL/TLS) connection.
See qmail.jms1.net for details on this patch and the JMS way of doing qmail virtualhosting.
Is there any way of safely migrating away from the configured postfix system on my CENTOS system to my own custom build of qmail the JMS way? I'm prepared to reconfigure my system from scratch if there's no easy way of doing the migration, as I haven't opened the server to the public yet (It's only handling a couple of personal sites and my personal email atm).
the other question, will virtualmin mind if I completely remove the postfix/dovecot rpms, or will it reinstall them on each subsequent upgrade?
According to the Virtualmin FAQ, Qmail and VPopMail are already supported:
http://www.virtualmin.com/faq/one-faq?faq_id=1511
I can't answer your question about migration from Postfix to Qmail, but I can answer your last question: You should be able to remove Postfix and Dovecot RPMs, since these are provided by your OS vendor, not Virtualmin. Virtualmin will not attempt to reinstall them unless you run the installation script again, which is not the recommended method of doing upgrades. Instead, you use your OS update tool, such as YUM in the case of CentOS, which will only update existing installed RPMs by default.
All this being said, I don't see how Qmail and VPopMail are any more secure than Postfix and Dovecot:
http://www.postfix.org/security.html
http://www.dovecot.org/security.html
the security links you posted, although very informative, do not explain "best practices" for the server owner, only the designers. John Simpson's patched qmail goes beyond basic security practices by completely preventing AUTH unless the client is on a secure (SSL/TLS) connection along with: spf checks, domainkeys, the validrcptto patch (which is great to prevent bounce spamming through your server), MX record checking (basic one I know, but it's in there), and (adding to the spf checks) blocking of SPF +all domains to prevent spammers regging a domain and adding a +all spf record to dns.
Thanks for the info. I could be wrong, but I believe that all of this can be done with Postfix and Dovecot as well. Without going into a lot of detail, most of the documents that explain how to do this are here:
http://www.postfix.org/docs.html
I'm not trying to change your mind on server preference, but I am still not convinced either that qmail is any more secure than Postfix and Dovecot. Proper configuration and management is the key in both cases.
I'll certainly look through those docs, again, thankyou for the link :-) . We are agreed that it is all down to how you configure the servers. I've more experience with qmail, so I'm more likely to be able to configure it in a secure fashion than I am with postfix - it's all down to what you know I guess. I'm sure there are many postfix gurus that wince at my mention of using qmail :-p , but I like it, it does what I want and how I want.
as another note, I've gone ahead and replaced postfix using the alternatives system that RHEL and Centos provide (so that I can easily go back) and things seem to be working quite well indeed
I just found this on the postfix docs
"smtpd_tls_auth_only (default: no)
When TLS encryption is optional in the Postfix SMTP server, do not announce or accept SASL authentication over unencrypted connections.
This feature is available in Postfix 2.2 and later."
unfortunately this is only available for 2.2 and above, so I need to update my version of postfix to have this support.. however centos does not currently supply a later build of postfix.
Interesting, I didn't realize that feature was so recent, but I'm glad you found out how to do it in case you do decide to run Postfix in the future. Personally, although I also believe in strong security, I am not ready to[Em>require</Em> all of my clients to use TLS, since it would block a lot of them out or make it difficult to reconfigure their clients. But I do think it's a worthy goal, and of course I use it myself.