On 12/17/20 3:07 PM, Chris via mailop wrote:
Secondary MXes have a role as your main mail server. Long experience with spambotnets reveals that most of them are pretty stupid, because their MX capabilities are limited. In fact, many spambots infections don't do any DNS lookups at all, and rely on pre-recorded resolutions done centrally, of JUST the primaries, and in some cases long after the resolution has gone stale. In particular, the spambot responsible for most bitcoin extortion and Russian pseudo-Canadian Rx is a good example of something that caches resolutions for as much as a year or more.
Oh wow. That's interesting. Sad. But interesting none the less.I've long thought the most effective way successfully send spam is to send it through a properly configured RFC complaint SMTP server.
Some of my most effective spamtraps don't have anything MXed at them anymore. I've had one trap move from one set of IPs to another. The old MXes actually generate more infected IPs than the new ones do EVEN WITHOUT treating anything hitting the old MXes as infected by definition.
Hum....
[My bot detection rules on the new IPs is around 60% of total traffic. Damn spot on 100% on the old ones.]
O.O
A few other spambots think they're smarter than you, and will deliberately spam the worst priority MX thinking that these will be the servers that have the weakest filtering.
This is where Junk Email Filter's Project Tar [1] comes into play.
If you have a few IPs to burn, and an existing mail server, this is what I recommend:1) Set up a secondary MX pointing at your real mail server with full spamfiltering. 2) Set the primary MX pointing at a stub that does nothing more than do a reject on HELO/EHLO. 3) Set a tertiary MX pointing at an IP that doesn't actually have anything listening.
I prefer a slightly different approach.1) Point the primary MX at a server with nothing listening. It will send TCP Resets. -- I know this as "No Listing", a varient of "Grey Listing". -- I have yet to see any negative side effects wit this.
2) Point the secondary MX at your main mail server. -- Business as usual. 3) Optionally - Point the tertiary at your backup mail server. 4) Point the last MX at something like Project Tar.
Many spambots will hit the primary, get a failure, and simply give up. Real servers will hit the primary, then try the secondaries. A few spambots will hit the tertiary and waste their time waiting for something that won't happen.
I like how Project Tar publishes an RBL of bad actors that don't adhere to RFC specific protocol, like pre-greeting traffic. This is nice to feed into SpamAssassin rules.
Note: both the primary-MX reject, lower priority MX hang proposals did make the rounds, separately, many years ago on, say, Usenet discussion forums.
Do you have any references off hand? If not, I'll go do some digging.
I can personally assure you that they really do work, but your precise mileage may vary.
I too have had -- what I consider to be -- exceedingly good luck with what I outlined.
[1] Project Tar - https://wiki.junkemailfilter.com/index.php/Project_Tar -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
