[ietf-dkim] Proposal for specifying syntax and semantics formultiple signatures

[Dave Crocker]

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>