Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity

[Dave Crocker <[e-mail]>]

On 4/14/2013 7:08 PM, Tim Draegen wrote:
> On Apr 12, 2013, at 5:35 PM, J. Gomez <[e-mail]> wrote:
>> 4. (Uselessness problem) This proposition achieves nothing.
>>
>>     --> True. It's not the intent of the "l=" tag to achieve anything nor to convey policy from Sender to Receiver. The "l=" tag merely conveys additional information from Sender to Receiver, and the Receiver is free to consume it as he wishes or to disregard it altogether.
>
>
> This here.  If the tag doesn't achieve anything and could very well be wrong ('cause there is no measurable impact to getting it right), it'll just add noise to a receiver's decision making, and therefore {all of your other counter-arguments}.
>
> To game this out, *IF* this tag existed and was accurately used, as a receiver I'd still have to figure out what sources are mailing lists in order to make the extra "l={yes,no,dunno}" tag useful.  Let's say I have perfect mailing list knowledge, what then am I supposed to do with email coming through a mailing list from a domain with the "l=no" tag?  If the answer is "nothing", then why is this tag even there for me to look at?
>
> I guess I'm left with "How does this make anything better?"
>
> IMO Michael Adkins wrote it best:
>
>> 7.  Operational Issue
>> This problem is better solved by making data about legitimate mailing
>> lists publicially available so everyone can apply local policy overrides
>> consistently.


Anything that smacks of hints, heuristics, guessing and statistics 
invites more noise into the system.  As a rule, that's not good for 
standards-based activities and are best left to outside processes.

The underlying issue here seems to be a) message handling by 
non-transparent intermediaries, and b) their not necessarily playing in 
the dmarc sandbox.

I think there is nothing useful that can be done in terms of DMARC 
standards for the latter.  If they break stuff and won't help fix it, 
the topic is done.

For the former, it sounds like a case of wanting some kind of transitive 
trust, which moves us back to having the mediator do inbound dmarc 
validation, record it into the A-R header field(?) and then ensure SPF 
and DKIM authentication and maybe dmarc publishing, too.

It might also make sense to add some sort of "I am a mediator who 
processed this message and assert the following truths..." and then 
include that field in the dkim signature hash.  That is, to define some 
additional authentication semantics for mediators, if they wish to play 
in this sandbox.  The presence of this extra header field asserts a set 
of semantics and the dkim signature validates its presence (depending 
upon the reputation of the signing mediator's domain, of course.)

This provides a kind of authenticated audit trail, but of course still 
leaves open the question of how it would be handled by receivers.

d/

-- 
  Dave Crocker
  bbiw.net