Arg. Well I think you hit the nail on the head. And I think I may have
stumbled on to a spam defeating trick. Here's what I think MAY be going on.
As we all know spammers are the textbook drive by shooters. They are
going to try the first A returned from the mailserver just like a
regular mailer.
The problem for them is that if there is no response from that A record
then normal TCPIP stack is going to wait for a while then eventually
time out. When you are sending a bazillion spams you cannot afford to
tie up a process waiting around to see if a remote will eventually
answer if it does not initially answer right away since at the high rate
they are sending spams they would rapidly overflow memory on host
machines, the mules, their bots are using to send out spam. This would
then cause those machine owners to investigate and remove those bots.
In addition their mules often operate on dynamic IP zones which are
blocked by many ISPs. They can't tell if it's a network ACL blocking
them or if the IP simply isn't there. So their bots try for a
connection and if there is no response the bot quickly kills the process
and moves to the next victim.
I did not remove the AAAA records because the IPv6 RFCs require that if
the initial connection tried with IPv6 fails you retry with IPv4.
I SUSPECT the vast majority of mules are compromised systems that have
public IPs most likely end user workstations plugged directly into the
Internet or to cable modems and so on. These machines have valid
working IPv6 numbers. (for example, plug a workstation into a Comcast
cable modem. It will get a private IPv4 translated number and a public
IPv6 number.) So their TCPIP stacks will automatically try IPv6 first.
The bot is not then attempting to try the IPv4 number, it's on to the
next victim host in the MX list.
So this makes an interesting possible way to block spammers. Simply
define an IPv6 number that does not exist as AAAA for each of your MX hosts.
Legitimate mailservers will retry the IPv4 and complete the connection.
Drive bys cannot afford the time to verify that the IPv6 address is
timing out and then retrying the IPv4 for that host.
It is in effect a sort of tarpit I believe.
You could extend this to defining multiple nonexistent numbers for an
IPv4 host except that DNS does not seem to have a way to force ordering
of multiple IPv4s
Of course, spammers could get around this by recompiling their bots to
use only IPv4. But then that means RBLs suddenly become extremely
effective since there are so vastly fewer IPv4 numbers out there. Also
a bot operating on a compromised mailserver that has a history of
sending via IPv6 would stick out like a sore thumb and be easy for the
majors to block.
I think I will run the mailserver like this for a few weeks and see
what happens and if there are any user complaints.
Ted
On 5/6/2022 4:40 AM, Greg Troxel wrote:
Ted Mittelstaedt <t...@ipinc.net> writes:
For unrelated reasons I had to turn off IPv6 on my incoming mailserver.
Spam plummeted. Like by 80% at least. Both uncaught and caught spam did.
When IPv6 was on, the mailserver had all PTR and AAAA and MX records to
allow it to receive incoming mail via IPv6.
Something about this seems really wrong. Any suggestions of where to
start digging?
Something indeed seems fishy. I look at uncaught spam to see what I
should tweak on a routine basis, and my impression has been that it's
overwhelmingly either places like gmail (which tend to be delivered over
v6 but would of course come v4 if you don't have v6), or v4. So being
v4 only and getting 20% of the spam you used to get just doesn't make
sense.
When you "turned off" IPv6, did you change DNS so that doing MX/A/AAAA
no longer returned an AAAA record?
Did you notice a reduction in legit mail and an associated increase in
complaints?
When you looked at incoming spam from the time when you had the normal
v4/v6 setup, did you find that most spam arrived over IPv6?
I looked over my own logs. In the log interval I examined there are
spam counts:
329 MTA rejects (which I count as 100% spam)
139 filed as spam by the normal SA standards (>=5)
26 filed as marginal (>=1 < 5)
13 filed as ham (<1)
I'm not examining things misfiled as spam that I refiled into ham
folders. I also skipped about 13 spams misfiled as ham, but on a quick
scan they fit the same pattern.
Looking at the 329 MTA rejects (because that was easiest):
309 IPv4
20 IPv6
and of the IPv6:
4 gmail
13 a mailinglist/forwarding host (lists I'm on -- they don't filter
well enough)
2 my own v6 address - need to look into this, but pretty sure it
is external spam logged oddly
1 a v6 address with no rDNS that is probably some compromised
server that happens to have v6 set up. As far as I can tell
it is some company in .au.
Looking over the 139 >=5 spams, it's mostly v4, and of the v6, once I
exclude google and the same mailinglist, there is only1 v6 address, this
time a random company in .es.
So for me, spam over v6 is very rare, except for mailinglists without
adequately strict filtering and google (which we all know doesn't do a
good enough job of outgoing filtering, but that's not about v6).
Thus, I don't know what to make of your experience; something about it
must be very different and understanding that is likely interesting.
