Stephen Farrell wrote:
And this note closes WGLC.
I believe we got the following comment:-
http://mipassoc.org/pipermail/ietf-dkim/2008q3/010672.html
Can the authors respond, to the list if discussion is needed or with
a new I-D for typos etc.
[ietf-dkim] Overview WGLC
Frank Ellermann nobody at xyzzy.claranet.de
Wed Aug 6 10:29:57 PDT 2008
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/
Actually should be /using the/ with 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/ [...]
We don't feel that this will provide any improvement in understandability.
| 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/ (?)
No, this would incorrectly change the meaning.
But there is a problem with "also can also", which should be "can also"
or "also can", but not "also can also".
| 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.
Actually we ought to distinguish "DKIM" as a signing mechanism, versus
other things DKIM enables, such as ADSP. Having the term DKIM refer to
more than signing is already causing confusion.
So we're going with /will also provide/also enables/
| 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.
No. Since the text here is merely serving as an exemplar, there is no
need to make it attempt to be exhaustive. But the text can erroneously
be read to imply that 4406-8 are historical, rather than techniques
of that ilk being historical and these being current instantiations of
that historical technique. So to be more explicit that these are
examplars of how that historical notion is currently being applied,
we'll change
assessments.[RFC4408], [RFC4406] and [RFC4407]
to this
assessments. For example, see [RFC4408], [RFC4406] and [RFC4407]
for current uses of the sending system's IP address.
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).
This is not correct. It also isn't relevant to the document. 4408 only
talks about "mail receivers", not distinguishing between intermediate
MTAs, final MTAs, or mail clients.
Ditto the PRA (4007) for 4406. Such practices are not "historical",
an issue already reported on the list twice, IIRC.
Also not relevant. See above.
| 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.
No. DKIM can be used for a variety of purposes. Deliverability has been
its primary focus.
The problem appears to be because of trying to use a very narrow
definition of "delivery" to mean "final delivery to the mailbox",
instead of the whole notion of delivery to the user that encompasses
accepting the message at the SMTP protocol level and subsequently
storing the message in the post office.
So there seems to be some minor ambiguity in use of the term.
One possible solution is to simply add the words "accept and" to the
sentence:
Whether to accept and deliver a newly-arrived message to the
indicated recipient?
| 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.
OK, better, except s/interpetations/interpetation/ and /are/is/, to make
the sentence a bit simpler.
Please upgrade the RFC 2822 references to 2822upd.
+1
| 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.
No. This document is pedagogy, not normative specification, and
explanatory and suggestive text about motivations and actions is
appropriate. But we'll change it to read
Administrators who have deployed DKIM verification have an
incentive to encourage senders (who might subsequently complain
that their email is not being delivered) to use DKIM.
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
+1
We'll give these comments a couple days to percolate and get responses,
then post a revision.
Tony Hansen, Dave Crocker & Phillip Hallam-Baker
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html