Jim Fenton wrote:
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 dkim-ops(_at_)mipassoc(_dot_)org(_dot_)
Perhaps. Not interesting in extending this beyond other than a
thought. If others want to initiate an ERRATA, I am not asking for it.
I think it is unclear of the purpose of having DKIM=UNKNOWN if its not
for optional but exclusive Author Domain (AD) signing. I hear what
you said. But ADSP is about exclusive AD signing. No?
OPTIONAL
ALWAYS
ALWAYS+DISCARD IF INVALID
is pretty much how I read it and how I was thinking of it having it
documented for people.
Not having a ADSP should be the only thing that says you are not an
ADSP participant. The people JL says will never publish it.
But having one, even as an UNKNOWN should suggest something other than
non-ADSP participation.
JMO
---
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html