It looks like some spammers have decided that snafu.priv.at is worthy
of a bit of hurt: sending out spam with the
header set to <randomglibberish>@snafu.priv.at has the "nice"
side-effect of directing all the bouncy crap my way.
As you can see in the stats graph above, since May/June there are on average a thousand attempts each hour, all around the clock, to send me such crap. The usual spikes are a lot worse, about 3300 to 4500 attempts per hour, lasting half a day. That's more than one piece of crap per second...
And these are only the ones that I can toss early in the SMTP conversation: MAIL FROM: without domain or with known-bad address (e.g. email@example.com), RCPT TO: nonexistent on my side. (The ones that make it through this phase still have to make it further through my fairly stringent spamassassin, which issues days-long IP blocks against elegible purveyors of refuse.)
But the really annoying bit is that most spammer assholes seem to have cottoned up to the fact that any self-respecting, standards-compliant mail receiver mustn't block mail with MAIL FROM: <> - which is meant for transporting legitimate bounces.
So guess where I get most refuse from? Right, disguised as bounce mail, and that way I don't even get a chance of blacklisting the parties sending me the stuff...
Short of having access to any effective retaliatory equipment I've now started throttling my mailservers not just via milter, sendmail's rate and connection rate controls but also with the kernel firewall: the sendmail rate control is nice but way too polite as it only refuses commands with 4xx but doesn't actually shut down TCP connections.
So now I run two iptable recent matches before sendmail even gets a sniff. The first is one that restricts new SMTP connections to one per minute (per source IP), and currently that's not a sliding window (i.e. the other side doesn't have to shut up for 60s before being let through but rather gets a guaranteed chance 60s from the previous successful SYN packet).
This seems to help a lot and doesn't seem to affect legit mail delivery any, as queue runs should be 10-15 min apart. Since I added that feature a few days ago the spikes have been a lot better (and I see lots of packets being denied, hehe).
The second recent match refuses new connections for four days, and
is only acted out by the firewall but not controlled by it. IPs are added to
that recent table from userland, by my mimedefang milter which simply writes
/proc/net/xt_recent/SMTP (a very nifty feature of
the recent stuff).
And IPs are added when we see a spammer who is obviously not
just an unwitting creator of backscatter:
- when they send us email that predends to be from nonexistent@my domains,
- when they send email that pretends to be from an external address that does not exist (we check by talking SMTP back to the relevant servers; if they refuse accepting a bounce to this addy then it's faked or fucked, and I don't care for it either way),
- if they feed us viruses (not that i care but my users might),
- or if they feed us crap that goes to nonexistent@my domains (but not if it's from <>, because that can be a legit bounce or an SMTP verification just like I do myself).
This (regrettably) prickly and fastidious behaviour is the best that I've come up with so far which keeps my servers from blowing up from the garbage deluge but which doesn't violate the standards itself. (And don't tell me I should use SPF, because it's a lousy idea that causes extra breakage instead of solving any problems.)