Errors are highlighted using [[error]] notation. This was based
upon the draft located at:
http://ietf.org/internet-drafts/draft-ietf-dkim-base-02.txt
There seems to be a type of corruption introduced and were not
noted in Jim's nits.
3.4.6 Example
Example 3: When processed using relaxed header canonicalization and
simple body [[canoniccalization]],
3.5 The DKIM-Signature header field
h= Signed header fields (plain-text, but see description;
REQUIRED). A colon-separated list of header field names that
identify the header fields presented to the signing algorithm.
The field MUST contain the complete list of header fields in
the
order presented to the signing algorithm. The field MAY
contain
names of header fields that do not exist when signed;
nonexistent
header fields do not contribute to the signature computation
(that is, they are treated as the null input, [[includiing]]
the
z= Copied header fields (plain-text, but see description; OPTIONAL,
default is null). A vertical-bar-separated list of selected
header field names and copies of header field values that
identify the header
fields present when
the message was signed. It is not required to include all
header
fields present at the time of signing. This field need not
contain the same header fields listed in the "h=" tag. Copied
header field values MUST immediately follow the header field
name
with a colon separator (no white space permitted). Header
field
values MUST be represented as Quoted-Printable [RFC2045] with
vertical bars, colons, semicolons, and white space encoded in
addition to the usual requirements.
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use [[onnly]].
3.6.1 Textual Representation
It is expected that many key servers will choose to present the
keys
in an otherwise unstructured text format (for example, an XML form
would not be considered to be unstructured text for this purpose).
The following definition [[MMUST]] be used for any DKIM key
represented in
an otherwise unstructured textual form.
...
y This domain is testing DKIM. Verifiers MUST NOT treat
messages from signers in testing mode differently from
unsigned email, even should the signature fail to verify.
Verifiers MAY wish to track testing [[modee]] results to
assist
the signer.
3.7 Computing the Message Hashes
In hash step 1, the signer or verifier MUST hash the message body,
canonicalized using the body canonicalization algorithm
specified in
the "c=" tag and truncated to the length specified in the "l=" tag.
That hash value is then converted to base64 form and inserted into
the "bh=" tag of the [[DKIMM-Signature:]] header field.
All tags and their values in the DKIM-Signature header field are
included in the cryptographic hash with the sole exception of the
value portion of the "b=" (signature) tag, which MUST be treated as
the null string. All tags MUST be included even if they might
not be
understood by the verifier. The header field MUST be presented to
the hash algorithm after the body of the message rather than
with the
rest of the header fields and MUST be canonicalized as specified in
[[the€]] "c=" (canonicalization) tag. The DKIM-Signature header
field
MUST NOT be included in its own h= tag.
5.1 Determine if the Email Should be Signed and by Whom
A signer MUST NOT sign an email if it is unwilling to be held
responsible for the message; in particular, the signer SHOULD
ensure
that the submitter has a bona fide relationship with the signer and
that the submitter has [[tthe]] right to use the address being
claimed.
5.4 Determine the header fields to Sign
The From header field MUST be signed (that is, included in the
h= tag
of the resulting DKIM-Signature header field); any header field
that
describes the role of the signer (for example, the Sender or
Resent-
From header field if the signature is on behalf of the
corresponding
address and that address is different from the From address) MUST
also be included. The signed header fields SHOULD also include the
[[Subjectt]] and Date header fields as well as all MIME header
fields.
6.3 Compute the Verification
INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the
body
at the indicated body length might pass on a malformed MIME
message if the signer used the "N-4" trick described in the
informative note in Section 5.5. Such verifiers may wish to
check
for this case and include a trailing "--CRLF" to avoid breaking
the MIME structure. A simple way to achieve this might be to
append "--CRLF" to any "multipart" message with a body
length; if
the MIME structure is already correctly formed, this will appear
in the postlude and will not be [[displayeed]] to the end user.
6.6 MUA Considerations
This sort of [[addrress]] inconsistency is expected for mailing
lists, but
might be otherwise used to mislead the verifier, for example if a
message supposedly from administration(_at_)your-bank(_dot_)com had a Sender
address of fraud(_at_)badguy(_dot_)com(_dot_)
8.2 [[Misappropriateed]] Private Key
8.3 Key Server Denial-of-Service Attacks
Since the key servers are distributed (potentially separate for
each
domain), the number of servers that would need to be attacked to
defeat this mechanism on an Internet-wide basis is very large.
Nevertheless, key servers for individual domains could be attacked,
impeding the verification of messages from that domain. This is
not
significantly different from the ability of an attacker to deny
service to the mail exchangers for a given domain, [[aalthough]] it
affects outgoing, not incoming, mail.
8.5 Replay Attacks
In this attack, a spammer sends a message to be spammed to an
accomplice, which results in the message being signed by the
originating MTA. The accomplice resends the message, including the
original signature, to a large number of recipients, possibly by
sending the message to many compromised machines that act as MTAs.
The messages, not having been modified by the accomplice, have
valid
signatures.
Partial solutions to this problem involve the use of reputation
services to convey the fact that the specific email address is
being
used for spam, and that messages from that signer are likely to be
spam. This requires a real-time detection [[mechanissm]] in
order to
react quickly enough. However, such measures might be prone to
abuse, if for example an attacker resent a large number of messages
received from a victim in order to make them appear to be a
spammer.
B.1 Simple Message Forwarding
In some cases the recipient may request forwarding of email
messages
from the original address [[tto]] another, through the use of a
Unix
.forward file or equivalent.
B.4 Mailing Lists
There is a wide range of behavior in forwarders and mailing lists
(collectively called "forwarders" below), ranging from those which
make no modification to the message itself (other than to add a
Received header field and change the envelope information) to those
which may add header fields, change the Subject header field, add
content to the body (typically at the end), or reformat the body in
some manner.
Forwarders which do [[noot]] modify the body or signed header
fields of a
message with a valid signature may re-sign the message as described
below.
Appendix C. Creating a public key (INFORMATIVE)
This public-key data (without the BEGIN and END tags) is placed in
the DNS. With the signature, canonical email contents and
[[puublic]]
key, a verifying system can test the validity of the signature.
The
openssl invocation to verify a signature looks like this: