Re: Enough DMARC whinging

[Miles Fidelman <[e-mail]>]

Alessandro Vesely wrote:
> On Thu 01/May/2014 17:18:38 +0200 Dave Crocker wrote:
>> On 5/1/2014 8:22 AM, Phillip Hallam-Baker wrote:
>>> Spam filters should know about things as important as mailing list
>>> subscriptions.
> +1
>
>> We have about 20 years of spam filtering experience in the industry.
>> The quality of modern filters is astonishingly good; it's the only
>> reason email remains viable for users, in spite of open-Internet spam
>> traffic being far above 90%.
>>
>> I believe that little or none of that filtering includes awareness of
>> mailing list subscriptions.  So while the above is an interesting and
>> possibly useful line of pursuit, it's not clear how it can be elevated
>> to the status of 'should'.
> It is certainly useful to simplify spam filtering.  I think there
> would be consensus on 'should'; not on 'must' because of privacy
> considerations.
>
>> Note that historically, mailing list operators have been resistant to
>> the imposition of technical or operational changes.

Speaking for at least one mailing list operator, who knows a lot more:  
I've ALWAYS implemented quite a bit of controls over our lists - both 
authenticating users before allowing them to join lists, and 
implementing extensive spam filtering at both the MTA and list level.  
The list software we use (Sympa), likewise has multiple spam and virus 
filtering mechanisms, as well as hooks for linking with external 
mechanisms.  I haven't worked with Mailman extensively, but it also has 
spam filtering mechanisms.

Spam is as much, or more of a problem for list operators, as anyone 
else.  What I object to is when someone foists a new mechanism down our 
throats - without any care for breaking things.

Actually, you may have unintentionally phrased this accurately: I (and 
probably other list operators) are "resistant to the IMPOSITION of 
technical or operational changes." Working WITH us, might yield better 
effect.  And there are at least two forms that could have taken:

1. Contribute support (labor/dollars) to write patches to the major 
email list packages, BEFORE turning on restrictive DMARC policies. (We 
are talking about large, well funded corporate entities who have 
invested dollars in developing and implementing DMARC for business 
reasons that presumably have signficant payback).

2. Designing and implementing mechanisms that mitigate the impact on 
mailing lists - for example, whitelists.

3. Actually developing something that plays nice with whitelists - as 
there is now some discussion about (XOAR, whitelists, ....).

> I'm not clear what you mean.  Is there a standard that defines mailing
> lists?
>
There are some that approach it - like the SMTP extensions for 
list-related headers.  I personally think mailing list functionality is 
well enough understood that we could improve on this, and incorporate 
some standard authentication mechanisms in the process.

Personally, I think some kind of standard that allows for:
- separate identification and signing/authentication of author, 
originating MTA, list/forwarder would go a long way (I think this would 
require additional headers and/or standardizing the use of existing 
headers a bit more tightly)
- maybe an extra list header or two regarding reply-to (separate author, 
author-errors, list, list-errors)
- a mechanism that allows a list to modify messages that doesn't break 
incoming signatures, say:
--- separate "original-subject" "subject-with-tags""listname" headers
--- a well-specified way to add a header and/or footer to a message 
(e.g., headers to indicate header-line-count, and footer-line-count)
--- provisions for MIME
--- i.e., a recipient can verify the original message and author, verify 
changes that have been made by a listprocessor, run some checks on the 
diffs, then make a decision on what to do with the message
- maybe some best practices for mail client presentation of information 
to end users

Miles Fidelman



-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra