--- "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
If that's really it, then my current implementation would see
q=xkms and
set:
Authentication-Results: dkim=neutral
I assume that you agree that my implementation is correct.
Provided that is consistent with the policy record. IE if the policy
record says that every message is signed with q=dns then q=xkms is an
error.
Hmm. This is an interesting definition of "optional". I think any xkms-type
proposal needs to be optional for the receiver too - which is what Michael's
sample implies. However, the way you're casting it is that the sender could
dictate to the receiver that they *have* to fetch via xkms, is that correct?
If so, that's not something I could support as I don't want senders deciding
that I have to initiate xkms fetches to achieve a base level of authenticated
email. An optional augmentation beyond authentication sounds fine, but as a
base level, no.
By optional augmentation, I had something in mind along the lines of where this
thread started; namely optional fetches for reputation/accreditation. For that
part, I could support an xkms-type fetch.
Mark.