DomainKeys Identified Mail (DKIM) Service Overview
RFC 5585

1.  Introduction

 [...]

   DKIM allows an organization to take responsibility for a message, in
   a way that can be verified by a recipient.  The organization can be a
   direct handler of the message, such as the author's, the originating
   sending site's or an intermediary's along the transit path.  However
   it can also be and indirect handler, such as an independent service
   that is providing assistance to a direct handler.  DKIM defines a
   domain-level digital signature authentication framework for email
   through the use of public-key cryptography and using the domain name
   service as its key server technology.  [RFC4871] It permits

I think the reference is meant to be before the dot.

   verification of the signer of a message, as well as the integrity of
   its contents.  DKIM will also provide a mechanism that permits
   potential email signers to publish information about their email
   signing practices; this will permit email receivers to make
   additional assessments of unsigned messages.  DKIM's authentication
   of email identity can assist in the global control of "spam" and
   "phishing".

1.2.  Prior Work

 [...]

   There have been four previous IETF Internet Mail signature standards.
   Their goals have differed from those of DKIM.  The first two are only
   of historical interest.

Actually, I think the 2nd and the 3rd are of historical interest.
I.e. OpenPGP is still in use.

   o  Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
      first released in 1991.  A later version was standardized as
      OpenPGP.  [RFC2440] [RFC3156] [RFC4880]

   o  Privacy Enhanced Mail (PEM) was first published in 1987.
      [RFC0989]

   o  PEM eventually transformed into MIME Object Security Services
      (MOSS) in 1995.  [RFC1848] [RFC1991]

RFC 1991 is "PGP Message Exchange Formats". Is it the correct reference here?

   o  RSA Security independently developed Secure MIME (S/MIME) to
      transport a PKCS #7 data object.  It was standardized as [RFC3851]


2.2.  Enabling Trust Assessments

 [...]

   In order to formulate reputation information, an accurate, stable
   identifier is needed.  Otherwise, the information might not pertain
   to the identified organization's own actions.  When using an IP
   Address, accuracy is based on the belief that the underlying Internet
   infrastructure supplies an accurate address.  When using domain based
   reputation data, some other form of verification is needed, since it
   is not supplied independently by the infrastructure

Missing dot.

3.1.1.  Use Domain-level granularity for assurance

 [...]

   Contrast this with OpenPGP and S/MIME, which associate verification
   with individual authors, using their using full email addresses.

I think the second "using" should be deleted from this sentence.


3.1.4.  Distinguish the core authentication mechanism from its
        derivative uses

   An authenticated identity can be subject to a variety of assessment
   policies, either ad hoc or standardized.  DKIM separates basic
   authentication from assessment.  The only semantics inherent to a
   DKIM signature is that the signer is asserting some kind of
   responsibility for the message.  Any interpretation of this kind of
   responsibility is the job of services building on DKIM, but the
   details are beyond the scope of that core.  One such mechanism might
   assert a relationship between the SDID and the author, as specified
   in the From: header field's domain identity.[RFC5322] Another might

I think "[RFC5322]" should be before the dot.

   specify how to treat an unsigned message with that From: field
   domain.

I want to discuss this on the call:

> Mail that is
> not signed by DKIM is handled in the same way as it was before DKIM
> was defined.

Isn't this a contradiction to what the signing practices model does?
That is, if the signing practices claim that all mail is signed
by DKIM, and this particular message has no DKIM signature, aren't
we throwing the message away?

Also:

>    service as its key server technology.  [RFC4871] It permits

Odd use of the reference. Which sentence does the reference belong
to?