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 [email protected].
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
