Suggested new language in [brackets], for various sections:
1.1. DKIM's Scope
DKIM signatures can be created by a direct handler of a message,
either as its author or as an intermediary. It can also be created
by an independent service that is providing assistance to a handler
of the message. Whoever does the signing chooses the domain name to
be used as the basis for later assessments. Hence, the reputation
associated with that domain name [may be] an additional basis for
evaluating whether to trust the message for delivery. The owner of
the domain name being used for a DKIM signature is declaring that
they accept responsibility for the message and may thus be held
accountable for it.
[ . . . ]
o Does not protect against re-sending (replay of) a message that
already has a verified signature; therefore a transit intermediary
or a recipient can re-post the message [again] in such a way that
the
signature would remain verifiable, although the new recipient(s)
[may be different from those which were originally] specified by
the author.
1.2. Prior Work
Historically, email delivery assessment decisions have been based on
an identity [derived from] the IP Address of the system that directly
sent
the message (that is, the previous email "hop"), [RFC4408] or on the
message content (e.g. [RFC4406] and [RFC4407]). The IP Address is
obtained via underlying Internet information mechanisms and is
therefore trusted to be accurate. Besides having some known security
weaknesses, the use of addresses presents a number of functional and
operational problems. Consequently there is a widespread desire to
use an identifier that has better correspondence to organizational
boundaries. Domain names are viewed as often satisfying this need.
[ . . . ]
3.2.3. Permit incremental adoption for incremental benefit
[ . . . ]
Although it is envisioned that this mechanism will call upon
independent services [(either within the receiving network, or a
third party)] to aid in the assessment of DKIM results, they
are not essential in order to obtain initial benefit. For example
DKIM allows (possibly large) pair-wise sets of email providers and
spam filtering companies to distinguish mail that is associated with
a known organization from mail that might deceptively purport to have
the affiliation. This in turn allows the development of "whitelist"
schemes whereby authenticated mail from a known source with good
reputation is allowed to bypass some anti-abuse filters.
[ . . . ]
Management of email [delivery] problems currently represents a
significant pain point for email administrators at every point on the
mail transit path. Administrators who have deployed DKIM
verification have an incentive to evangelize the use of DKIM
signatures to senders who may subsequently complain that [they
believe] their email is not being delivered [as desired].
[ . . . ]
4.1. The Basic Signing Service
[ . . . ]
DKIM permits restricting the use of a signature key (by using s=) to
signing messages for particular types of services, such as only for
[a single source of] email. This is intended to be helpful when
delegating signing
authority, such as to a particular department or to a third-party
outsourcing service.
[ . . . ]
4.2. Characteristics of a DKIM signature
A DKIM signature [applies to] the message body and selected header
fields.
The signer computes a hash of the selected header fields and another
hash of the body. The signer then uses a private key to
cryptographically encode this information, along with other signing
parameters. Signature information is placed into the DKIM-Signature
header field, a new [RFC2822] header field of the message.
[ . . . ]
4.3. The Selector construct
[ . . . ]
Signers often need to support multiple assessments about their
organization, such as to distinguish one type of message from
another, or one portion of the organization from another. To permit
assessments that are independent, one method is for an organization
to use different sub-domains in the "d=" parameter, such as
"transaction.example.com" versus "newsletter.example.com", or
"productA.example.com" versus "productB.example.com". This is (or
can be) entirely separate from the From: domain.
5. Service Architecture
[ . . . ]
The MSA The MSA signs the message, using private information from
the Key Store [(defined below}].
[ . . . ]
5.1. Administration and Maintenance
Reputation/Accreditation If a message contains a valid signature,
then the verifier can evaluate the associated domain name's
reputation [in order to determine appropriate delivery or display
options for that message]. Quality-assessment information, which
is associated
with a domain name, comes in many forms and from many sources.
DKIM does not define assessment services. It's relevance to them
is to provide a validated domain name, upon which assessments can
be made.
[ . . . ]
5.4. Unverified or Unsigned Mail
Note that a failed signature [will in most cases cause] the message
to be treated in the
same manner as one that is unsigned. Messages lacking a valid author
signature (a signature associated with the author of the message as
opposed to a signature associated with an intermediary) can prompt a
query for any published "signing practices" information, as an aid in
determining whether the author information has been used without
authorization.
--
J.D. Falk
Receiver Products
Return Path
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html