I see it very slightly differently, but mostly agree Bill Cole <billc...@apache.org> writes:
> 1. We serve our users: receivers, not senders. Senders claiming FPs > need the support of a corroborating would-be receiver. Agreed. Or maybe we take requests to add only from receivers. > 2. If senders have FPs on objectively legitimate mail, their first and > most important step is to identify WHY SpamAssassin thinks it is > spam. and address that. Do you need the invisible text? Is the message > embedded in a remotely-fetched image? The sea of "&zwnj" entities in > your messages' HTML serves what purpose exactly? If there's a real FP > problem with some rule that regularly is proved out by RuleQA, open a > bug. Sure, but if you serve receivers, often people will have misfiling and the sender is opaque, even if not spam and dkim. So saying the sender should fix is misaligned with serving receivers. Yes, they *should*, but people shouldn't send html mail either :-) I agree that requests from senders should be met with "make your mail less spammy". > 3. This is NOT a general-purpose reputation list. It exists to aid SA > users who have FPs from SpamAssassin default rules for wanted mail, > where we cannot determine any acceptable adjustment to rules which > would avoid the problem. It is a "last resort" form of FP mitigation > when we cannot find an acceptable general solution that isn't > domain-specific to a widely accepted sender domain. I see all spam classification as probabalistic and there is risk of FP. If a domain emits *only ham* and is dkim signed, and we believe that receivers want it, I think it makes sense to have it in. I think of things like alerts from banks, airline saying your flight time has changed, etc. where FPs are a real problem. I am extremely skeptical of anything that smells of email marketing here. I would expect only places sending transactional mail and alerts to established customers. > 4. We should only add or remove listings based on specific requests > backed by transparent evidence. Subversion commit messages are not > enough, we need a bug report or a mailing list discussion. sure > 5. Existing entries are presumed valid unless and until they cause a > false "ham" classification of spam which can be shared publicly in a > useful form. I guess, or if someone makes an argument that they aren't right. > 6. New entries must pass prolonged RuleQA testing of sender-specific > rules before being added to the default welcomelist. I don't follow this. Do you mean add 'def_welcomelist_dkim foo@bar' to a testing ruleset and see if it's ok? That seems fine if so. If not, I didn't follow you. It might also make sense for each welcomelist rule to have a score. Basically to bring the mail down to -2, to give it some headroom. But that might be too complicated compared to benefit.
