[ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

[Stephen Farrell]

On 15/09/10 15:43, McDowell, Brett wrote:
> On Sep 15, 2010, at 12:11 AM, Murray S. Kucherawy wrote:
> 
>> Based on that (rather precise) description, aren't ADSP's requirements a proper subset of the DKIM requirements?  If so, I'm not sure I agree with "badly conflicting", but it does frame future discussion quite nicely.
>>
>> For example, if DKIM enables the identification of mail streams, isn't the one ADSP covers just a specific instance of a mail stream?
>>
> 
> BTW, one thing I think we can agree on and find value from in these pre-deployment email discussions is terminology.  I ran into a problem at the last MAAWG during a panel discussion where my understanding of "3rd-party signature" is what someone else meant by "2nd-party signature".  What is the real definitions of "1st-party", "2nd-party" and "3rd-party" signatures in the context of DKIM and ADSP, i.e. in the context of i= and d= and from: values?

How does that relate to the current WG work items?

If it does, please start a specific thread the editor
can make sense of.

If it doesn't, do you think its really a good idea to
ask folks to get involved in a discussion of definitions
now?

Also, how does it relate to the subject line?

Please don't respond to this on the list unless you have to.

S.


> 
> 
>> ________________________________________
>> From: ietf-dkim-bounces at mipassoc.org [ietf-dkim-bounces at mipassoc.org] On Behalf Of Steve Atkins [steve at wordtothewise.com]
>> Sent: Tuesday, September 14, 2010 3:01 PM
>> To: DKIM List
>> Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
>>
>> The problem is that the two things have badly conflicting requirements. DKIM is based on a domain-based identifier that's independent of the From: domain, and that's where much of it's value comes from. ADSP is based on a domain-based identifier that must remain identical to the From: field at all times, and that's where it's sole value comes from. ADSP intrinsically conflicts with the original design case for DKIM, despite being piggy-backed on to it.
>>
>> So any document that puts forth even basic good practices for DKIM usage for monitoring sender reputation (use d= to differentiate mail streams) is going to be anathema to ADSP requirements (d= must be the same as the From: domain).
>>
>> And any ADSP-driven set of requirements (mailing lists should not only re-sign any mail they re-send, they should alter the From: address to match) is going to be considered nonsensical by people who consider DKIM a way to tie an identity cookie to a message.
>>
>> And, as we've seen, any compromise document is hated by pretty much everyone, even assuming you can get there.
>>
>> Cheers,
>>  Steve
>>
>> _______________________________________________
>> NOTE WELL: This list operates according to 
>> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>