Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 Oct 2013 17:04:32 +0200

On Sun 22/Sep/2013 16:02:23 +0200 Roland Turner wrote:
> On 09/17/2013 12:33 PM, Scott Kitterman wrote:
> 
>> DMARC does have a few more knobs to turn, but if you don't want
>> mail that fails authentication sent to the receiving user, you
>> have to use p=reject and that has the exact same problem with 
>> mailing list subscriptions that ADSP does.
> 
> Noting that we're talking about a very narrow situation (and yes, now
> that I look at it, your choice of Subject: points this out) that both
> ADSP and DMARC authors accept is beyond their reach (both protocols
> are expected to reduce the problems that they address, not to
> magically solve them without side-effects), meaning that the broader
> argument is not being addressed:
> 
>  * DMARC provides domain owners with visibility of this situation ahead
>    of a decision to switch on p=reject, ADSP does not. This materially
>    changes the situation. It allows a domain owner to make informed
>    choices, rather than guess, to plan appropriate trade-offs, to
>    monitor the situation on an ongoing basis and to discover unexpected
>    consequences as and when they arise.
>  * DMARC makes concrete (through override reasons of forwarded,
>    trusted_forwarder and mailing_list) reasons for receiver's
>    discretion which ADSP did not. As a practical matter the exercise of
>    discretion is required in either case, but DMARC raises it to a
>    recognised element of the protocol rather than an invisible activity.
> 
> So, even for the narrow situation that you're asking about, DMARC does
> considerably better than ADSP.

While the above is true, DMARC feedback is no crystal ball.  Mailing
lists are so uncommon that a domain with a small to medium number of
users could monitor its feedback for months before stumbling upon
lists.  At that point they'll be told they should have known that
p=reject is only for domains with no users, receivers will learn to
only honor such policy for the usual list of heavily phished domains,
and perhaps someone will want to move DMARC to historic.

IMHO we should pick up one or more of the recipes in RFC 6377, and/or
some proposed third party or joint signatures schemata --however
little the adoption they have enjoyed thus far-- and proclaim them the
official workarounds for this problem.  Currently, the spec mentions
"local heuristics", which varies too widely from one verifier to
another to characterize the override as a protocol element.

Ale