Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication
framework for email using public-key cryptography and key server
technology to permit verification of the source and contents of
messages by either Mail Transfer Agents (MTAs) or Mail User Agents
(MUAs). The ultimate goal of this framework is to permit a signing
domain to assert responsibility for a message, thus proving and
protecting message sender identity and the integrity of the
messages they convey while retaining the functionality of Internet
email as it is known today.
(dhc) Since DKIM signing is presumed to be done by any of the
entities that do sending, the word probably is fine, here.
However, I suggest emphasizing that there may be many senders for a
message, so:
"protecting message sender identity" -> "protecting the identity of
one of the senders of the message"
It doesn't really have to be even one of the senders (although
presumably it is). How about we just change "sender" -> "signer"?
3.4.5 Body Length Limits
...
INFORMATIVE IMPLEMENTATION NOTE: Body length limits could be
useful in increasing signature robustness when sending to a
mailing list that both appends to content sent to it and does not
sign its messages. However, using such limits enables an attack in
which a sender with malicious intent modifies a message to include
content that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in the
end recipient's eyes and to defeat duplicate message detection
algorithms. To avoid this attack, signers should be wary of using
this tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length, perhaps
based on other criteria.
(dhc) I think the use of "sender" here refers to the signer, but it
might refer to the originator. I'm not sure. Who is really the
source of the threat?
I agree with Paul here; changing it to "attacker" is fine,
particularly since it is non-normative. I think we can also drop
"with malicious intent", since that's implied by the word "attacker".
h=
...
INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can prevent insertion of those header
fields before verification. However, since a sender cannot
possibly know what header fields might be created in the future,
and that some MUAs might present header fields that are embedded
inside a message (e.g., as a message/rfc822 content type), the
security of this solution is not total.
(dhc) sender -> signer
Done.
s=
...
This tag is intended to permit senders to constrain the use of
delegated keys, e.g., where a company is willing to delegate the
right to send mail in their name to an outsourcer, but not to send
IM or make VoIP calls. (This of course presumes that these keys
are used in other services in the future.)
(dhc) senders -> signers
Done.
5.1 Determine if the Email Should be Signed and by Whom
...
A SUBMISSION server MAY sign if the sender is authenticated by
some secure means, e.g., SMTP AUTH. Within a trusted enclave the
signing address MAY be derived from the header field according to
local signer policy. Within a trusted enclave an MTA MAY do the
signing.
(dhc) signer -> submitter
I assume you mean "sender" -> "submitter" here.
6.2 Communicate Verification Results
...
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to
search for results header fields to visibly mark authenticated
mail for end users should verify that such header field was added
by the appropriate verifying domain and that the verified identity
matches the sender identity that will be displayed by the MUA. In
particular, MUA filters should not be influenced by bogus results
header fields added by attackers.
(dhc) given that this section specifies MUA behavior, there are
bigger issues than wording choice. however, to deal with that
smaller point:
sender -> author
Done.
B.6 Third-party Message Transmission
Third-party message transmission refers to the authorized sending
of mail by
an Internet application on behalf of a user. For example, a website
providing news may allow the reader to forward a copy of the
message to a friend; this is typically done using the reader's
email address. This is sometimes referred to as the "Evite
problem", named after the website of the same name that allows a
user to send invitations to friends.
One way this can be handled is to continue to put the reader's
email address
in the From field of the message, but put an address owned by the
site into the Sender field, and sign the message on behalf of the
Sender. A verifying MTA should accept this and rewrite the From
field to indicate the address that was verified, i.e., From: John
Doe via news(_at_)news-site(_dot_)com <jdoe(_at_)example(_dot_)com>.
(dhc) I am not sure which entity the term "the Sender" is referring
to, here. But again, this is wandering in the space of the MUA, I
think.
Rewritten to:
One way this can be handled is to continue to put the
reader's email address in the From header field of the
message, but put an address owned by the site into the Sender
header field, and sign the message on behalf of that address.
A verifying MTA should accept this and rewrite the From
header field to indicate the address that was verified, i.e.,
From: John Doe via news(_at_)news-site(_dot_)com
<jdoe(_at_)example(_dot_)com>.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html