Mailing List Archive

IPv6 issue
Hi All,

I hope this does not start a holy war.

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?

Ted
Re: IPv6 issue [ In reply to ]
Ted Mittelstaedt <tedm@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.
Re: IPv6 issue [ In reply to ]
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 <tedm@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.
Re: IPv6 issue [ In reply to ]
On 5/6/22 10:49 AM, Ted Mittelstaedt wrote:
> Arg. Well I think you hit the nail on the head. And I think I may
> have stumbled on to a spam defeating trick.

Ya ... not running email server on IPv6 is a way of not receiving (some)
spam. But I view it very similarly as not running an email server
period is another way of not receiving (all) spam.

It's a short term gain that has long term negative repercussions.

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

What you are describing is the premise behind "No Listing". The two
primary ways it's done is to 1) leverage TCP timeouts or 2) leverage a
TCP Reset. Either way, you're tickling bugs that alter behavior of spam
cannons. Things that proper SMTP servers handle much more gracefully,
most without any problem at all.

> 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 would encourage you to not have your host's FQDN include a AAAA record
if it's not going to be utilizing it. I'd instead suggest adding an
alternate name with the (bogus) AAAA record and reference that in MX
records.

> It is in effect a sort of tarpit I believe.

That's not tar pitting to me. Tar pitting would be answering and
replying extremely slowly. Such that you burn a LOT of time for an
established and arguably functioning (as in exchanging data) SMTP
connection. Like one character per second or every few seconds.

> 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

DNS zone files don't have a way to force ordering. Some DNS servers,
BIND in particular, does have the ability to sort records.

> Of course, spammers could get around this by recompiling their bots
> to use only IPv4.

You can apply No Listing to different IPs within a protocol and / or
across protocols.



--
Grant. . . .
unix || die
Re: IPv6 issue [ In reply to ]
I agree with what Grant said.

Also, I wonder how much greylisting would help, and if you were already
doing that. The data I posted is for a machine that already does
greylisting in general, with varying times depending on inclusion in
various RBLs and local data.

I find that delaying connections from unknown places even 2 minutes
helps a lot.
Re: IPv6 issue [ In reply to ]
On 6/5/22 6:31 pm, Ted Mittelstaedt wrote:
>
>
> 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.
>

Were there more hostname variations with AAAA records than A records?

--
Jeremy
Re: IPv6 issue [ In reply to ]
I used to greylist and it helped a lot.

2FA killed that, however. When someone logs into a website, bank, etc
quite often they use an email address as the second factor - so for that
to work the email has to be delivered instantaneously. Also most 2FA
does not follow any kind of SMTP standard, the will attempt delivery
once and not retry if it fails.

Once 2FA became a big deal for the banks I got far too many user
complaints on the greylisting to keep it.

Ted

On 5/6/2022 5:39 PM, Greg Troxel wrote:
>
> I agree with what Grant said.
>
> Also, I wonder how much greylisting would help, and if you were already
> doing that. The data I posted is for a machine that already does
> greylisting in general, with varying times depending on inclusion in
> various RBLs and local data.
>
> I find that delaying connections from unknown places even 2 minutes
> helps a lot.
Re: IPv6 issue [ In reply to ]
On 2022-05-07 02:39, Greg Troxel wrote:
> I agree with what Grant said.
>
> Also, I wonder how much greylisting would help, and if you were already
> doing that. The data I posted is for a machine that already does
> greylisting in general, with varying times depending on inclusion in
> various RBLs and local data.
>
> I find that delaying connections from unknown places even 2 minutes
> helps a lot.

i use sqlgrey with 60 mins, but at same time only for recipients that
can live with delays :=)

long delays helps rbls to know more spammers, with after greylist delays
is know as more spam

i cant use postscreen for this policy, so yes in some needs both
postscreen and sqlgrey is super

sqlgrey i have ip whitelist of known maillists to not delay, and
recipient listed in postgresql where opt out, all the best defense is
there
Re: IPv6 issue [ In reply to ]
On 2022-05-07 09:55, Ted Mittelstaedt wrote:

> Once 2FA became a big deal for the banks I got far too many user
> complaints on the greylisting to keep it.

2fa should NOT be done on email

idiotic banks :)
Re: IPv6 issue [ In reply to ]
On 5/7/22 1:55 AM, Ted Mittelstaedt wrote:
> I used to greylist and it helped a lot.

I used to use grey listing too. I've found no listing to be equally
effective.

> 2FA killed that, however. When someone logs into a website, bank,
> etc quite often they use an email address as the second factor -
> so for that to work the email has to be delivered instantaneously.
> Also most 2FA does not follow any kind of SMTP standard, the will
> attempt delivery once and not retry if it fails.

No listing tends to benefit from this in that the sender is able to use
the next server in line as soon as the sender can establish the
connection fractions of a second later.

> Once 2FA became a big deal for the banks I got far too many user
> complaints on the greylisting to keep it.

I've not knowingly had any problems with no listing like I used to have
with grey listing.



--
Grant. . . .
unix || die