Thousands of ssh probes

Matthew Seaman m.seaman at
Sat Mar 6 09:36:13 UTC 2010

Hash: SHA1

On 06/03/2010 06:33:53, Ian Smith wrote:
> In freebsd-questions Digest, Vol 300, Issue 10, Message: 6
> On Fri, 05 Mar 2010 16:07:29 +0000 Matthew Seaman <m.seaman at> wrote:
>  > On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
>  > > The spamtrap is a shiny object for spam, and anything that goes there gets
>  > > blocked for an hour from hitting the low port.  I presented this at a
>  > > conference once.
>  > 
>  > Having an IPv6-only high-mx seems to terminally confuse most spambots...
> I understand why IPv6 would confuse them, but don't follow why higher 
> numbered MXs would be more attractive to them in the first place?
> Are they assuming a 'secondary' MX will be more likely to accept spam?

Yes.  Generally a high-numbered MX is more trusted than the run-of-
the-mill internet by the actual mail server (lowest numbered MX)[*], so
forwarding between MXes tends to bypass chunks of anti-spam
protection.  The high-numbered MX itself is usually a pretty low
importance system at a location remote from all the rest of the mail
servers, so it tends to have less effective anti-spam protection.  Thus
spammers ignore the normal MX priority rules and just attempt to inject
spam through the highest numbered MX, because it is more likely to get

On the whole, I don't see the value in having a high-numbered MX to
dumbly accept, queue and forward messages like this. It doesn't really
add any resilience: the SMTP protocol is intrinsically all about store
and forward, and if a message cannot be delivered immediately, the
sending side will keep it in a queue for up to 5 days anyhow.  Low
priority MXes make some sense for load shedding, but realistically as
part of a cluster of servers at one site.  If you want resilience
against network outages, then you're going to have to provide a
resilient solution for /reading/ the e-mails too, and that's a whole
different ball game.



[*] Even if the low-priority MXes are treated as untrusted, you've still
got the whole backscatter problem to consider.

- -- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP:     Ramsgate
                                                  Kent, CT11 9PW
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-questions mailing list