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
