> We do notice all of those things, and we do use that to determine which are spam and which are not with some level of accuracy. It seems the weights of these things on spam filtering have been changed recently for the worse. I haven't seen these attacks in such volume before.
> It seems like you want us to block all of these messages at smtp time. We do block a lot, but not all. Partially, we don't block them all so that there is some chance for false positives to make it to the spam label where they can be marked not spam. That would be a logical thing to do in cases like I just reported, where the IP is extremely bad, or rDNS is missing, or it's in -all. Softfail cases should be treated like you described. > generally speaking the spam label is much more expensive to us than blocking at smtp time, so keeping the size of the spam label is a goal So here's a pretty low hanging fruit for your team. The samples I sent should be easy to reject just on basic sane mail server requirements. I still don't understand how a replayed message with oversigned From,To,CC,Subject,Date headers could pass DKIM authentication at Gmail. I don't have sample headers, but there are millions of messages like that sent on Feb 28 from the spam IP ranges I mentioned in the initial email. [image: Sender] Edgar Vaitkevičius, founder / CEO ed...@sender.net On Wed, Mar 2, 2022 at 9:20 PM Brandon Long <bl...@google.com> wrote: > > > On Wed, Mar 2, 2022 at 10:51 AM Edgaras | SENDER via mailop < > mailop@mailop.org> wrote: > >> > It does seem like Google could notice "old" date headers and BCCs and >> the fact the mail is coming from a dedicated spam factory and maybe treat >> it a little differently, though. >> >> My point exactly. They could maybe notice it's hard failing SPF, or rDNS, >> or just about every requirement they have published. >> > > We do notice all of those things, and we do use that to determine which > are spam and which are not with some level of accuracy. > > It seems like you want us to block all of these messages at smtp time. We > do block a lot, but not all. Partially, we don't block them all so that > there is some chance > for false positives to make it to the spam label where they can be marked > not spam. > > And yes, we know that scams getting to the spam label have some potential > for harm, and we do try to limit that in multiple ways... and of course, > generally speaking the spam label is much more expensive to us than > blocking at smtp time, so keeping the size of the spam label is a goal. We > know that spammers send billions of messages just to get some into the spam > label. > > Brandon >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
