Sendmail Is Considered Deprecated

Home » CentOS » Sendmail Is Considered Deprecated
CentOS 10 Comments


Today I searched redhat official portal and learned that Sendmail is considered deprecated. By default, CentOS 7 will use postfix as MTA. I need good advise on what it means to us. We are CentOS customers. We use that operating system for quite a few years. We rely on Sendmail for years for us to relay large quantity of emails to our customers for marketing purpose. We build our additional fallback servers as well for fallback relays. We build our customized configuration for Sendmail too. I really need help to figure out if we can continue using Sendmail (even deprecated) for future long term and what implication would be doing so. Thanks,

– xinhuan

10 thoughts on - Sendmail Is Considered Deprecated

  • That was an excellent decision I welcomed the day RedHat made it. Beginning with my firat RedHat (it was somewhere around RedHat 5 IIRC) I
    always have been replacing venerable sendmail with postfix.

    Well, it sounds like you are one of the companies with whose effort I have to fight constantly in my own effort to protect our users from spam…


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • You can still install sendmail, but postfix is the default, a decision I
    personally support as I have found it to be a lot easier to administer than sendmail with a much better security track record.

    Historically, you would use system-switch-mail to select your preferred MTA to switch from the default.

    I don’t know if that is still the method, since the default now is what I prefer.

  • What makes Postfix superior in fighting spam?

    How do I integrate MIMEDefang, SpamAssassin, and ClamAV with Postfix?
    Are there migration guides for moving one’s Sendmail anti-spam and AV
    configurations to Postfix?

  • I don’t know about MIMEDefang but SpamAssassin and ClamAV are pretty straight forward. There are guides for both with Postfix all over the net.

    MIMEDefang I have not heard of, but unless it does something really funky I suspect it also is easy to set up with Postfix.

  • I actually made two independent statements:

    1. That I use postfix forever (postfix was written by Wietse Venema with security in mind).

    2. That the company the OP works for judging from my reading of OP’s post makes money by facilitating the creation of spam (by their customers).

    By no means I meant to say posfix is superior to sendmail in fighting spam. Neither of them is designed for fighting spam, each of them is merely MTA. Postfix, however, having human readable configs with rather logical logics makes it easier (for me) to administer, therefore easier
    (for me again) to integrate with anti-spam components (amavisd, spamassassin, clamav – the last to scan for viruses – or rather virii I
    should say as that is plural of latin word ;-)

    Just my $0.02.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • From the MIMEDefang website:

    It will detect a SpamAssassin and ClamAV installation and invoke it site-wide, rejecting virii and extreme spam before it gets to the delivery agent (eg. procmail), quarantining it for administrative review and sending a quarantine notification to the recipient.

    Reading around, it looks like Postfix supports milters and people have gotten MD working with it.

  • That’s pretty much why I started using postfix, I don’t remember when but I believe it was with Red Hat 7 (pre Fedora days). It was much easier for me to configure postfix on a web application server and have it send encrypted to their MX then it was to configure sendmail. It was possible with sendmail but I wasted hours trying to get sendmail configured, first time with postfix was cake.

    Now I use it because of the support for opportunistic DANE (I run an updated version, built from CentOS src.rpm but with version bump) so that when the receiving MX has DNSSEC with a TLSA record on port 25, I
    know the message is either delivered to that MX encrypted or not at all.

    The attack that strips the STARTTLS causing plain text won’t work when the receiving MX is configured with DANE. Right now comcast is the only major ISP in the united states that has MX servers configured with DANE, but several small ones do as well, and several in Europe are as well
    (especially .nl and .de mail servers)

    I don’t know if sendmail has been updated to support DANE yet or not, but last time I looked, it did not.

  • It is considered “deprecated” as you say, but that does not mean they no longer support it. You can use Sendmail in CentOS 7 just fine and it is relatively easy to switch (complexities of proper Sendmail configuration not withstanding).

    I think in this case they simply mean that Sendmail is not the default, but that does not mean it is not supported in any way.

    Admittedly this sounds like SPAM, but not all mass marketing mail is SPAM and it can be done in a way which is not. I’ll give you the benefit of the doubt for now.

    I would say that Sendmail will likely continue to be supported at least through the lifespan of RHEL7, I cannot speak as to whether it will be supported in RHEL8 or not, but if you want to continue using Sendmail and you feel comfortable using it, then by all means use it.

    That said, I would encourage you to have a look at Postfix, you can do pretty much everything you do in Sendmail in Postfix and more and the configuration is easier to manage. Postscreen is one of the newer postfix features that you won’t find in Sendmail and you may find that alone is worth the switch.


  • As of today you don’t need to do anything, apart from explicitly installing Sendmail after any fresh install (either in the installer or any time after), e.g., yum install sendmail && yum remove postfix.

    But deprecated suggests it will eventually be made unavailable so it would be wise to begin planning to transition to an alternative, though when that will happen is unkown so there’s no timetable you can work towards. Since Postfix is the only other MTA they provide that’s what you should consider most strongly, though if you’d like alternatives EPEL provides at least Exim and OpenSMTPD.