A few comments on my action items:
1308 (language recommending use of t=s): In the description of the
t=s flag, I've added "Use of this flag is RECOMMENDED unless
subdomaining is required."
DNS discussion: There's a note from Olafur suggesting that the
document add "do not use wildcards." I'm not completely clear where
this belongs: it can't be for _domainkey.*.example.com, so perhaps
this means for *._domainkey.example.com? Or is this about policy?
1316 #1 (define plain-text): It turns out it's already defined for
tag=value lists (which is what matters for us) in the ABNF for
VALCHAR. I've added "INFORMATIVE IMPLEMENTATION NOTE: Although the
"plain text" defined below only includes 7-bit characters, an
implementation that wished to anticipate future standards would be
advised to not preclude the use of UTF8-encoded text in tag=value
lists."
1316 #22 (guidance on limiting trace headers): Section 5.4 now
includes the text "Signers choosing to sign an existing header field
that occurs more than once in the message (such as Received) MUST
sign the physically last instance of that header field in the header
block. Signers wishing to sign multiple instances of such a header
field MUST include the header field name multiple times in the h= tag
of the DKIM-Signature header field, and MUST sign such header fields
in order from the bottom of the header field block to the top. The
signer MAY include more instances of a header field name in h= than
there are actual corresponding header fields to indicate that
additional header fields of that name SHOULD NOT be added."
1317 #33 (use cases for 3rd party MTAs --- the notes have this listed
as #30-#34, but I believe that is incorrect): I have added Appendix
B.7 reading (sorry for the XML):
<section
title="SMTP Servers for Roaming Users"
><t
>Roaming users may find themselves in circumstances where it
is convenient or necessary to use an SMTP server other than
their home server; examples are IETF conferences and many
hotels. In such circumstances the signature, if any, will be
added by a party other than the user's home system.</t
><t
>Ideally roaming users would connect back to their home
server using either a VPN or a SUBMISSION server running with
SMTP AUTHentication on port 587. If the signing can be
performed on the roaming user's laptop then they can sign
before submission, although the risk of further modification
may be high. If neither of these are possible, these roaming
users will not be able to send mail signed using their own
domain key.</t
></section
>
Not explicitly listed in the notes:
Section 5.4 (Determine the header fields to sign) now has the
following language (again, sorry for the XML):
The From header field MUST be signed (that is, included in
the h= tag of the resulting DKIM-Signature header field); any
header field defined as an Originator Field in <xref
target="RFC2822"
></xref
> section 3.6.2, Resent-From, and Resent-Sender MUST also be
included. The signed header fields SHOULD also include the
Subject and Date header fields as well as all MIME header
fields. Signers SHOULD NOT sign an existing header field
likely to be legitimately modified or removed in transit. In
particular, <xref
target="RFC2821"
></xref
> explicitly permits modification or removal of the
"Return-Path" header field in transit. Signers MAY include
any other header fields present at the time of signing at the
discretion of the signer.<list
style="empty"
><t
>INFORMATIVE OPERATIONS NOTE: The choice of which header
fields to sign is non-obvious. One strategy is to sign all
existing, non-repeatable header fields. An alternative
strategy is to sign only header fields that are likely to be
displayed to or otherwise be likely to affect the processing
of the message at the receiver. A third strategy is to sign
only "well known" headers. Note that verifiers may treat
unsigned header fields with extreme skepticism, including
refusing to display them to the end user.</t
></list
>
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html