CentOS 6 Sendmail Backup MX Config

Home » CentOS » CentOS 6 Sendmail Backup MX Config
CentOS 19 Comments

Hi All,

I’m just wanting to check that my understanding of the settings is correct as my web searches are finding a lot of dated information.

If I want a CentOS 6 sendmail system act as the secondary MX for domain bbbbb.co.uk do I just add a

Connect:bbbbb.co.uk RELAY

statement into /etc/mail/access and restart sendmail

Obviously I have the DNS MX records for the domain are already established.

I’ve been getting “/config error/: /mail loops back to me/ ” errors.

I think I may be stumbling into a variant of cname problem where the hostname as far as the sendmail machine is concerned is aaaaa.com but the DNS setting for the secondary MX is SMTP1.bbbbb.co.uk.

They both resolve to the same IP but when sendmail looks up the MX
records for bbbbb.co.uk it will find SMTP.bbbbb.co.uk and smtp1.bbbbb.co.uk listed and it may relay the mail off to smtp1.bbbbb.co.uk without recognising that aaaaa.com SMTP1.bbbbb.co.uk. Am I on the right track here, as I then just need to change the secondary MX setting in DNS to aaaaa.com?

Many thanks

Ken

19 thoughts on - CentOS 6 Sendmail Backup MX Config

  • I’d recommend not having a secondary MX at all unless it is equipped to reject invalid users and spam in all the same ways as your primary.
    Otherwise it accept junk that your primary rejects and then you are obligated to send a bounce message which is always a bad thing – you want the authoritative receiver to reject at the SMTP level instead of accepting at all. There’s a whole category of spam where the real target is the apparent sender where a bounce will go. Also anything sending valid mail should be prepared to queue and retry on temporary failures just as well as your own secondary would.

  • Agree, but…

    Not exactly. If greylisting on primary is set, but on backup MX is not, still what is killed by greylisting by primary MX, almost never will come through backup MX. This is due to the same reason why greylisting is efficient: it trows off all that doesn’t behave as mail server (thus never comes for re-delivery, and definitely doesn’t try backup MX which real servers always do even before attempt of re-delivery). Still, it is good to have the same greylisting on backup MX. And all other blows and whistles.

    I agree, it is wrongful behavior to accept something which later you discover you can not deliver. I would call it bad MX setup, as you are making yourself potential source of backscatter (which though is not as much exploited yet as open relays, but still is bad setup).

    If you set backup MX based on postfix, there is relay_recipients you have to specify, which lists all e-mail addresses that are legitimate on primary MX. Nothing else is being accepted by default, thus secondary MX
    does not become a source of backscatter.


    I’ve seen at least at some point that google mail accepts everything. Then, (after they parsed and filed information in that message I would speculate) they send non-delivery notification. That was a real incident after which I have a policy on my servers: I do not forward e-mail of users who left department to their google mail. As I don’t want _my_
    server to become a source of backscatter as a result of the crap they do.

    Valeri

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

  • I’m not convinced. Spam is big business and trying a 2nd MX is cheap.

    Greylisting would be kind of hard to do right. You’d have to keep the known-good senders in sync across the receivers. But my bigger worry would be a dictionary-type attack on user names as recipients if you don’t have access to the real user list on the secondary. Aside from the blowback of the bounces, if you’ve ever accepted an address it is likely to get on lists of known-good spam and cause extra traffic forever after.

  • Les Mikesell wrote:
    In this case the secondary MX has the same RBL’s etc etc as the primary. I do see the spammers sending their junk to the secondary more than the primary MX. Agree the secondary does not know the difference between valid and invalid addresses.

    Thoughts on my configuration?? I might just change the DNS name in the secondary MX anyway.

    Ken

  • I stated pure observation on at least two pairs of primary – backup MX I
    maintain. Still I made backup MXes with greylisting as well (they are separately hit by same bad spammers scripts, at a rate about 10 times smaller than primary MXes are and absolutely independently).

    With standard backup MX based on postix (with rather trivial configuration) you always do have list of legitimate recipients of primary MX on the secondary MX. Sorry if my previous e-mail is not explicit enough about it. It’s a work, however, to maintain that table on backup MX (so your backup MX does accept mail for newly added users to primary MX). But having backup MX receiving everything is wrong configuration prone to backscatter – at least I see we agree on that. So, just don’t roll out badly configured backup MX, I would say.

    Valeri

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

  • I think that’s unusual – spammers often target the secondaries as a preference on the premise that they are likely to not be as well-configured as the primary. But it has been a while since I ran one so maybe things have changed.

    Doing greylisting right means you also have to keep the table of already-known senders up to date and that may be very dynamic.

  • What software the secondary MX is based on in whose case you say secondary MX doesn’t know legitimate addresses of primary MX?

    I know about postfix. And all my servers are based on postfix. And even in the most trivial configuration of secondary MX based on postfix secondary MX _does_ have to have all legitimate addressed of primary MX. These are in relay_recipients table. Any address that is not in that table, will not be accepted by secondary MX. Postfix even in the most trivial configuration is sane and does not “accept everything”.

    So, what is the secondary MX server that you are describing that “accepts everything” is based on?

    Valeri

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

  • I think he means that the secondary does not know the user names on the primary. Which it won’t, unless someone maintains it, regardless of the server software.

  • Consider me lucky…

    If you are kind person, yes. Sqlgrey is designed to work simultaneously for primary, secondary (and tretary maybe – didn’t check) MXes. Yet, even if they are independent, all will work, you are just not being nice to other servers and make them make 3 delivery attempts (the last is successful) instead of two (that is: primary MX – “temporary failure”, secondary – “temporary failure”, primary after some time – accepted;
    instead of primary MX – “temporary failure”, secondary – accepted which will be in nice configuration common for both MXes greylisting engine and database).

    Valeri

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

  • Did you ever set up backup MX based on postfix? Sounds like not, as in case of postfix you have to maintain that table on backup MX, or it will not accept anything destined to primary MX.

    It is only now that I read the thread subject… which is about sendmail. So, I guess my comments about postfix are not relevant or not quite relevant to this thread. I started replacing venerable sendmail almost two decades back with postfix which was written with security in mind from the very beginning by brilliant person: Vietse Venema. I still like human readable configuration files of postfix and got really used to all logic of it. So even though sendmail I heard is not a security disaster for long time already I’m quite happy with postfix. At some point even RedHat switched to postfix as default MX software on their system (not long ago though…). I guess, backup MX example makes me even happier: postfix really prevents you from doing wrong thing (making your backup MX a source of backscatter).

    Just my $0.02

    Valeri

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

  • Sendmail was pretty much all fixed by the time postfix was released, and made even better with the addition of the milter interface that lets you run scanning, etc. processes under different uids but able to participate in the SMTP conversation. Postfix eventually got around to copying that too.

    Just another change for change’s sake as far as I’m concerned. Sendmail continues to work just fine and the configs as shipped rarely take more than a few lines of change in the m4 file to do normal operations.

    It’s not postfix doing that, it is you, doing whatever has to be done to keep your lists in sync. Still, I don’t see the point of even having a secondary MX. The days are long gone when chunks of the internet can’t reach each other for long periods of time and anything sending should do its own queuing and retries. In fact if you do greylisting, you have forced all of your senders to prove it.

  • Once upon a time, Ken Smith said:

    That’s a big “bad idea”. Aside from spam filtering, your backup will accept invalid recipients and then (when delivery to primary fails)
    generate bounces back to senders. This is known as “back scatter” and will get your server black-listed. If you don’t have a network name service of some type (e.g. LDAP), don’t do this.

    The real question is: what are you trying to achieve with a backup MX?
    If it is to store mail when the primary is down, legitimate remote mail servers will do that for you; you don’t need to have a backup.

  • On some domains I have 3 MXs – primary, secondary and tertiary – all share exactly the same coding, configuration and reporting. Absolutely no sense is weakening security for any MX although some spammers think the highest numbered MX is the weakest !

  • That is because Google is primarily a USA government sponsored intelligence gathering operation. It wants as much information as possible. Google’s commercial activities were never originally planned. They are an unexpected, and very lucrative, bonus.

  • When I set up secondary MX services in Sendmail (and Postfix) then I
    always use the direct address feature of the domain routing table and avoid looking up MX RRs altogether. After all, if the mail arrived here it is a good bet that the main MX is off-line (or this is SPAM/UCEM but that is another issue).

    So assuming that the primary MX host is mx10.example.com and the secondary is mx40.something.else then with Sendmail the file
    /etc/mail/mailertable on mx40.something.else should contain something like this:

    example.com. esmtp:[mx10.example.com]
    .example.com. esmtp:[mx10.example.com]

    The [] brackets prevent MX lookups and just routes the message traffic directly to mx10.example.com as soon as a connection can be made.

    This prevents the most common source of mail loops where the primary is off-line and so any mail is bounced back to the backup MX, which just happens to be the host that just sent it, thus causing the loop.

  • Much spam/ucem is deliberately sent directly to the lower priority MX
    host from the outset on the assumptions that: 1.) the secondaries will be less well configured to detect SPAM to begin with; and 2.) once mail is routed though an officially recognized secondary host then the primary is less likely to treat such traffic as SPAM.

    We run grey listing and amavisd (clamd/spamd) on all of our MX servers because of this practice. We also list several non-existent MX
    secondaries at the lowest priority to cheaply pick off the really stupid points of origin.

    Yes we do get rejects for real correspondents. A notable recent victim, if such is the right word to describe a self-inflicted injury, was ibm.com. Who, in contravention of rfcs 7208 and 7372, both configured eleven MX hosts for their domain AND enabled SPF. This causes an immediate permerr with anyone checking SPF as the maximum number of MX hosts allowed with an SPF enabled domain is ten.

    But, who am I to tell IBM how to configure a computer?

    On the other hand, we also have large organizations who use SMTP pools and with these grey-listing simply does not work. Each subsequent attempt to connect can occur from any of the IPs in that pool and the mail either never gets through or is seriously delayed. For those cases we are constrained to use white-listing.

LEAVE A COMMENT