Wednesday, 24. March 2004
Count your MXes *
A brief email exchange with a reader the other day put me in mind of something that happened when we changed ISPs a little while back. We are too small to have our own ASN or to put in place the necessary infrastructure to do things like run our own name servers, so rely on our ISP to manage DNS matters for us. I have never much cared for this (our dependence on a third party to provide DNS) and still hope to find a simple, cost effective way of taking it on. But for now that's how it is.
Well, shortly after the DNS changes were put in place and started to propagate, I went to the name servers which were now authoritative for our main production domain to verify that everything was correct. It was not.
Despite very clear instructions, the hostmaster at our ISP had, in addition to the various A and MX records I had actually requested, given me for free three additional MX records pointing to SMTP servers under the control of the ISP. This type of arrangement is often referred to as MX fallback. The idea is that, if your own mail server is down for some reason, another will accept email on your behalf and hold it in a queue to be delivered to you when your mail server comes back up.
It took me quite a long time and considerable patience to get the message through that, when I had said I wanted two MX records, I had actually meant two and not my two plus any others you care to add.
So. Why is this an issue? Two words. Unbalanced policy.
By now, most sites operating their own Internet mail servers have at least some policies in place to handle various types of network abuse both during and immediately after (**) transmission. In many cases these policies are quite strong. For example, here we use a number of DNSBLs to block messages during delivery plus other rules to handle attempts to wriggle through loopholes in the protocol (spoofed sender envelopes, bogus EHLO and so on), plus our local list of banned IPs and hostnames and so on and so forth.
Let us assume that we actually want our ISP to provide MX fallback:
Well, shortly after the DNS changes were put in place and started to propagate, I went to the name servers which were now authoritative for our main production domain to verify that everything was correct. It was not.
Despite very clear instructions, the hostmaster at our ISP had, in addition to the various A and MX records I had actually requested, given me for free three additional MX records pointing to SMTP servers under the control of the ISP. This type of arrangement is often referred to as MX fallback. The idea is that, if your own mail server is down for some reason, another will accept email on your behalf and hold it in a queue to be delivered to you when your mail server comes back up.
It took me quite a long time and considerable patience to get the message through that, when I had said I wanted two MX records, I had actually meant two and not my two plus any others you care to add.
So. Why is this an issue? Two words. Unbalanced policy.
By now, most sites operating their own Internet mail servers have at least some policies in place to handle various types of network abuse both during and immediately after (**) transmission. In many cases these policies are quite strong. For example, here we use a number of DNSBLs to block messages during delivery plus other rules to handle attempts to wriggle through loopholes in the protocol (spoofed sender envelopes, bogus EHLO and so on), plus our local list of banned IPs and hostnames and so on and so forth.
Let us assume that we actually want our ISP to provide MX fallback:
- Then we will always want to accept email from our ISP's fallback MXes.
- These will be announced as non-preferred MXes for our own domain.
- Anyone wishing to defeat our use of DNSBLs at our preferred MX simply has to try the non-preferred (fallback) MX first.
- If that fallback MX does not have the same policies in place for blocking based on IP, resolved name or SMTP handshake items, then it is a de facto back door for an abuser to enter our system.
The question is then whether our ISP has the ability or the appetite to mirror our local policy on the fallback MX.
I guess you can ask, but don't expect a helpful answer. These fallback MXes are not there just for you, but for every other customer of the ISP in question and every one of those customers will have different MX policy requirements. So there's your choice:
- Use your ISP's fallback MX and accept that it will be abused more than used. (***)
- Create your own fallback MX and manage policy on it yourself (make it a Domino server in the same domain as your preferred MX and use a common server configuration document replicated between the two) -- This is what we do here.
- Or just don't have a fallback at all (gasp). The impact of this decision is easy to evaluate. You just need to know how much downtime you expect (frequency and duration of incidents) and have a reasonable idea of mail volumes. If outages are infrequent and short lived and mail volume is not high (all true here as it happens), then really -- do you need MX fallback at all?
* Get Sam Spade for Windows (free) and use the dig tool on your own domains.
** Other mechanisms that take effect after message delivery are not affected by unbalanced MX policies.
*** I have the stats to back this up and just to illustrate further, will publish full stats for preferred/non-preferred MX next month.
Category: Domino: Administration
Technorati: Domino: Administration
Comments :
Unable to post a comment? Please read this for a possible explanation...
- 
