Re: [ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)]

[hector <[e-mail]>]

Congratulations on getting this published.  Hopefully, it will taken 
serious by many domains to help provide a reasonable return on DKIM 
processing. In lieu of a standardized (and public) reputation system, 
network, ADSP can give some value.

I have a few questions seeking clarification, confirmation mostly, 
because if I'm going to begin to implement DKIM with an ADSP focus for 
our customers, we will need to be able translate the information in 
the spec into easy to understand documented and online "Help" for 
customers.

1) With the policies:

    dkim=all vs dkim=discardable

In layman terms, one is actionable (discardable) and one is not (all). 
One is an "Error" resulting in a reject, one is a "Warning" not 
resulting in a reject, in both cases, can be logged/recorded?  Our GUI 
setup may show it like so for example:

   Author Domain: domain.example

   DKIM Signing Policy:

   (o) unknown     - your mail may be signed

   (_) all         - Your mail are always sign, however
                     verifiers SHOULD NOT reject invalid signatures.

   (_) discardable - Your mail are always sign, and
                     verifiers MUST reject invalid signatures.

   [ PUBLISH ] [CANCEL ]

Is that the basic translation and fair way to put it?

2) DKIM=UNKNOWN

Is there any actionable logic for optional signing?

I mean, you may not always sign, but if you do, it must not be invalid?

I just want to make sure in our help/doc to indicate whether 
publishing with unknown is the same as no ADSP record. One is 
explicit, the other is implicit.  I may not always sign, but if I do, 
take it serious.  Having no records could be viewed you don't care 
either way.

I guess as it seems to be now, it would be a "Warning" but still 
acceptable (no rejection on this basis).  But see the tail end of 3.

3) Finally 3rd party signatures.

Please believe me I don't wish to rehash this. It was the one thing 
that I really felt will help domains.  Not so much in defining the 
difficult task for valid use cases for the inclusion of 3rd signature 
policies, but rather the exclusion of 3rd parties.  For example, 
appendix B.4 says:

B.4.  Third-Party Senders

    Another common use case is for a third party to enter into an
    agreement whereby that third party will send bulk or other mail on
    behalf of a designated Author or Author Domain, using that domain
    in the [RFC5322] From: or other headers.  Due to the many and
    varied complexities of such agreements, third-party signing is not
    addressed in this specification.

Ok, I accept this, we had hard time defining 3rd party situations. 
But this is not the same as the one hard logical conclusion a domain
may have:  He doesn't do 3rd party signatures nor expect it.

So it seems me that the explicit declaration of a ADSP policy, the 
only options provided to prevent it are the explicit DKIM=ALL and 
DKIM=DISCARDABLE declarations.

However, does the explicit DKIM=UNKNOWN declaration also imply 
exclusive Author Domain Signing?  An explicit DKIM=UNKNOWN should 
suggest ADSP operations only, even if the signature is optional.

Is that a correct or incorrect consideration?

Thanks

---

Jim Fenton wrote:

> I haven't seen this announcement here, probably because
> [e-mail] doesn't subscribe to this list.
> 
> -------- Original Message --------
> Subject: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain
> Signing	Practices (ADSP)
> Date: Wed, 12 Aug 2009 16:53:22 -0700 (PDT)
> From: [e-mail]
> To: [e-mail], [e-mail]
> CC: [e-mail], [e-mail]
> Newsgroups: gmane.ietf.announce,gmane.ietf.dkim
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>         RFC 5617
> 
>         Title:      DomainKeys Identified Mail (DKIM) Author
>                     Domain Signing Practices (ADSP)
>         Author:     E. Allman, J. Fenton,
>                     M. Delany, J. Levine
>         Status:     Standards Track
>         Date:       August 2009
>         Mailbox:    [e-mail],
>                     [e-mail],
>                     [e-mail],
>                     [e-mail]
>         Pages:      21
>         Characters: 43093
>         Updates/Obsoletes/SeeAlso:   None
> 
>         I-D Tag:    draft-ietf-dkim-ssp-10.txt
> 
>         URL:        http://www.rfc-editor.org/rfc/rfc5617.txt
> 
> DomainKeys Identified Mail (DKIM) defines a domain-level
> authentication framework for email to permit verification of the
> source and contents of messages.  This document specifies an adjunct
> mechanism to aid in assessing messages that do not contain a DKIM
> signature for the domain used in the author's address.  It defines a
> record that can advertise whether a domain signs its outgoing mail as
> well as how other hosts can access that record.  [STANDARDS TRACK]
> 
> This document is a product of the Domain Keys Identified Mail Working
> Group of the IETF.
> 
> This is now a Proposed Standard Protocol.
> 
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Internet
> Official Protocol Standards (STD 1) for the standardization state and
> status of this protocol.  Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   http://www.ietf.org/mailman/listinfo/ietf-announce
>   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [e-mail].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> USC/Information Sciences Institute
> 
> _______________________________________________
> 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