Re: MAILING_LIST_MULTI

On 2025-02-25 at 09:31:44 UTC-0500 (Tue, 25 Feb 2025 09:31:44 -0500)
Greg Troxel <[email protected]>
is rumored to have said:

> Bill Cole <[email protected]> writes:
>
[...]
>>
>> I will look at adding an extra condition in that meta-rule.
>
> I am on multiple googlegroups.  (Yes, it's a bug that anyone hosts 
> their
> mailinglists there, but that's another story.)  I find
> MAILING_LIST_MULTI to be useful, because it counteracts the "DKIM 
> failed
> because the list munged the message" and things like that.  So just
> excluding google groups doesn't really seem right.

Well, the original rationale of that rule was to match common mailing 
list managers whose setup and administration makes them uncommon for 
spammers to use. Clearly Google groups is not presenting that higher bar 
to entry.

> The problem with googlegroups is that google seems to let people 
> create
> groups and add people to them.  Really, that google seems to choose to
> allow spamming with gmail in general.

Yes, Google is a net bad actor regarding spam. I personally treat them 
as a default spam source, so that mail from any part of their open sewer 
must have some affirmatively positive indicators to even be seen by SA. 
Obviously, I don't believe that such a policy fits SA or even the mail 
systems I work with that are not my own.

However, I would strongly advise that anyone needing to reliably receive 
Google Groups mail look at local protective practices for specific 
groups based on  the List-ID, X-Google-Group-Id, or Mailing-list 
headers. Even if our RuleQA doesn't prove out the value of an exclusion 
of them from the MAILING_LIST_MULTI rule, there will probably be some 
other work towards catching that spam. This is something like the fourth 
time people have brought this problem up here, so it is not going away 
until SA starts marking Google Groups mail as spam or it stops being 
predominantly spam.

> I think what's needed is some kind of database of which lists are ok,
> sort of like welcomelist, maybe like txrep.  Maybe a groups RBL, so 
> new
> ones are like DOB.   But in general I am concerned about leaking too
> much mail info into RBL queries already.

I see no way for the SA project to manage such a database responsibly, 
given the effort and risks involved. TxRep should help locally if it is 
active. In this case, the fact that the domain was under a fortnight old 
was caught, but that rule is not very strong.

I would cheer a 3rd party taking on the work and risk of a mailing list 
registry designed for identifying well-behaved mailing lists. Without 
big players like Google being able to certify their lists, such a 
project would be a challenge.



-- 
  Bill Cole
  [email protected] or [email protected]
  (AKA @[email protected] and many *@billmail.scconsult.com 
addresses)
  Not Currently Available For Hire