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

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

On Thu, 1 Nov 2007, Jorey Bump wrote:

>> > > 1) That's not the domain that's having problems.
>> > > 2) It's MX-es are not running postfix (they are running courier)
>> > > 3) The MX-es are there for a reason. Google "nolisting".
>> >
>> > Which requires just 3 MX hosts not 66.
>>
>> To be effective you need more. 66 was for testing purposes, but proved to
>> work. In a production setup I wouldn't bother using more than 10-15.
>
> You only need a single nonresponsive primary MX for Nolisting.
>
> It's funny, but I was doing a similar experiment when I discovered Nolisting
> (although I used a 5 minute TTL). I was simply trying to find out how many MX
> records popular MTAs and ESPs would retry before giving up (it turns out you
> can't rely on more than two attempts). The next day, my log parsers revealed
> a dramatic drop in spam. I refined the technique to provide the most
> reliability, and that is why Nolisting formally requires only one
> nonresponsive MX. Tacking on additional ones is not Nolisting, and returns
> results that are misleading.

I agree, but when you set up about 10 records, you find that the 1st and
n-th out of n servers get about 80% of the packet hits. The n-1, n-2 and
n-3 servers get a decreasing number of hits. 2nd is usually the next one
with most packets going through, presumably including all of the ham that
hit the 1st, immediately rejecting server.

>> Spammers go most for the top 1 and bottom 5 MX-es.
>
> *Some* malware attempts delivery to multiple MX hosts. I believe that is the
> best you can conclude. It is impossible to get reliable results on any
> variation in the configuration without using a virgin block of IP addresses,
> and preferably a new domain.

Not at all. Once the DNS TTL expires, it's as good as it's going to
get. And if you have domains with lots of users (and usernames), that's a
great way to show that the vast majority of spam will go to the decoy
MX-es.

> Even then, there are too many factors to adjust
> for, but my studies have shown that the majority of malware still targets the
> primary MX. Nonresponsive low priority MX records seem to result in more spam
> being generated, but not necessarily
> less spam on the responsive MX (you're just creating new targets).

I beg to differ. Given that my packet logs show that the low priority
MX-es are the ones that get most of the packet hits (more than the
primary), I'd say the evidence is pretty conclusive.

> If you want to explore a more strict variation, look at Unlisting:
>
> http://unlisting.org/
>
> By itself, it is extremely effective, but prone to too many false positives.
> I have been combining Nolisting with Selective Unlisting for more acceptable
> results:
>
> http://unlisting.org/selective.html
>
> The caveats remain, but you determine the acceptable risk.

I read that, and I really like the idea, but the problem is that you need
100% reliable whitelists for all multi-homed senders. Since this is
impractical, I don't think it's ever going to work on a large scale. The
same applies to greylisting, which is equally broken. You cannot rely on
multi-homed senders sending from a nearby (IP-wise) subnet. I used to run
a multi-homed system that had two completely diffrent sets of IPs on two
completely different subnets from two completely different ISPs.

But there are a couple of derived methods I'm looking at that don't suffer
in the same way. This has little to do with postfix, though, so it's
probably best to take it off the list. :-)

Gordan

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