Hector, Here are my interpretations. Everyone, please bear in mind that these are just that and others are free to disagree. I'm not interested in getting into a debate about this.
It's not clear to me that this is really a standardization discussion at this point, so perhaps we should take discussions of this sort to another list such as [email protected]. Comments inline... hector wrote: > 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? I disagree that "all" is not actionable. There are several things the verifier/assessor can do. (1) Apply more stringent content checking (perhaps changing the threshold values or something). (2) If the GUI is under the control of the assessor (such as a webmail client), display a visual warning. If not, do something like add [dkim unverified] to the subject line. Some of you may have seen that if I responded hastily to a message without cleaning that up, because I have been trying that out for quite some time now. > > 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. I would advise against treating a signature that is invalid any differently from a signature that isn't present. There are intermediate agents that might break the signature, and we don't want to give the impression that applying a signature might increase the risk of non-delivery. Furthermore, dkim=unknown has the same meaning as the lack of an ADSP record. > > 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? dkim=unknown doesn't imply that there is any Author Domain Signing going on, and it is always (regardless of the ADSP value) OK for an intermediary to apply a DKIM signature if it's willing to take responsibility. So ADSP is completely silent on the presence or absence of third-party signatures. Again, dkim=unknown has exactly the same semantics as the lack of an ADSP record. A published ADSP record will normally have a longer time-to-live than the negative caching of the lack of one, so publishing a record will cut down on DNS traffic. My answer is that this is an incorrect consideration. Hope this helps. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
