Thousands of ssh probes

Chuck Swiger cswiger at
Sat Mar 6 14:19:36 UTC 2010

On Mar 6, 2010, at 4:36 AM, Matthew Seaman wrote:
>>> 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
> through.

While this is undoubtedly true in some cases, you're offering too much  
credit to the spammers for other cases.  :-)

There are spambots which simply scan through IPv4 address space trying  
to talk to port 25, and they attempt to deliver the same spam (or some  
template put through an obfuscator which adds random text) to a list  
of usernames, regardless of MX records.  Some try to deliver to  
unqualified addresses (ie, rcpt to: <cswiger>); others do a reverse  
lookup of each address and append the domain name to the addresses.   
It's pretty easy to notice this when you've got a bunch of IPs setup  
on different domains.

Anyway, for personal domains, you can setup teergrubes on both high  
and low numbered MX records, which delay but never accept mail, and  
have your real mailserver in the middle.  Unfortunately, there are so  
many broken SMTP servers out there, which don't retry delivery to all  
MX hosts, that a fair amount of "legitimate" email will be lost-- you  
can't realistically do this for normal users.

> 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.

The two main uses are:

1) If your primary MX is where delivery happens, and it goes down or  
is otherwise unavailable for a while, you can do an ETRN against the  
secondary(-ies) and get all of the queued mail relatively immediately  
once you fix the issue.  If you have drastic problems (ie, a box goes  
down permanently and you can't get a replacement up in less than a  
week due to shipping time), you can even have your secondary queue  
email for longer than the default 5 days if that becomes necessary.

2) Domains without permanent network connectivity:


More information about the freebsd-questions mailing list