Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
On 5/23/19 3:52 PM, John Levine wrote: > In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write: >> There are domains that would like to receive reports, but whose usage of >> mail doesn't make it useful to express a policy. Conversely, there are >> domains that want to express a policy but aren't interested in reports. >> I'd like to advocate that DMARC be split up into two different documents >> dealing with reporting and policy separately. If it's useful to have a >> separate document that defines what it means to be "DMARC-compliant" >> that is referenced by both, that would be OK. > Given that we already have one document, I would be very strongly > opposed to this. It's fine to fix things that are wrong, but trying > to restructure it retroactively will inevitably lead to accidental > incompatibilities. MTA-STS and TLSRPT started out as one document as well, and separated quite cleanly IMO. I'm not sure what kind of incompatibilities you think might be created. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
In article <20190523225213.c214620147b...@ary.qy>, John Levine wrote: >In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write: >>There are domains that would like to receive reports, but whose usage of >>mail doesn't make it useful to express a policy. Conversely, there are >>domains that want to express a policy but aren't interested in reports. >>I'd like to advocate that DMARC be split up into two different documents >>dealing with reporting and policy separately. If it's useful to have a >>separate document that defines what it means to be "DMARC-compliant" >>that is referenced by both, that would be OK. > >Given that we already have one document, I would be very strongly >opposed to this. It's fine to fix things that are wrong, but trying >to restructure it retroactively will inevitably lead to accidental >incompatibilities. On the other hand, if you want to write separate non-normative tutorials for the reporting part and the policy part, sure, go ahead. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", 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
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write: >There are domains that would like to receive reports, but whose usage of >mail doesn't make it useful to express a policy. Conversely, there are >domains that want to express a policy but aren't interested in reports. >I'd like to advocate that DMARC be split up into two different documents >dealing with reporting and policy separately. If it's useful to have a >separate document that defines what it means to be "DMARC-compliant" >that is referenced by both, that would be OK. Given that we already have one document, I would be very strongly opposed to this. It's fine to fix things that are wrong, but trying to restructure it retroactively will inevitably lead to accidental incompatibilities. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis issue: Separating reporting and policy
In response to Seth Blank's call for issues of 9 May 2019: DMARC contains what are really two distinct mechanisms, a reporting mechanism and a policy mechanism. The policy mechanism is largely a request to the verifier about what to do in the event that a message is received that does not comply with policy. There are domains that would like to receive reports, but whose usage of mail doesn't make it useful to express a policy. Conversely, there are domains that want to express a policy but aren't interested in reports. I'd like to advocate that DMARC be split up into two different documents dealing with reporting and policy separately. If it's useful to have a separate document that defines what it means to be "DMARC-compliant" that is referenced by both, that would be OK. There was a similar situation with MTA-STS which had both a policy and a reporting mechanism, and that was broken into two standards-track RFCs: RFC 8460 (SMTP TLS Reporting) and RFC 8461 (SMTP MTA Strict Transport Security). I consider this to be a relevant precedent. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
