OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Possible MX Lookup/Ordering Issue

gordanbobich.net
Date: Thu Nov 01 2007 - 09:51:25 CDT


On Thu, 1 Nov 2007, Jorey Bump wrote:

>> > You might want to explain what you're trying to accomplish with your
>> > multiple MX records. This list is ridiculously long, and the TTLs are
>> > far to high for an experiment. It's hard to look at the results of this
>> > query and jump to the conclusion that Postfix is at fault:
>>
>> You're jumping to conclusions.
>>
>> 1) That's not the domain that's having problems.
>
> I don't mean to imply that this domain is the one having problems, just that
> you are engaging in some very creative DNS configuration. Perhaps equally
> creative approaches are responsible for this problem.

Or perhaps the said creative approaches are triggering otherwise
undetected bugs elsewhere. That's what I'm trying to get to the bottom of
here. :-)

>> 3) The MX-es are there for a reason. Google "nolisting".
>
> I don't have to Google it, I discovered Nolisting, coined the term, and
> maintain the definitive documentation for it:
>
> http://nolisting.org/
>
> The first hit results in the original location, my personal web site:
>
> http://www.joreybump.com/code/howto/nolisting.html

My apologies - I hadn't realised that you were "the one". Pleased to meet
you. :-)

> What you are practicing is not Nolisting. You are doing more harm than good
> by listing so many MX records. Nolisting only requires a single nonresponding
> primary MX.

Which will actually do more harm than good. Spammers go for the low
priority MX-es, because the standard opinion is that the high priority
MX-es will be anti-spam armed, and the low priority ones aren't. No doubt
born out of the misconfigurations from companies that filter their
primaries through the likes of Message Labs and still leave the lowest
priority MX totally open "just in case".

Thus, you need a primary that rejects immediately, and frees the sender up
to try the next record down. (repeat an arbitrary number of times)
Followed by a real, responding server.
Followed by an arbitrary number of records that drop or tarpit everything
that touches them, because nothing should ever get that far.

It's not just about foiling the spammers that go for the primary - it's
even more about foiling spammers that go for the low priority MX-es or aim
for a random MX. If you're going to use decoys, what's the point in
half-measures? It's not like it's breaking the RFC, which allows for an
arbitrary number of MX-es and 65535 unique priority numbers.

> You are likely causing some malware to generate unnecessary
> traffic for each MX you list.

My heart bleeds for all the zombie owners. Sorry, but I'm finding it very
hard to be moved by this argument.

>> 4) Lots of MX-es are no excuse whatsoever for not re-trying them in the
>> correct order, whether their IPs get reported back in the additional
>> section or not.
>
Agreed, but we still need evidence from your logs that this is indeed what's
happening.

As per the other post, I'm still digging out the said evidence.

Gordan