Hi!
I'll take a more thorough look later.
On 1/21/26 18:12, Richard Clayton wrote:
In message <[email protected]>, Hannah Stern
<[email protected]> writes
[lots of extremely helpful proof-reading .. if I don't mention a comment
I just fixed it]
- "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?
a Forwarder either forwards or delivers -- it's the same machine
whichever it does. I've recast this for clarity.
The new wording makes it much more clear at least in my eyes.
- 3.2 Tag=Value Lists
- I'll just note that "tag-name = ALPHA *ALNUMPUNC" with
the latter only allowing letters/numbers/underscore.
as you note later ... this means we cannot have r.header-field because
"-" is not allowed. Rather than having a different ABNF for Tag=Value
lists than elsewhere I have changed this to rh=header-field,... ie: the
first item in the list is the header field name.
At Bron's suggestion the syntax now has vertical bars between the header
field names and recipes are b. c. (we could perhaps use something that
is not in base64, but this seems clear enough.
I have considered r=header-name,... and r=*,... for the body (ie * means
"not a header field but the body" but it seems clearer (and will mean
the code can tackle each topic separately) if we use rb= for the body
and rh=field-name for header fields.
I see this ABNF now for header recipes:
mi-rh-tag = %x72 %x68 [FWS] "=" [FWS] mi-rh-headers
mi-rh-headers = mi-rh-header * ([FWS] %x7c [FWS] mi-rh-header)
mi-rh-header = header-field-name [FWS] ":" [FWS] mi-rh-header-data
mi-rh-item-data = / ; the no recipes case
mi-rh-recipes / %7a
mi-rh-recipes = mi-rh-recipe * ([FWS] "," [FWS] mi-rh-recipe)
mi-rh-recipe = %x63 "." 1*DIGIT "-" 1*DIGIT /
%x62 "." base64string
One clerical error is the reference (in mi-rh-header) to
mi-rh-header-data which doesn't exist but probably means
mi-rh-item-data.
If I understand this correctly, the "no recipes case" is inteded
for "originally there was no Foo header field, but I've inserted
some"? In contrast to "z" (there were previous Foo header fields
but for some reason I can't/won't tell what they were).
I think this will work.
In RFC 5322, there's this:
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
So theoretically, a field name could include a pipe character.
But that's no problem, as the pipe character as part of the field
name would be in the context that parses header-field-name
(start of mi-rh-headers or after the separating pipe).
The separating pipe can occur only after the ":" of mi-rh-header
has been seen. That's not hard to distinguish.
The only valid ftext character we can't represent now is ';'
(semicolon) because of the Tag=Value list syntax. I don't care.
If we wanted to be complete in this respect, we could specify in
section 8 to ignore any header fields whose key contains ';'.
- 5 Message-Instance/change recipes
- "r="... "c:"
* Would we want a shortcut for single-line copies?
Currently they're like "c:42-42"
how common would this be ? The syntax now requires both numbers
everywhere (since people generating recipes will know what the counts
are)
It would just be an abbreviation. In bodies I think it's
less likely than with headers:
Same question for invalid header field numbers though.
Would we want a short-cut for single-header-field copies?
again this seems unusual
Previously there was one Foo header, the modifier inserted
another one. rh=Foo:c.1-1 or rh=Foo:c.2-2 would result from this.
I agree it'll be not so frequent and it would be only about
saving a mere 2 octets (nearly never more). So for my sake
it would be ok to decide to prefer an uniform syntax without
special cases, i.e. leave it as it is in the currect draft v6.
- "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.
yes, some changes to DKIMKEYS are outstanding, in particular we aim to
deprecate unused features ... the specification draft has jumped the gun
by assuming those changes have been made
I'd be glad to have a clear "multiple TXT records are a PERMFAIL"
rule (as specified in the main spec draft, v6 now).
v6 was shipped last night (before I saw your comments on rt+ etc, so v7
will need to tackle that)
As said, I'll have a more complete look at the new version soon.
I'm quite happy with the parts I've already looked at.
Kind regards,
Hannah.
--
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]
