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.
>- 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.
>- 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)
> Same question for invalid header field numbers though.
> Would we want a short-cut for single-header-field copies?
again this seems unusual
> - "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
v6 was shipped last night (before I saw your comments on rt+ etc, so v7
will need to tackle that)
--
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
