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 _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta