Hi!
On 12/25/25 02:29, Richard Clayton wrote:
I have put in the changes and clarifications I emailed about earlier.
I'll go through the draft with a few remarks:
- 2.2 Forwarder:
- "services, In this document we use the concept of a Forwarder"
Might need to be a new sentence, i.e. s/,/./?
- "which is an MTA that receives a message and then either delivers
it into a destination mailbox or forwards it on to another system
in an automated, pre-determined, manner."
Why is final delivery into a destination mailbox still called
the operation of a Forwarder?
I'd have thought a Forwarder (which is obligated to add a new
signature) is only an MTA that changes the envelope or the
message itself (except for trace headers)? So I'd not call
a simple secondary MX a Forwarder, nor the MTA at the last
step before final delivery, unless it applies changes to the
message?
- 3.2 Tag=Value Lists
- I'll just note that "tag-name = ALPHA *ALNUMPUNC" with
the latter only allowing letters/numbers/underscore.
- 5 Message-Instance/change recipes
- "r="... "c:"
* This addresses the overlapping/non-monotonic issue well.
* How would a verifier handle invalid specifications
(line number 0 or > number of lines)? Same as z?
Or completely invalid signature (permfail)?
* Would we want a shortcut for single-line copies?
Currently they're like "c:42-42"
- "r_header="
* This addresses the inconsistency with the tag-name spec
in the previous version.
* How are header field names with "-" handled though?
An obvious solution would be substituting an underscore.
Another possibility would be allowing "-" in tag-name.
* "c:" addresses the overlapping/non-monotonic issue well.
Same question for invalid header field numbers though.
Would we want a short-cut for single-header-field copies?
- "mi-rh-tag-data = mi-rh-recipes / %07A"
* s/0/x/
* Perhaps lowercase the "a" for stylistic consistency
with "mi-r-tag-data"?
- 6 DKIM2-Signature
- "sig-t-tag = %x74 [FWS] "=" [FWS] dat"
Unless I miss something, I can't find a definition for "dat".
Perhaps we could inline 1*DIGIT instead?
- 10.1
- "then a new Message-Instance heade field"
This is a typo, s/heade/header/
- 11.3 fetching the public key
- "The Verifier retrieves the public key as described in
Section 10.3"
I don't see pertinent information in 10.3. Perhaps 4.5
could be a pertinent reference.
- "If the query for the public key returns multiple key
records, then the return PERMFAIL ("more than one key
returned" since this is not permitted by [DKIMKEYS]."
This misses the closing parenthesis.
In addition, the lastest DKIMKEYS draft just says
"the results are undefined" in this case. So this
is inconsistent and I'd suggest clarifying that in
DKIMKEYS.
- 11.6 Checking Message-Instance
- At the end of the first paragraph there's a comma instead
of a period.
Overall thanks for the revision. While I haven't yet had the
time to actually draft an implementation, I can't see any
significant blocker or ambiguity in the spec right now that would risk
incompatibility or even implementability, except possibly for the issue
of "-" in header field names, for change recipes.
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]
