gordanbobich.net
Date: Thu Nov 01 2007 - 10:39:14 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, 1 Nov 2007, Jorey Bump wrote:

> gordanbobich.net wrote, at 11/01/2007 10:51 AM:
>> On Thu, 1 Nov 2007, Jorey Bump wrote:
>>
>> > 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".
>
> Don't let opinion or fringe cases guide you here. Too often, I have to defend
> Nolisting against a straw man argument that "this is useless because spammers
> will just bypass the primary MX and go to the secondary instead." Well,
> *some* do, and I'll deal with them in a later step. Meanwhile, I've foiled
> the majority, and I've conserved some of my resources so they can be used
> elsewhere.

Sure - and I've gone one better and hidden my real MX somewhere between
the rejecting ones at the top (which leads to immediate retries to the
next MX down, which may or may not do the same thing), and the tarpitting
ones at the bottom. And even if a valid MTA gets to the bottom ones
through a minor network outage, it'll still eventually time out and roll
over to retry from the top after a little while.

>> 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.
>
> Why bother fighting spam that wouldn't exist otherwise? Don't create
> unnecessary targets. It's not like there is a finite amount of spam aimed at
> a domain that gets thinned out over multiple hosts. Malware is perfectly
> capable of generating *more* spam for each MX record. I haven't seen
> conclusive evidence the contrary.

The fact that the top 1 and bottom 3 MX records see a disproportionately
high packet hit rate compared to the valid and accepting real MX is
evidence.

>> 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.
>
> Be careful. RFC 2821 specifies that a client MUST try and retry each MX
> address in order, and SHOULD try at least two addresses. Yes, you can create
> as many decoys as you like, but you can't predict the results when you stray
> outside the requirements or suggested best practices. At that point, it's
> anyone's guess what a site's local policy mandates.

Sure - so have a rejecting primary, real secondary, and a bunch of decoys
afterwards for spammers that try the low priority ones. That way you're
still RFC compliant in that your real MX is one of the top two.

>> > 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.
>
> I was referring to unnecessary traffic to your site, ISP, and on the Internet
> at large. It's not useful to generate an unnecessary volume of traffic,
> especially when dealing with unpredictable malware. Try to conserve your own
> resources, since the resources of botnets are virtually unlimited by
> comparison.

Unless you tarpit their TCP connections by crashing them half-open (-j
TARPIT). It makes a big dent. :-)

Gordan

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]