Ayke, At one point, these two were a single draft, but there's more utility possible with having TLSRPT separate. To answer your scenarios below:
1) The site may not be able to process reports, or may not want the information, but they could still want to move toward a policy of ensuring mode=enforce or have a TLSA published. The MTA-STS draft mentions that if the site also publishes TLSRPT, they could receive reports. 2) The site could still have TLSA records or general TLS failures. While the sending site would not validate the MTA-STS policy, there could be other items causing reports show failures. 3) I believe 2 and 3 are similar situations. Does that answer some of your questions? -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: Ayke van Laethem [mailto:[email protected]] Sent: Saturday, March 24, 2018 5:56 PM To: Brotman, Alexander <[email protected]> Cc: [email protected] Subject: Re: [Uta] Updated TLSRPT (WGLC Comments) Hi all, Something that's been confusing to me is: if and how does the SMTP-TLSRPT specification depend on the MTA-STS specification? The "mode" field of the policy controls whether any report should be generated (if there is a TLSRPT policy too), but the SMTP-TLSRPT specification itself does not mention this dependency at all. In fact, I wonder why the MTA-STS policy would affect report sending anyway. Consider these cases: 1. There is a policy with mode=testing and no TLSRPT policy - obviously no report is generated, because there is no address to send it to 2. There is a policy with mode=none and a TLSRPT policy - according to the MTA-STS spec, no report should be sent, but the TLSRPT spec is silent on this 3. There is no STS policy at all, but there is a TLSRPT policy - I'm guessing reports have to be sent, even though there is no STS policy that says so, in case DANE is used It would make most sense to me if report sending only depends on the presence of the TLSRPT policy (the TXT record) and not at all on the active MTA-STS policy mode. There may be a special case to not send reports if there is a MTA-STS policy mode=none *and* DANE is not in use (how do you determine exactly DANE is not in use?), but IMHO this should be documented in the TLSRPT spec. Ayke 2018-03-05 14:09 GMT+01:00 Brotman, Alexander <[email protected]>: > Updated draft in a short while. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > > > -----Original Message----- > From: Uta [mailto:[email protected]] On Behalf Of Viktor Dukhovni > Sent: Sunday, March 04, 2018 3:08 PM > To: [email protected] > Subject: Re: [Uta] Updated TLSRPT (WGLC Comments) > > > >> On Mar 4, 2018, at 1:47 PM, Brotman, Alexander >> <[email protected]> wrote: >> >> Hello folks, >> >> We used the feedback from folks during the WGLC and have submitted a new >> version. This is mostly editorial changes or minor inconsistencies. We did >> also remove any relation between the TLS-Report-Submitter and the filename. >> If you have any comments, please let us know. Thank you. >> >> https://www.ietf.org/id/draft-ietf-uta-smtp-tlsrpt-16.txt > > Almost there, but a couple of editorial nits: > > 4.4 > > o "policy-string": A string representation of the policy, > > Since it is no longer a "string representation" of the policy, but rather an > array of strings, at least the description should probably change to: > "An encoding of the policy as a JSON array of strings" or some such. You > could also rename the element to "policy-array", but I don't feel strongly > about that. > > 4.5. Policy Samples > > Part of the report body includes the policy that is applied when > attemping relay to the destination. > > For DANE TLSA policies, a JSON array of strings each representing > the > RDATA of a single TLSA resource record as a space-separated list of > its four TLSA fields; the fields are in presentation format > (defined > in RFC6698 Section 2.2) with no internal spaces or grouping > parentheses: > > ["3 0 1 > 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", > 3 0 1 > > 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"] > > There's a missing open double-quote for the second "3 0 1". > > For the MTA-STS policy, an array of JSON string will > represent the > > s/array of JSON string will represent/JSON array of strings that represents/ > just as in the DANE paragraph above. > > policy that is declared by the receiving site, including any errors > that may be present. Note that if there are multiple MX records, > they are not included as an array. > > [ > "version: STSv1", > "mode: report", > "mx: mx1.example.com", > "mx: mx2.example.com", > "mx: mx.backup-example.com", > "max_age: 12345678" > ] > > I reformatted the JSON array with one element per line for clarity (putting > the square brackets on separate lines), I think you should do the same both > here, and in the DANE example: > > [ > "3 0 1 > 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", > "3 0 1 > 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234" > ] > > The comment about MX host patterns not being included as an array may be a > confusing. It might be clearer to say: > > Note that where there are multiple "mx" values, they must be listed as > separate > "mx" elements in the policy array, rather as a single nested "mx" sub-array. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
