Subject: [ietf-dkim] http://tools.ietf.org/html/draft-kucherawy-dkim-atps-00

From: Jeff Macdonald <[email-masked]>
Date: Wed, 22 Sep 2010 14:22:31 -0400

Nice!

This is very much like a proposal that Dave and I put together, but:

1) is focused on ADSP
2) uses MD5 for creating a label for lookup

The proposal Dave and I did, "Affiliated Names List"*, was a way for a
domain owner to publish affiliations with other DKIM domains. My
motivation for that proposal was driven by the belief** that 3rd party
signatures, which I will now call Non-Author DKIM Signatures, would be
treated differently than 1st party signatures.

If there is a consensus that Non-Author DKIM Signatures should be
scored negatively***, then I suggest the scope of this document could
be expanded by simply removing the requirement that there be an ADSP
tag present. This would allow domain owners who are not participating
in ADSP to use the same infrastructure that this draft puts in place.

PS - I apologize if this draft isn't within our charter.

* http://mipassoc.org/affil/specs/draft-macdonald-affiliated-nameslist-00-04dc.html
** due to some chatter at various industry meetings
*** I for one, do not believe that Non-Author DKIM Signatures should
be scored negatively for just being themselves

-- 
Jeff Macdonald
Ayer, MA
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Sep 2010 11:50:23 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Jeff Macdonald
> Sent: Wednesday, September 22, 2010 11:23 AM
> To: DKIM WG
> Subject: [ietf-dkim] http://tools.ietf.org/html/draft-kucherawy-dkim-atps-00
> 

That remains an unknown.  I still haven't figured out what policy should be exposed to verifiers when ATPS hits but ADSP doesn't.

> in ADSP to use the same infrastructure that this draft puts in place.

Sure, it's possible consensus will go in the direction of supplanting ADSP with this.  It certainly could (and I actually hadn't even thought of that until now).  If that's the case it won't be hard to detach it from ADSP altogether.

> PS - I apologize if this draft isn't within our charter.

I suggest we discuss it on [email-masked].  It's active on [email-masked], but I think that's also the wrong place for it as it's not an operational concern (yet).

-MSK