Re: [Uta] Updated TLSRPT (WGLC Comments)

<alexander_brot...@cable.comcast.com> Cc: uta@ietf.org 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 wh

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

Re: [Uta] Updated TLSRPT (WGLC Comments)

> On Mar 4, 2018, at 1:47 PM, Brotman, Alexander > 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

[Uta] Updated TLSRPT (WGLC Comments)

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

Re: [Uta] Updated TLSRPT

Of Viktor Dukhovni Sent: Wednesday, January 31, 2018 5:44 PM To: uta@ietf.org Subject: Re: [Uta] Updated TLSRPT > On Jan 31, 2018, at 5:24 PM, Keith Moore <mo...@network-heretics.com> wrote: > > You just can't name the content-type something+gzip... Not sure I understood the above cor

Re: [Uta] Updated TLSRPT

IMO if you want to define application/tlsrpt in such a way that readers/processors can reliably distinguish between clear text JSON and gzipped JSON , say by looking at the first few bytes of the content for the header magic number indicating gzip compression, you're free to do so. You just

Re: [Uta] Updated TLSRPT

> On Jan 31, 2018, at 3:12 PM, ned+...@mrochek.com wrote: > >> I fail to see any interoperability concern. Perhaps, I'm missing >> something. Please explain. > > The +json suffix is defined to mean that the content consists of JSON, > and can be parsed as such, independent of any

Re: [Uta] Updated TLSRPT

> > On Jan 31, 2018, at 2:44 PM, Keith Moore wrote: > > > > You don't violate 27 years of practice based on any number of tests that > > this WG is capable of doing, just to avoid defining two content-types. > I remain quite puzzled as to the nature of the

Re: [Uta] Updated TLSRPT

> No. You don't violate 27 years of practice based on any number of tests that > this WG is capable of doing, just to avoid defining two content-types. Exactly right. We couldn't possibly perform a meaningful test of this sort. And even if we could, and if the results showed there were no

Re: [Uta] Updated TLSRPT

> On Jan 31, 2018, at 2:44 PM, Keith Moore wrote: > > You don't violate 27 years of practice based on any number of tests that this > WG is capable of doing, just to avoid defining two content-types. I remain quite puzzled as to the nature of the violation. All I

Re: [Uta] Updated TLSRPT

No. You don't violate 27 years of practice based on any number of tests that this WG is capable of doing, just to avoid defining two content-types. Sent from my iPhone > On Jan 31, 2018, at 2:25 PM, James Cloos wrote: > > FWIW, I tried sending myself a gzip(1)ed json file

Re: [Uta] Updated TLSRPT

FWIW, I tried sending myself a gzip(1)ed json file using: Content-Type: application/tlsrpt+json; conversions=gzip It worked fine. And gnus even gunzip(1)ed it for me when I asked it to inline the attachment. This was sent to another system which has a .forward file pointing to my main

Re: [Uta] Updated TLSRPT

> On Jan 31, 2018, at 5:46 AM, Keith Moore wrote: > > The whole point of the "+json" convention is to let email processors know > that they can parse the attachment as JSON without having to know more about > the rest of the content. So existing mail processors

Re: [Uta] Updated TLSRPT

On Jan 29, 2018, at 10:51 AM, Alexey Melnikov wrote: > Viktor, > > > On 29/01/2018 15:46, Viktor Dukhovni wrote: >>> On Jan 29, 2018, at 2:35 AM, Valery Smyslov wrote: >>> >>> Again, please provide the text. Otherwise the iterations >>> update-review may last forever.

Re: [Uta] Updated TLSRPT

> On Jan 29, 2018, at 11:36 AM, Alexey Melnikov > wrote: > > What you are proposing is not a part of MIME. You can't introduce > Content-Encoding header field in email and remaing backward compatible with > existing code. The time for this proposal was

Re: [Uta] Updated TLSRPT

> On Jan 29, 2018, at 10:51 AM, Alexey Melnikov > wrote: > >>> On Jan 29, 2018, at 2:35 AM, Valery Smyslov wrote: >>> >>> Again, please provide the text. Otherwise the iterations >>> update-review may last forever. >> It is unclear from the

Re: [Uta] Updated TLSRPT

Viktor, On 29/01/2018 15:46, Viktor Dukhovni wrote: On Jan 29, 2018, at 2:35 AM, Valery Smyslov wrote: Again, please provide the text. Otherwise the iterations update-review may last forever. It is unclear from the current state of the document whether my suggestion

Re: [Uta] Updated TLSRPT

> On Jan 29, 2018, at 2:35 AM, Valery Smyslov wrote: > > Again, please provide the text. Otherwise the iterations > update-review may last forever. It is unclear from the current state of the document whether my suggestion to have just one MIME type with compression

Re: [Uta] Updated TLSRPT

Hi Viktor, many thanks to you for the deep review and thanks to authors for the update. > > We uploaded a new version of the TLSRPT a few moments ago. The majority of > > the changes are meant to > address comments submitted by Viktor Dukhovni (https://www.ietf.org/mail- >

Re: [Uta] Updated TLSRPT

> On Jan 26, 2018, at 9:41 AM, Brotman, Alexander > wrote: > > We uploaded a new version of the TLSRPT a few moments ago. The majority of > the changes are meant to address comments submitted by Viktor Dukhovni >

[Uta] Updated TLSRPT

Hello, We uploaded a new version of the TLSRPT a few moments ago. The majority of the changes are meant to address comments submitted by Viktor Dukhovni (https://www.ietf.org/mail-archive/web/uta/current/msg02388.html). A rough list of changes: - Update to mime type - Add dnssec-required -

Re: [Uta] Updated TLSRPT Draft (v07)

Additionally, I've just noticed that the rua field in TLSRPT is unlike DMARC, and is a single URL, not a comma-separated list. In my experience deploying DMARC, it's been useful to feed reports to multiple systems. If that's an oversight, rather than an explicit decision, I'd be keen on TLSRPT

Re: [Uta] Updated TLSRPT Draft (v07)

A couple of minor comments: 1. Section 3 includes: "A URI specifying the endpoint to which aggregate information about policy failures should be sent" and "When sending failure reports via SMTP" This might imply that reports should only be sent when a failure is experienced, whereas I believe

[Uta] Updated TLSRPT Draft (v07)

Hello Folks, We attempted to incorporate the feedback from Alexey and Chris as best we could, and we believe we have addressed each of their concerns either via the updated draft or via the mailing list. The period for the WGLC is nearly over, and we wanted to try to provide an