Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
On Mon, 28 Dec 2020, Ned Freed wrote: > I'm not ethusiastic about the split, but if that's what people want then so be > it. I will say that my experience has been that doing so is usually more work > and provides less benefit than you'd expect. I recall agreeing to split out all of the reporting into a separate draft, which makes some sense so the two parts can proceed separately, but not further splitting aggregate and failure reports. I was referring to the latter; I thought the reference to the drafts involved made that clear. Sorry for the confusion. The outcome of the split of MIME part one into four parts may offer some limited insight here. IMO splitting message bodies from media types was a sound logical split and ended up being a good thing. The split of conformance criteria from media types, however, was a pretty serious lose - they now tend to get ignored - so much so it's tempting to try and undo it. But the split of media type registration from MIME/email was the real win, so much so that it more than justified the entire activity. The lesson, if there is one, is to go just far enough, but no further. Splitting different reporting types smells a lot like "further" to me. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
On 12/28/2020 1:17 PM, Michael Thomas wrote: On 12/28/20 10:05 AM, Seth Blank wrote: We agreed to split aggregate and failure reporting into different documents, and this split was discussed on the list several times, as well as at IETF 108. The intention was to split apart the key components that realistically get updated in different manners / at different cadences. Aggregate reports and failure reports get used in wholly different manners, have fundamentally different use cases, are implemented in wildly different ways, and have completely different privacy and security considerations. Hence, we agreed they should be split into separate documents, so each can be concise, to the point, and independently updated. Does that mean all of the reporting? So that DMARC is really ADSP-bis? When Seymour Cray was asked by his engineers building the Cray super computer, what primary language should they use for the new concept of Vectorization computing, Seymour responded; "I don't care what language we use ... just call it FORTRAN!" It's marketing now, folks. It was what academia was teaching and industry engineers were using at the time. Lets just get the DKIM-POLICY model done and call it DMARC. I really don't care because the basic fundamental concept has been established and to me, that is the most significant gain we have here - the DKIM-POLICY DNS LOOKUP concept has traction. Yes, functionally, they were all the same, SSP, ADSP, DSAP and DMARC, from the basic LMAP "Lightweight Mail Authorization Protocol" concept of using an author domain for a DKIM-POLICY DNS lookup model. DMARC is the latest with a different syntax language that has gained traction. I support DMARC for that only reason -- its about TIME!! I rather we define the protocol DKIM-POLICY Model because we already have a DKIM-TRUST model in the standard. Nonetheless, now we can piggy-back off the _dmarc.example.com DNS lookup rather than _adsp._domainkey.example.com. All the same concept, therefore all the same problems. Lets get DMARC done as a basic-lookup protocol and begin adding more to it related to 3rd party authorization protocols which can piggy-back of the DNS call. Reporting should of always been a separate consideration. PS: Consider how many DNS lookups an all-things SMTP receiver does for port 25, non-authenticated/Authorized connections. For wcSMTP: At connection: IP Geo Location Filter IP DNS RBL At SMTP before DATA Maybe EHLO domain DNS matching check Maybe EHLO domain SPF check Maybe MAIL FROM SPF check Maybe MAIL FROM Call Back Verifier (MX) At SMTP DATA if it gets this far: Maybe DKIM check Maybe ADSP 5322.From check Maybe DMARC 5322.From check Maybe ATPS 5322.From check Maybe VBR 5322.From check Overall, there are a lot of calls today per SMTP session. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
In article you write: >-=-=-=-=-=- >Aggregate reports and failure reports get used in wholly different manners, >have fundamentally different use cases, are implemented in wildly different >ways, and have completely different privacy and security considerations. All true, but the actual specs overlap quite a lot. For example, where does section 7.1 about verifying external destinations go? If the answer is that it's copied into two documents, that is bad. I think we've seen that for failure reporting there is nothing to change beyond updating the privacy considerations, so leaving all the reporting in one document is unlikely to cause schedule problems. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
On 12/28/20 10:05 AM, Seth Blank wrote: We agreed to split aggregate and failure reporting into different documents, and this split was discussed on the list several times, as well as at IETF 108. The intention was to split apart the key components that realistically get updated in different manners / at different cadences. Aggregate reports and failure reports get used in wholly different manners, have fundamentally different use cases, are implemented in wildly different ways, and have completely different privacy and security considerations. Hence, we agreed they should be split into separate documents, so each can be concise, to the point, and independently updated. Does that mean all of the reporting? So that DMARC is really ADSP-bis? The reporting is clearly a completely separate protocol from the policy mechanism, and is far more likely to mutate than the base policy mechanism which has changed very little from ADSP. I mean, as far as I can tell the main change from ADSP is to include spf too. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
We agreed to split aggregate and failure reporting into different documents, and this split was discussed on the list several times, as well as at IETF 108. The intention was to split apart the key components that realistically get updated in different manners / at different cadences. Aggregate reports and failure reports get used in wholly different manners, have fundamentally different use cases, are implemented in wildly different ways, and have completely different privacy and security considerations. Hence, we agreed they should be split into separate documents, so each can be concise, to the point, and independently updated. Seth, as Chair On Mon, Dec 28, 2020 at 10:00 AM Tim Wicinski wrote: > > I will admit my memory can get pretty hazy, but I agree with Mr Levine - I > remember splitting out reporting, > but only as one document. > > The Working Group can always make a compelling case to change this > > tim > > > On Mon, Dec 28, 2020 at 12:06 PM John R Levine wrote: > >> On Mon, 28 Dec 2020, Ned Freed wrote: >> > I'm not ethusiastic about the split, but if that's what people want >> then so be >> > it. I will say that my experience has been that doing so is usually >> more work >> > and provides less benefit than you'd expect. >> >> I recall agreeing to split out all of the reporting into a separate >> draft, >> which makes some sense so the two parts can proceed separately, but not >> further splitting aggregate and failure reports. >> >> Regards, >> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl.ly >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
I will admit my memory can get pretty hazy, but I agree with Mr Levine - I remember splitting out reporting, but only as one document. The Working Group can always make a compelling case to change this tim On Mon, Dec 28, 2020 at 12:06 PM John R Levine wrote: > On Mon, 28 Dec 2020, Ned Freed wrote: > > I'm not ethusiastic about the split, but if that's what people want then > so be > > it. I will say that my experience has been that doing so is usually more > work > > and provides less benefit than you'd expect. > > I recall agreeing to split out all of the reporting into a separate draft, > which makes some sense so the two parts can proceed separately, but not > further splitting aggregate and failure reports. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
On Mon, 28 Dec 2020, Ned Freed wrote: I'm not ethusiastic about the split, but if that's what people want then so be it. I will say that my experience has been that doing so is usually more work and provides less benefit than you'd expect. I recall agreeing to split out all of the reporting into a separate draft, which makes some sense so the two parts can proceed separately, but not further splitting aggregate and failure reports. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
