Thousands of ssh probes
cswiger at mac.com
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
>> 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
> Yes. Generally a high-numbered MX is more trusted than the run-of-
> the-mill internet by the actual mail server (lowest numbered MX)[*],
> 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.
> spammers ignore the normal MX priority rules and just attempt to
> spam through the highest numbered MX, because it is more likely to get
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