Informal comments only here. I know a merger with Dave's draft is in progress, so some of these may not apply by the time you're done.
Section 1.1: It feels a little presumptuous to assume any DKIM receiver has also built out a reputation system, or has access to one. I guess it might depend on what you consider a reputation system though; are there DNSxLs for DKIM domains that are open to the public? I don't think SpamAssassin carries with it a set of domains that should be dropped if they carry valid DKIM signatures. Either way, I think the generalization is peculiar. At a minimum, say "some systems develop reputations" etc. I think I concur with the suggestion that wa should drop discussion of ARC. This WG, or the DMARC WG, can develop an update to ARC based on the outcome here if the community chooses to do so, but I don't think it should be part of this WG's premise. Section 1.2: The opening sentence that emphasizes non-use of RFC 2119, amusingly, forces you to include a reference to RFC 2119. I suggest instead: "This document is not normative in any way." "administratively" should be "administrative functions" or similar. ("users" and "services" are nouns, so this should be too.)S The "List-*" header fields are defined in RFC 4021. In "trace and operational headers", "headers" should be "header fields". Are we actually defining new Mail Handling Services here, or rather declaring special cases of Originators and Relays? Do they become Authors again after they've handled/filtered a message? Are we sure SPF and DMARC should be in scope for this work? SPF feels irrelevant, and DMARC feels like a layer violation. If we want to do so, we could refer the reader to the RFCs defining those protocols just to make them aware of the bits of the ecosystem, but then I would leave them out of the rest of the document. Section 2: "headers" should be "header fields" "customized by" the ultimate recipient? or should that be "for"? Involvement of SPF here doesn't seem to be needed either. We only need to tall the DKIM story. I think the notion of folders also exceeds DKIM's scope. That's a handling choice post-DKIM. It's enough to highlight that a false positive is procured by the attacker, to the attacker's benefit. Section 3: Does including SPF in this part of the discussion contribute to the problem statement or muddy it? This is about DKIM, not about spam handling in general. Section 3.1's "DKIM" bullet talks about signature survival, while Section 3.2's "DKIM" bullet talks about who does the signing. This seems dissonant, or at least makes them hard to compare and contrast since they talk about different things. Section 4: Caching known signatures, a con: adds a potentially expensive database component to the receiving service, and will require tinkering to figure out what cache duration is appropriate to catch replays while not also catching legitimate mail. The "sign for the next hop" proposal could use a language tweak of some kind. I can't quite put my finger on it. If it's "sign for the next hop" at a host level, I have to know that host; today, I just sign and toss it in the queue, and my MTA figures out which MX is going to take it, but if I have to know which MX that is, I can't sign until connection time; milter-based filters at least don't work that way because the integration point doesn't allow it. If it's actually "sign for the next ADMD", that problem goes away, but the definition of "ADMD" gets a bit muddy because now you have to include in that definition any MX that might be providing transparent store-and-forward. Section 5 you won't need. Section 6 can simply say there are no security considerations for a problem statement document, though you anticipate some interesting ones in documents to follow. :-) Lastly, you can drop the "yet" from Section 7. :-) -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim