Hi Bill, thanks for the detailed explanations. I understand the purpose of the def_whitelist_auth list better now, but wonder if its benefit is not overcompensated by significant negative effects, certainly not desired by the community.
First of all, I would like to contribute some statistical findings: A look at the exemplary group of the largest 1,000 U.S. online stores according to Alexa Rank shows that about 15 percent of the domains are whitelisted in 60_whitelist_auth.cf. There are no significant and especially no consistent differences in the email reputation of these 15 percent compared to the rest of the top 1,000. This would not be a problem if the Spamassassin whitelist did not unintentionally give the 15 percent a competitive advantage. Based on the high spam score bonus of 7.5 points, which USER_IN_DEF_DKIM_WL and USER_IN_DEF_SPF_WL bring, one can for example risk a higher frequency of mass mailings, run riskier reactivation campaigns or write to "broader" distribution lists: Possible spam scores, for example due to blacklisting, would be ironed out by the above-mentioned "bonus". And indeed: With some stores from the 15 percent group I see again and again - partly even consistently - serious blacklistings. There are about 16 DKIM rules and 12 SPF rules in Spamassassin that are meant to evaluate in a technically automated way whether and how good the SPF and DKIM implementation of a sender is. Interestingly, the comment in 60_whitelist_auth.cf. says: "These listings are intended to (...) reward senders that send with good SPF, DKIM, and DMARC." With this in mind, it seems like a logical overlap to me that USER_IN_DEF_DKIM_WL and USER_IN_DEF_SPF_WL introduce additional high "bonus" scores based solely on human judgment at the one-time point of a check. Almost all of the senders listed in 60_whitelist_auth.cf have changed their email service providers one or more times over the years, with sometimes significant changes in the quality of their deliverability settings and with significant differences in list hygiene, sending frequency, etc. But the spam score bonus of 7.5 remains nailed down all the time! In short, I would recommend considering removing the DKIM and SPF whitelists in Spamassassin altogether. It would make the spam-fighting world a better and fairer place! Best, Robert > Am 29.06.2021 um 06:52 schrieb Bill Cole > <sausers-20150...@billmail.scconsult.com>: > > On 2021-06-28 at 17:04:05 UTC-0400 (Mon, 28 Jun 2021 23:04:05 +0200) > Robert Harnischmacher <robert.harnischmac...@publicare.de> > is rumored to have said: > >> In which form can one submit the subdomain of a mail sender for the >> integration in 60_whitelist_auth.cf. Which information is required for >> consideration? > > There is no process by which a sender can pro-actively apply for the addition > of a def_whitelist_auth entry in that file. Entries are added rarely, when a > committer to the project sees a need for an entry due to false positives or > borderline scoring of messages from a sender who is not known to send ANY > spam and is known to send "ham" that users value highly. Removal of entries > is equally ad hoc and unilateral, and more rare. If a committer is convinced > that an entry is causing spam to be misclassified as ham, they can remove > that entry. > > Note that the above describes concrete process and vague criteria, not any > sort of objective formal policy. There is no objective official policy. The > normal state for any sender is to not have an entry. I believe that most > committers to the project would agree with me that ideally there would be no > such list because high-value ham would be more readily distinguishable from > spam. Additions and removals happen when they are believed to address a > concrete problem being experienced by actual SpamAssassin users. I don't > recall any significant disagreements about entries in that list, but if there > were any they could be discussed here or on the 'dev' list. Ultimately, the > PMC would be the final authority on including an entry or not, however our > processes for deciding anything that becomes an issue for the PMC is biased > towards stability, not agility. > > > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire
smime.p7s
Description: S/MIME cryptographic signature
