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. 


         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

    "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.


Uta mailing list

Reply via email to