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
rfc-editor(_at_)rfc-editor(_dot_)org 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: rfc-editor(_at_)rfc-editor(_dot_)org
To: ietf-announce(_at_)ietf(_dot_)org, rfc-dist(_at_)rfc-editor(_dot_)org
CC: ietf-dkim(_at_)mipassoc(_dot_)org, rfc-editor(_at_)rfc-editor(_dot_)org
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: eric+dkim(_at_)sendmail(_dot_)org,
fenton(_at_)cisco(_dot_)com,
markd+dkim(_at_)yahoo-inc(_dot_)com,
standards(_at_)taugh(_dot_)com
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
rfc-editor(_at_)rfc-editor(_dot_)org(_dot_) 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