Hi,
Below is my early "AD review" of the document. I think it is in pretty
good shape and is ready for WG Last Call (I am Ok with the question of
JSON versa something else be settled during or after WGLC.)
1) In 1.1:
o Policy Domain: The domain for which an MTA-STS Policy is defined.
This is the next-hop domain; when sending mail to
"[email protected]" this would ordinarly be "example.com", but
this may be overriden by explicit routing rules (as described in
"Policy Selection for Smart Hosts").
Nit: This needs an internal section reference.
I think there was another place in the document when an internal section
number is not mentioned.
2) In 3.1:
sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1"
%x53 %x76 %x31
Do you intend for this to be matched case-sensitively?
What you wrote above is that "v" is case-insensitive, but "STSv1" is.
3) Section 3.2 says that unrecognized fields are to be ignored, so you
need to update ABNF in 3.1 to make it clear.
Current ABNF:
sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B]
sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1"
%x53 %x76 %x31
sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)
I suggest something like the following (this implies that position of
the first 2 fields is fixed, extensions at the end. If you prefer that
any fields are in any order (other than the version), I can update the
ABNF):
sts-text-record = sts-version *WSP field-delim *WSP sts-id
[field-delim [sts-extensions]]
field-delim = %x3B
sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1"
%x53 %x76 %x31
sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)
sts-extensions = sts-extension *(field-delim sts-extension)
[field-delim]
; Extension fields at the end in any order
sts-extension = sts-ext-name *WSP "=" *WSP sts-ext-value
sts-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" /
".")
sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; like esmtp-value from RFC 5321, but doesn't
allow ";".
; So basically any CHAR excluding "=", ";", SP,
and control
; characters.
4) In 3.2: Should "SHOULD ignore unrecognized fields" be a MUST? I.e.,
why would it not be Ok to ignore unrecognized fields?
5) In 3.3: RFC 6125 use needs more details, because you need to specify
answers to every question in section 3 of RFC 6125.
In particular you should say that when checking certificates, you only
use DNS-ID and CN-ID (SRV-ID and URI-ID are not used) and that you allow
wildcards in them.
6) Last para on page 7: this is also true in RFC 6125.
7) In 5.1, last para: I think you mean that if there are too many
failures to deliver when using MTA-STS, regular SMTP rules for
generating a bounce apply? I think this needs rewording to say that.
8) If you want to allow for extensibility, you probably need an IANA
registry of fields allowed, so that developers can find them easily. I
can help with some text.
9) On page 13: I think pseudocode should make it clear that you retrieve
DNS-ID SAN.
Best Regards,
Alexey
P.S. I might have a couple of extra items, but I need to double check a
few things first.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
