Re: IPv6 issue
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: IPv6 issue
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
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
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
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 records than A records? -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: IPv6 issue
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. signature.asc Description: PGP signature
Re: IPv6 issue
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 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 record if it's not going to be utilizing it. I'd instead suggest adding an alternate name with the (bogus) 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 smime.p7s Description: S/MIME Cryptographic Signature
Re: IPv6 issue
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 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 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 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 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/ no longer returned an 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 13a 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 1a 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
Re: IPv6 issue
Ted Mittelstaedt 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 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/ no longer returned an 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: 4gmail 13a mailinglist/forwarding host (lists I'm on -- they don't filter well enough) 2my own v6 address - need to look into this, but pretty sure it is external spam logged oddly 1a 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. signature.asc Description: PGP signature
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 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
