Possible MX Lookup/Ordering Issue
I'm seeing some strange behaviour with my Postfix setup. It occasionally
doesn't try the MX records in the correct order. It will try a low
priority one, and if the machine is on a local subnet but not running,
it'll get back a "no route to host", and get stuck. It'll keep retrying
this one quite a few times, before it gives up and rolls over to the high
priority MX-es which it should have tried first.
Is this a known bug?
One thing that could be causing it is that I am, unfortunately, relying on
a partially broken PowerDNS setup, which truncates the additional section
of the response down to 512 bytes so it can respond via UDP. This leads to
it reporting a complete list of, say, 10 MX records, but only reports IPs
for 3 in the additional section (and these 3 seem to rotate around all the
Does Postfix try to cut a corner here and use the MX with the IP returned
in the additional section, instead of going purely based on the MX list
and trying the records in the priority order as it should?
I cannot think of any other explanation. My logs show that it never even
bothered trying to connect to the high priority (low number) MX-es before
it tried a low priority one (which, as it happens, wasn't working). It
then got stuck retrying that non-working MX for hours instead of retrying
them in the correct order. But that's less of a problem - the serious
problem is that it didn't try connecting to the MX-es in the correct
This only seems to happen on a small number of emails. Most of the time,
it seems to do the right thing.
- On Thu, 1 Nov 2007, mouss wrote:
> gordan@... wrote:Sure - but I've tested this across different networks and different
>> On Thu, 1 Nov 2007, mouss wrote:
>>> this does not prove that using 10 records significantly reduces the spam
>>> received on the real MXes. This only shows the dsitribution of spam
>>> attempts when using 10 records.
>> Sure - but unless spam that went to MX10 then went and tried MX2, the
>> spam wasn't delivered to MX2.
> As Jorey said, it's not like there is a finite quantity of spam to be
> distributed among MXes. I have domains that receive 0 spam (and they
> have an MX). BTW. I also see smtp attempts to machines that are not
> listed as MX for any domain.
domains. There is always the dominant shape of the curve: disproportionate
number of connections on the 1st nth, n-1 and n-2 MX records (where n is
the number of MX-es).
>>> the experiment would be:It worked so well that I never bothered gathering any stats. But I guess I
>>> test 1: with only 2 records, what amount of spam is targetting the real
>>> MX. do this for some period of time (so that there are actually many bot
>>> test 2: do the same test with 10 records.
>>> if the amount of spam (on the "real" MX) in test 2 is significantly
>>> lower than in test 1, then 10 records would be useful. otherwise, you
>>> are just putting more honey for the flies.
>> The difference is extremely signifficant. It is also signifficant
>> between 3 and 5 MX-es, although it gets less measurable when going from
>> 10 upward.
> you did not show actual numbers for this.
could go through my spam folder and put some numbers to it when I have a
>>> No. see above. you are comparing numbers in a single setup. you are notBecause there is still a measurable drop, and it isn't exactly an
>>> comparing different setups (different number of records).
>> Yes I was. I tested with increasing numbers of MX records and the amount
>> of spam reduced. You do get into diminishing returns (statistically, 10
>> gets around 90% of it away, going from 10 to 100 only reduces it by
>> another 9%), so usually I don't bother with more than about 15. The
>> drop-off is actually better than linear because spammers seem to target
>> the 1st highest and 3 lowest MX-es, so adding more in the middle just
>> dilutes the ones that target a random MX.
> If they target 1st and last 3, then why 10 instead of 5?
>> You could, of course, just try it yourself for some figures you canYou'll need some quite spam-heavy unused domains to gather the statistics
>> trust. :-)
> I suspect there may be broken MTAs out there, so I keep myself under the
> 2 MX limit to avoid any risk on "real" domains. but I may test this on
> domains unused in email.