Agree with Dave here. There's no actual usage issues that are being addressed that merit the split (and the work involved). If you want to receive reports, but not have receivers enforce a policy, set 'p=none' and a rua. If you want to set a policy but not receive reports, set 'p=<policy>' and an empty rua. I don't see why that's considered confusing or problematic.
It's also worth noting that the the precedent isn't an actual operational precedent yet. There's only one major receiver who is sending SMTP TLS reports, and if you follow RFC 8460 to the letter you will not actually receive them. Unless you implement the DNS records described in RFC 8461, you don't get any reports. As someone who recently dealt with this, and had a back and forth with the receiver, I can personally attest that this was very confusing. The first data point from operational deployment seems to indicate that splitting RFC 8460/8461 may have been a mistake. It's either confusing for the implementing receiver (they are doing something they shouldn't be doing) or for the domain owner (RFC 8460 isn't enough to get reports by themselves). Best, Peter On Fri, May 24, 2019 at 6:03 AM Dave Crocker <dcroc...@gmail.com> wrote: > On 5/23/2019 1:35 PM, Jim Fenton wrote: > > 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. > > > I'm not clear what technical or operational problem you are trying to > solve. That is, you seem to be proposing a document split without any > technical changes. Yes? > > While separating or joining segments of specification makes a > difference, you haven't described what actual usage issues there have > been that warrant the effort to split this document. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > 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
