[PLUG] high MX versus greylisting

[Eli Stair]

Very cool profiling of that behaviour!  If the response is entirely
RFC compliant, and doesn't break valid (but non-RFC...) MTA's that's a
great frontline defence before any Bayesian filtering even has to take
place!

Aside from the points you mentioned, the most important thing I can
think of would be the addition of some software loadbalancing-esque
feature.  If the real and faux MX are on the same box, having
per-minute (or realtime) polling of the status of the "real" MX would
be necessary in the event that it actually fails, so your backup can
actually receive.  IMO.

Cheers on the good work, please update when/if you have time to
integrate that further.

/eli

On 12/28/05, Keith Lofstrom <keithl at kl-ic.com> wrote:
>
> A High-MX spam trap may be incompatable with greylisting, unless
> the two are carefully combined.
>
> Randal has a clever "high MX spam filter" system that detect
> when the bad guys attempt to get around spam blocking by going
> to the secondary mail input first.  Here's how it works:
>
> The MX records for my site specify an alternate mailing address
> to use when my primary mailing address is not responding;  this
> alternate address has a higher MX value, telling the mail transport
> programs out there to use that high MX address if they cannot connect
> to the normal low MX address.  Since the alternate address is often
> less heavily guarded than the main one, some spam-bots try that
> alternate high-MX address first.
>
> One simple (but sometimes invalid, see below) way to detect
> spammers (and the IP address they are working out of) is to
> set up a fake high MX secondary address, on the same machine
> as the primary (but with another IP address perhaps), and
> temporarily blacklist the IP addresses that try to use it.
> After all, if the secondary address is capable of receiving
> mail, the primary address is too - there should never be any
> mail to that address.
>
> Now, add greylisting.  Greylisting works on the idea that a real
> SMTP server will retry sending a message if it doesn't get through
> immediately.  spam-bots don't do this.  So a greylisting MTA
> (Mail Transport Agent) receiving an email will send a 450 error
> to the sending MTA the first time it sees an email attempt, but
> will pass the message (and whitelist the server) when it sees
> another attempt more than five minutes later.  This blocks more
> than 95% of spam-bots, and when I turned on greylisting on my
> server I went from 60 spam messages making it through spamassassin
> per day, to less than 2 (Note, I get around 30,000 raw spam
> attempts per day).
>
> However, because greylisting sends out the 450 temporary error
> to the sending MTA, that MTA will retry on the high-MX port.
> A High-MX trap program will need to be aware of this, or it
> will treat this valid behavior as a spambot.
>
> I do not have time right now to rewrite my high-MX detector
> and combine it with Postgrey, so I just take the high-MX messages
> and dump them on the floor.  That stops the high-MX-only spam,
> though it creates an inconvenience all the other valid MTAs
> and may cause some to break.  Unless I can combine the behaviors
> properly, I probably shouldn't run the high-MX detector.
>
> Keith
>
>
> --
> Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
> KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
> Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>