Hmmm...
Given the predisposition folks have towards such misunderstandings, it
well might be worth a distinct section of text (with a table of
contents entry) that anticipates the problem and discusses it.
...that's probably worth doing, yes.
Thanks, Dave, for volunteering to write the text. Post here and send to
Eric when it's ready.
we should probably take this act on the road. i almost heard the ba-dump bump
from the drums.
- - - -
The overview is going to have this sort of text, though it would not hurt to
have it repeated, since it is non-normative.
So, how about some subset of:
DKIM lets an organization take responsibility for a message. That
organization is a handler of the message, either its originator or an
intermediary in the transport sequence. The owner of the domain name being used
for a DKIM signature is declaring that they are accountable for the message.
This means that their reputation is at stake. That is, their reputation is the
basis for evaluating whether to trust the message for delivery.
The responsible organization adds a digital signature to the message,
associating it with a domain name of that organization. Typically, signing will
be done by a service agent within the authority of the message originator's
Administrative Management Domain (ADMD). Signing might be performed by any of
the functional components, in that environment, including: Mail User Agent
(MUA), or Mail Submission Agent (MSA), Internet Boundary MTA. DKIM permits
signing to be performed by authorized third-parties.
After a message has been signed, any agent in the message transit path can
choose to validate the signature. Typically, validation will be done by an agent
in the ADMD of the message recipient. Again, this may be done by any functional
component within that environment. Notably this means that the signature can be
used by the recipient ADMD's filtering software, rather than requiring the
recipient end-user to make an assessment.
Receivers who successfully validate a signature can use information about
the signer as part of a program to limit spam, spoofing, phishing, or other
undesirable behavior, although the DKIM specification itself does not prescribe
any specific actions by the recipient.
Whether a DKIM signature improves deliverability or bypasses filters is
entirely at the discretion of the validating receivers. When a message has been
signed using DKIM, a receiver uses their knowledge about the signer to determine
the most appropriate treatment of the message. It is expected that messages from
a signer who has a good reputation will be subject to less scrutiny by the
receiver's filters.
Examples of what DKIM does not, by itself, do include:
* DKIM does not offer any assertions about the behaviors of the
identity doing the signing.
* DKIM does not prescribe any specific actions for receivers to take
upon successful (or unsuccessful) signature validation.
* DKIM does not provide protection after message delivery.
* DKIM does not protect against re-sending (replay of) a message that
already has a valid signature; therefore a transit intermediary or a recipient
can re-post the message in such a way that the signature would remain valid,
although the new recipient(s) would not have been specified by the originator.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html