Stephen Farrell wrote:
http://tools.ietf.org/wg/dkim/draft-ietf-dkim-overview/
| DKIM defines a domain-level digital signature authentication
| framework for email, using public-key cryptography, using
| the domain name service as its key server technology [RFC4871]
s/, using the/and the/
| DKIM allows an organization to take responsibility for a message, in
| a way that can be validated by a recipient. The organization can be
[...] s/The organization/This organization/ [...]
| handling the message directly, such as the author's, the originating
| sending site or an intermediary. It also can also be created by an
| independent service that is providing assistance to a handler.
s/It can also be created by an/It can also be an/ (?)
| 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
s/will also provide/also provides/ + s/will permit/offers/ (?)
If the "overview" by design ignores ADSP the future form will do,
but I think that's not the idea.
| Historically, the IP Address of the system that directly sent the
| message -- that is, the previous email "hop" -- has been treated as
| an identity to use for making assessments.[RFC4408], [RFC4406] and
| [RFC4407]
Ditto 2821bis looking at "hello" identities, DNSBLs blocking "bad"
IPs, etc. The historical part in this business are "reverse paths"
noting all hops, everything else is state of the art.
An envelope sender address (4408) is not supposed to be checked at
random hops, it is used between the border MTAs (the hop from the
last MTA on the sender side to the first MTA on the receiver side).
Ditto the PRA (4007) for 4406. Such practices are not "historical",
an issue already reported on the list twice, IIRC.
| Email receiving services are faced with a basic decision: Whether
| to deliver a newly-arrived message to the indicated recipient?
Before (or together with) that question they have to decide if they
wish to *accept* the mail, and if they accepted it they also have
the responsibility to deliver it or report non-delivery (with some
known exceptions like "hostile content" and "forward to 3rd party")
So there are typically two basic decisions. The draft should say
this, although its focus is clearly not on accept / reject issues.
| The only semantics inherent to a DKIM signature is that the signer
| is asserting (some) responsibility for the message. Hence, a DKIM
| signature only means that the signer is asserting (some)
| responsibility for the message, and nothing more. Other services
| can build upon this core association, but their details are beyond
| the scope of that core.
Saying it twice IMO does not help. How about something like this:
+ The only semantics inherent to a DKIM signature is that the signer
+ is asserting some kind of responsibility for the message. Any
+ interpretations of this kind of responsibility are the job of
+ services building on DKIM, but their details are beyond the scope
+ of that core.
Please upgrade the RFC 2822 references to 2822upd.
| Administrators who have deployed DKIM verification have an
| incentive to evangelize the use of DKIM signatures to senders
| who might subsequently complain that their email is not being
| delivered.
Please strike that "evangelization" blurb, IMO this belongs on
dkim.org and similar places.
In section 1.3 - the forward pointer to appendix A with various
terms - please add "mediator", because that term is used in 5.6
before the explanation in appendix A.1
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html