[ietf-dkim] Proposal for specifying syntax
andsemantics formultiple signatures
hsantos at santronics.com
Mon Apr 3 02:49:47 PDT 2006
All would like to see is a robust design against failure.
You are not offering this and this sincerely concerns me as I think this
puts the new domain responsibility and reputation at risk and the verifier
will sense the biggest burdens.
I am not talking about "spam filtering" "content analysis" but simply
You are asking domains to take responsibility and that its now their
reputation at stake. Yet you are not offering domains any assurance that it
will be safe, nor that it will reliable work or how verifiers should handle
the conflicts and failures.
Hector Santos, Santronics Software, Inc.
----- Original Message -----
From: "Dave Crocker" <dhc at dcrocker.net>
To: "Barry Leiba" <leiba at watson.ibm.com>
Cc: "Eric Allman" <eric at sendmail.com>; <ietf-dkim at mipassoc.org>
Sent: Monday, April 03, 2006 3:37 AM
Subject: Re: [ietf-dkim] Proposal for specifying syntax andsemantics
> >> 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
> from the drums.
> - - - -
> The overview is going to have this sort of text, though it would not hurt
> 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
> for a DKIM signature is declaring that they are accountable for the
> This means that their reputation is at stake. That is, their reputation is
> 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,
> be done by a service agent within the authority of the message
> Administrative Management Domain (ADMD). Signing might be performed by any
> 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
> choose to validate the signature. Typically, validation will be done by an
> in the ADMD of the message recipient. Again, this may be done by any
> component within that environment. Notably this means that the signature
> 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
> the signer as part of a program to limit spam, spoofing, phishing, or
> undesirable behavior, although the DKIM specification itself does not
> any specific actions by the recipient.
> Whether a DKIM signature improves deliverability or bypasses filters
> entirely at the discretion of the validating receivers. When a message has
> signed using DKIM, a receiver uses their knowledge about the signer to
> the most appropriate treatment of the message. It is expected that
> 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
> 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
> already has a valid signature; therefore a transit intermediary or a
> can re-post the message in such a way that the signature would remain
> although the new recipient(s) would not have been specified by the
> Dave Crocker
> Brandenburg InternetWorking
More information about the ietf-dkim