Dave,
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
protocol consistency.
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.
http://www.santronics.com
----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
Cc: "Eric Allman" <eric(_at_)sendmail(_dot_)com>;
<ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Monday, April 03, 2006 3:37 AM
Subject: Re: [ietf-dkim] Proposal for specifying syntax andsemantics
formultiple signatures
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