My mail system has been generating a log of log noise about temporary DNS failures recently. I took a look at the logs and tracked the issue down to a certain (apparently US-based spammer) sending mail out from domains with many MX records associated with it. So many, in fact that the the MX record exceeds the 512 byte limit for UDP, requiring that a TCP query then be made. It's the UDP failure before the TCP retry that's causing the warning in the logs.

While this is technically valid behaviour, it's very unusual and bad practice.

Firstly: TCP-only DNS is unreliable (especially in NAT environs) and considered wasteful network wise if it can be avoided.

Secondly: If you actually need many backup MX records (and you probably don't), it's better to give multiple addresses to a few distinct host names. The algorithm for mail delivery requires going to each host name, not each IP address. In the event of issues on the MX servers, it's an unfair burden for a sender to iterate through each of many hosts before concluding that delivery is not currently possible.

I actually suspect the many-MX design to be some technique for bypassing anti-spam systems, but I don't have any clear example I can point to.

So for now, I'd just like to track them, and later possibly incorporate the information into an anti-spam heuristic.

I'm currently just tagging mails in an ACL, based on the number of MX records associated with the domain of the sender. Oddly, for such a rich set of opperators, Exim doesn't seem to have something counting the number of items in a list. (Note: while this returns the number of MX records, it's not conclusive in recording if TCP was required for a DNS lookup.)

   warn    set acl_m_sender_mx_count = ${reduce {${lookup dnsdb{>: \
            mx=$sender_address_domain}}}{0}{${eval:$value+1}}}
           add_header = X-Sender-MX-Count: ${acl_m_sender_mx_count}

If I actually wanted to act on this information I can apply a test such as:

    condition = ${if >{$acl_m_sender_mx_count}{10}}