Thanks Jim, this is useful! I expect it will lead to needing to do a pretty major rewrite, which I think is useful anyway.
Bron. On Sat, Nov 1, 2025, at 14:56, Jim Fenton wrote: > 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] > -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
