As near as I can tell, every single one of these came up at the IETF
end --- I checked the version I sent them and the doubled characters
do not exist.
eric
--On May 31, 2006 2:22:23 PM -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:
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:
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html