Hi!
On 12/24/25 20:55, Richard Clayton wrote:
In message <[email protected]>, Hannah Stern
<[email protected]> writes
[...]
For Message-Instance, v= is limited to 2 digits. Perhaps for
consistency the EBNF for v= for the DKIM2-Signature (section 6) could
also changed to allow only 1*2DIGIT for consistency.
I've made it consistent, but 1*DIGIT rather than 2DIGIT (the latter
would mean you had to write v=01)
My suggestion was 1*2DIGIT to allow "1" but not "100". But I'm
perfectly fine with 1*DIGIT here. Implementations may want to apply
policy so abuse with excessive numbers of signatures/message instances
is mitigated.
There is talk about feedback requests elsewhere in the draft (e.g. 10.2)
but they are not specified for the DKIM2-Signature header.
For the moment we have punted on what feedback might be or where it
might be sent... there are existing schemes which provide feedback to
entities whose DKIM1 signatures are present in messages and where a
request has been made out-of-band.
It may be that the best thing to do here in DKIM2 is to provide a
destination email address, rather than a mere flag. Senders of feedback
would need to check for appropriate authorisation in the DNS -- as is
the practice for DMARC reports.
Ok, so I read from this that the feedback part is still WIP. Works for me.
In section 8: 'and any header fields whose name starts with "ARC" MUST
be ignored': Is this really "ARC*" or "ARC-*" or "ARC" *1("-" 1*ftext)?
(That is, would something like "Archived-At: <uri>" as per RFC5064 be
ignored?)
It should be "ARC-*" ... or we could list the headers from RFC8617 by
name (I think implementing ARC-* is easier, and I doubt people would
invent new ARC-headerfields any time soon).
I agree with ARC-* being better than an explicit enumeration.
9.2: 'one by one from the left hand side of the mf= domain and compared
with the rt= domain until there is an exact match or no labels remain'
Perhaps say explicitly "rt= domain of the previous signature"?
I've done a major rewrite of this to provide more clarity. In particular
there was confusion between the check that a Verifier must do when
receiving an email (check for an exact match of mf= rt= with the RFC5321
values) and the "chain of custody" scheme which ignores the local part
and strips off labels to try and get a match.
In my impression the language is clear enough.
Of course this doesn't allow a d=dkim-signer.some-org.example signature
for mf=<[email protected]>, but at least I'd think there's no
use-case for this anyway?
Another thing would be i=1 rt=<[email protected]>, while
the i=2 step might want to handle all subdomains the same like
mf=<[email protected]>. With the current spec the i=2 signer
would need to have its VERP mechanism at or below subdomain.
But I guess your motivation might have been to not introduce PSL style
alignment checking here (i.e. just requiring org-domains of mf/d/rt to
match respectively)?
10.2.2 step 4: This may lead to ambiguity. If a verifier choses to
iterate all keys, fine, if any fits, the signature validates (possible
partial DoS potential), but if the verifier doesn't, they can't know if
another key would actually work or if the signature is just invalid -
i.e. if "permfail" is the actually correct result. The associated draft
for DKIM2 DNS actually says the RRs MUST be unique. Perhaps make 10.2.2
step 4 consistent with that MUST (as suggested in step 5 in connection
with the DKIM2 DNS draft).
this step is copied verbatim from DKIM1, and the uniqueness requirement
is in RFC6376 as well (ie this is essentially an Errata against that
document). I will fix this to say that multiple keys should cause a
PERMFAIL.
I am working through further emails ... once I finish them I will issue
a new version of my document (hopefully today!)
Thanks.
I've already sent my remarks about the new version. Altogether I hope
it's a good step forward and closer to final.
Kind regards,
Hannah Stern.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig,
Dr. Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte
den Absender und vernichten Sie diese E-Mail. Anderen als dem
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this e-mail
in any way is prohibited. If you have received this e-mail in error,
please notify the sender and delete the e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
