Postfix As Default MTA

Home » CentOS » Postfix As Default MTA
CentOS 9 Comments

I noticed when CentOS 6 came out that RHEL had moved to postfix vice sendmail as the default MTA. I had never heard the rationale given, it always sat on the back burner, but I was reminded of the question the other day when I was dealing with a related topic.

I don’t want to get into a pissing contest about how one MTA is obviously better than the other, nor why others think that I should prefer one over the other, but I *would* like to know what rational (if any) RedHat gave on the move. My google-fu hasn’t been successful in finding it and I didn’t see anything in the CentOS archives on the topic.

Does anyone remember the reasoning, if given? In particular, I’m wondering if it was due to integration with any other specific subsystem or software product.

Devin

9 thoughts on - Postfix As Default MTA

  • I can’t speak directly to RedHat’s reasoning, but I can say that I find Postfix MUCH easier to deal with than Sendmail. After 20+ years in Unix/Linux system admin, I still find Sendmail arcane and confusing, while Postfix configuration details are much more comprehensible to the ordinary mortal mind. When I needed a filtering front-end to a rather old and outdated mail server, I was able to make it happen with Postfix in less than a day, starting from scratch.

    Of course, what really matters is that you choose a solution that meets your specific needs. From what I’ve read over the past several years, it really boils down to personal preference rather than any great difference in functionality.

  • –[…]

    Yeah, in my case of 20+ years in UNIX admin and development, I’ve become comfortable with administering sendmail-based systems, and postfix is the devil not known :)

    Up to now I’ve been of the attitude of “sendmail’s not broken, I’ve got better things to do than fix it”. However, I was reading on ADSP for DKIM
    (RFC 5617) and in < http://www.opendkim.org/README> there is a discussion of issues surrounding sendmail’s handling of DSNs. But then, it looks like ADSP may be contraversial anyway.

    Thus the stream of consciousness …

    Devin

  • Ron Loftin wrote:

    For a contrary opinion, while sendmail.cf is difficult to follow, I’ve never found sendmail.mc too difficult.

    However, I’m finding postfix very difficult to configure with spamassassin. Postfix/dovecot works well enough, but the recommended addition of amavisd-new with clamav and spamassassin seems extraordinarily complicated and spaghetti-like, and I haven’t found any documentation in *.CentOS.org that describes the specific spamassassin side of the setup.
    [The alternative sendmail/procmail/spamassassin combination I run on another server seems much easier to follow.]

    Everything on my server appears to be running as it should, but I don’t think any spam is being caught. Eg I have set ok_languages en it fr de ga in /etc/mail/spamassassin/local.cf (and re-started spamassassin)
    but I am still inundated with chinese spam.

    If anyone knows of any documentation on the recommended CentOS setup of postfix/dovecot with amavis, clamav and spamassassin I should be grateful for a pointer.

    What I’d really like is to see what happens to a given email as it goes through its rather complicated journey through my system.

    In particular, I don’t really see the point of amavis, since as far as I can see spamassassin can be used directly with postfix.
    (I don’t care about clamav, as I don’t think I’d be tempted to read any email likely to infect my system.]

    Any advice or elucidation gratefully received, especially from anyone running this 5-program email combination.

  • I haven’t stayed quite up to the minute on MTA’s, but my impression was that sendmail really, really needed the milter interface but once it was added and tools like MimeDefang were developed to handle external processing within steps of the SMTP conversion (and under different user ID’s if you want) it became as good as anything. Maybe RedHat just never found MimeDefang…

  • I’ve had good success installing spamass-milter-postfix from the EPEL
    repository, and then adding:

    smtpd_milters = unix:/var/run/spamass-milter/postfix/sock

    to /etc/postfix/main.cf, as instructed in
    /usr/share/doc/spamass-milter-postfix-0.3.2/README.Postfix

    I don’t have any amavis stuff configured.

    -Greg

  • Greg Bailey wrote:

    Thanks very much for your response. I want to first try the combination recommended in CentOS.org as I described.

    I assume someone must run it, since it is recommended. I must admit I don’t see the point of amavis, since as you say one can run spamassassin under postfix without it.

    But if I cannot get this “official” setup working, I’ll go over to something like you suggest, and will probably follow the document you mention.

  • This is a multi-part message in MIME format.
    ————–030906020703080201030705
    Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable

    Yes I have this running on three different CentOS 5.x servers and until recently was very pleased with it. What changed?
    I am seeing emails with ***SPAM*** in the headings getting through to my Thunderbird client – this never used to happen, thus I think something has broken. When I get some time I’ll re-examine the setup and make sure it is all functioning. To be fair, I initially installed (2006/7) and ran postfix based upon a Postfix book I purchased – this was very helpful as until that time I
    had used sendmail with much frustration. Postfix has many possible “checks” and this book helped me understand what these did and more importantly, when in the process they did their magic. I later added the amavis / clamav / spamassassin as per the wiki – and it all just seemed to work, sending a test virus got appropriately caught and dealt with and this still functions. I do not get many of these now as my business has shrunk and the staff that needed protection have left. My recollection of how and why all the parts are required is dusty –
    will need to freshen this up now as I have just begun the install of a new CentOS 6.x mail server. HTH Rob

    ————–030906020703080201030705

LEAVE A COMMENT