I have finally found the time to work on my own implementation of MTA-STS.
As is often the case when actually implementing the specification, it
has turned up a number of issues of varying levels of severity, which
I'm listing in no particular order.
(1) Both RFC 7405 and RFC 5234 should be mentioned in the terminology section.
(2) The ABNF production field-delim appears in the definition of MTA-STS TXT
records and policies, with different values. I suggesting renaming the
former to sts-field-delim and the latter to sts-policy-field-delim,
to match the naming conventions for other productions.
(3) Section 3.1 contains this example:
"_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;""
Do we really need/want the outer quotes here? (Note that this is not
inlined in the text, where the quotes would be required.)
(4) Section 3.1 does not contain an explicit statement of what to do if the
selected TXT record is syntactically invalid. I think this is another case
where no policy should be assumed, so how about changing:
If the number of resulting records is not one, senders MUST assume the
recipient domain does not implement MTA-STS and skip the remaining
steps of policy discovery.
to:
If the number of resulting records is not one, or if the resulting
record is syntactically invalid, senders MUST assume the recipient
domain does not implement MTA-STS and skip the remaining
steps of policy discovery.
(5) The production:
sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", and control chars
refers to "control chars", which AFAIK is not a well-defined. RFC 5234
defines CTL for this purpose, so this should be changed to "and CTLs".
SP was removed from the list of prohibited stuff in this text in
-15. Why? Space is still excluded by the actual production, and itbs
not thought of as a control character.
I hope the intent is not to allow stuff like:
v=STSv1; id=20160831085700Z; foo=bar1 bar2;
And if it is, the ABNF needs further work because there is now
an ambiguity regarding trailing spaces and the *WSP thatbs allowed
at the end of a parameter value.
(6) Section 3.2:
Parsers MUST accept TXT records and policy files which are
syntactically valid (i.e. valid key/value pairs separated by semi-
colons for TXT records) and but containing additional key/value pairs
not specified in this document, in which case unknown fields SHALL be
ignored.
"records) and but containing" -> "records), possibly containing"
(7) Itbs probably too late to change this, but the "mx" key name is misleading
at best: It has nothing whatsoever to do with MX records. Rather, it
specifies a set of certificate identities SMTP servers for the domain
are constrained to use. Indeed, nothing prevents mta-sts from being used
with a domain whose server is identified by an A record - with no MX record
in sight.
And perhaps more to the point, therebs no alignment between MX record
values and these key values, but this key name makes the reader think
there is.
At a minimum there needs to be a note making it clear that the MX
host names are not involved in the policy check. It would probably
also be good to say that "MX host" is simply a host designated to
handle mail for a given domain, which may or may not be the result
of MX record processing.
(8) The policy resource ABNF mandates CRLF as the line terminator.
Unfortunately, this is just not HTTP reality - line terminators are
going to be whatever was used in the file being served out, and I
donbt think mandating that people use CRLFs in these files is realistic.
As such, the ABNF needs to be changed to at least allow LF, and probably
CR, terminators. Something like:
sts-policy-term = CR / LF / CRLF
And then use this throughout the rest of the ABNF instead of CRLF.
(9) The production:
sts-policy-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars, excluding "=", ";", SP, and
; control chars
has the same issue with "control chars" noted in (5). Additionally,
whatbs the point of excluding ";" and "="? Unlike TXT records, they
have no special meaning as delimiters here. If anything youbd want to
exclude ":", but I see no point in doing that either.
I also note that this production excludes SP (and unlike sts-ext-value,
the language about it has been retained). This seems overly restrictive to
me, so perhaps changing this to something like:
sts-policy-ext-value = %x21-7E [*(%x20-7E) %x21-7E]
; chars, excluding CTLs and no
; leading/trailing spaces
It also may be worth considering allowing UTF-8 in extension values.
Once the syntax rules are set theybre very difficult to change.
(10) The production for mx values:
sts-policy-mx-value = 1*(ALPHA / DIGIT / "_" / "-" / ".")
seems overly lax to me, especially since the DNS-ID fields being
compared against are constrained to valid domain syntax. Rather
than once again specifying productions for a domain, I would
suggest importing the definition of Domain from RFC 5321. This
then becomes:
sts-policy-mx-value = ["."] Domain
Domain = <see RFC 5321 4.1.2>
(11) For completeness, section 3.4 should contain a note about the handling
of domain literals. I suggest "this specification does not provide a
means of associating policies with address that employ domain literals"
or something stronger.
That's it for now. I should note that my implementation is incomplete, and
I expect I will have more comments once I've worked through the SMTP
client additions.
Ned
