On 2/20/18 10:13 PM, Valery Smyslov wrote: > Hi, > > this is the second working group last call (WGLC) for the "SMTP TLS Reporting" > (https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/). > The WGLC will be short and will last for one week till March the 1st. The > document has received substantial changes recently, so > please review > the latest version of the draft (-15) to make sure that these changes didn't > break WG consensus. > I read the draft again and did a review pretty much from scratch. Apologies in advance if some of my comments are redundant or have already been discussed.
Section 1 paragraph 4: "failures in routing" -- suggest also including DNS failures (spoofing, etc.) Section 1 paragraph 5: While this document derived from the MTA-STS effort, it seems like it's as much a companion for RFC 7672. Also wonder whether RFC 7672 should be a normative rather than informative reference. (same comment in section 2) Section 1.1 bullet 2: Perhaps also mention RFC 7672 since this is the SMTP policy piece of DANE policy Section 1.1 bullet 5: delivery -> relay Section 3.1: Redundant with Appendix A. Sections 3.1.2 and A.2 : I'm concerned that the trailing \ within quotes might be interpreted as a literal CRLF which would not be allowed by the ABNF. Section 4 bullet 2c: The MX host. Apparently separate reports are generated per MX host, which totally makes sense. But this seems like it could have been introduced better. Section 4 bullet 2d: An identifier for the policy (where applicable) -- This is mentioned nowhere else in the specification, so where would this identifier come from? Suggest it be deleted. 4.3.1 bullet 2: MX -> MX hostname 4.3.1 bullets 4 and 5: failure-reason -> failure-reason-code (also might be good to have a forward reference because these are the first mentions of it.) Section 4.4 below "policy-string": The examples are poorly delimited here; putting them in the middle of the bulleted list breaks the continuity of the list. Suggest a reference to examples located elsewhere. Section 5.3 paragraph 3: "MUST match the value found in the filename" but the value in the filename is only a recommendation (section 5.1). I continue to lean toward not depending on values in other than the message body (single source of truth). Section 5.3.1 last paragraph "...sending MTAs MUST NOT honor...": This bit of normative text is easy to miss, tacked onto an example. It also seems like it may be very hard to implement: you can't just drop a report into the mail stream (at least not in the absence of "REQUIRETLS NO"). Have the authors considered suggesting that the reports be sent to another domain instead (a domain that does not have MTA-STS policy)? -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
