I read through the Motivations draft, and have quite a few comments.
Title: The title makes it sound like a DKIM2 specification, rather than
a discussion of the motivations for DKIM2.
Intended status: Should be Informational.
Abstract: “replacing the existing email security mechanisms”: TLS,
S/MIME, etc. are email security mechanisms, and are not replaced by
DKIM2. This needs to be more tightly scoped.
1. Background paragraph 1: The correct historical context for the
beginning of DKIM is RFC 4871, “DomainKeys Identified Mail (DKIM)
Signatures”. RFC 6376 (cited) was one of the updates mentioned in the
following paragraph.
Paragraph 3 and 4: “these problems”. What problems are these? No
problems have yet been described.
Paragraph 7 (item 2) should mention something about not interfering with
the existing privacy properties of email (e.g., privacy of bcc
addresses)
Paragraph 8 (item 3): It isn’t clear what problem this is solving
(this comes later)
Throughout the document: Please use accepted terminology for header
fields vs. headers. Email messages have exactly one header composed of a
number of header fields.
Sections 2 and 3: These should be interchanged, so that the document
describes the problems it is solving before describing what it proposes
to do about them.
Section 2.1 paragraph 3: “track which addresses can forward to it”.
This sounds like a signinficant new burden. How does this work for
non-DKIM2 aware recipient systems?
Section 2.1 paragraph 4: “forward-path addresses are not not all
present”. I had the impression from elsewhere that there would be
exactly one recipient address per signature, and one SMTP transaction
per recipient address. Is that incorrect?
Section 2.3: Backscatter has not yet been defined (probably fixed if Sec
2 and 3 are interchanged). This seems to assume that reverse-path DSN
has been implemented everywhere. I expect there will be a very long tail
for implementation of this.
Please explain how reverse path backscatter works when the MX record in
the reverse direction directs mail elsewhere (to an incoming rather than
outgoing MTA, for example). Is this a special case where only A/AAAA
record lookup is done on the signing hostname? Would all outgoing MTAs
be required to accept incoming SMTP connections for incoming DSNs? How
does the system needing to send a DSM know whether to send it over the
reverse path or in the traditional way? (I realize that I’m probably
getting into details of the actual DKIM2 specification at this point.)
Section 2.3 paragraph 3: “any hop can strip off”: Seems like this
ought to be a requirement.
Section 2.4 paragraph 3: Paragraph 4 should probably note that it will
have to deal with different encodings (e.g., Base64) and multiple MIME
parts.
Section 2.5 doesn’t seem to correspond to a problem described anywhere
in the document.
Section 4.1 seems to be saying that nobody is adopting elliptic curves,
so we should make it mandatory. This neeeds further justification.
Algorithm agility is important, particularly to accommodate PQ
algorithms, but this seems like an odd requirement.
Section 4.2 paragraph 2 needs to more precisely describe what a single
recipient is. Is a role account (e.g., [email protected]) a single
recipient if it redistributes to more than one actual mailbox?
Section 4.3 paragraph 3 sounds a lot like the Expires: header field.
Hope this is useful.
-Jim
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
