On Fri, Mar 1, 2024 at 6:00 PM John Levine <[email protected]> wrote:
> It appears that Todd Herr <[email protected]> said: > >Below please find the current text (rev -30) and my proposed replacement > >text. > > It seems OK but I would say that at this point that mailto: URI are the > only > ones currently defined. > Participating, to this point. Throwing out an idea, that may be spectacularly bad: mailto: is the only function that's ever been used. We even discussed exploring other mechanisms, and consensus was to drop that exploration. I can't find the ticket quickly, but I know it was covered early on during the bis work. Do we just want to dramatically simplify this, and throw the "mailto:"; into the reporting ABNF and call it a day? It would dramatically streamline the text. > > > > >PROPOSED REPLACEMENT TEXT: > >========================= cut here ========================== > >rua: > > > >Addresses to which aggregate feedback reports are to be sent > >(comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the > >Domain Owner is requesting Mail Receivers to send aggregate feedback > >reports about results of authentication checks performed on mail using the > >domain for which the DMARC policy record is published. [ > >I-D.ietf-dmarc-aggregate-reporting > ><#I-D.ietf-dmarc-aggregate-reporting>] discusses > >considerations that apply when the domain name of a URI differs from that > >of the domain advertising the policy. See Section 11.6 > ><#external-report-addresses> for additional considerations. Any valid URI > >can be specified. A Mail Receiver MUST implement support for a "mailto:"; > >URI, i.e., the ability to send a DMARC report via electronic mail. If the > >tag is not provided, Mail Receivers MUST NOT generate aggregate feedback > >reports for the domain. URIs not supported by Mail Receivers MUST be > >ignored. The aggregate feedback report format is described in [ > >I-D.ietf-dmarc-aggregate-reporting <#I-D.ietf-dmarc-aggregate-reporting>]. > ><#section-5.3-4.14.1> > >ruf: > > > >Addresses to which message-specific failure information is to be reported > >(comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the > >Domain Owner is requesting Mail Receivers to send detailed failure reports > >about messages that fail the DMARC evaluation in specific ways (see the > >"fo" tag above). [I-D.ietf-dmarc-aggregate-reporting > ><#I-D.ietf-dmarc-aggregate-reporting>] discusses considerations that apply > >when the domain name of a URI differs from that of the domain advertising > >the policy. See Section 11.6 <#external-report-addresses> for additional > >considerations. A Mail Receiver MUST implement support for a "mailto:"; > URI, > >i.e., the ability to send a DMARC report via electronic mail. If the tag > is > >not provided, Mail Receivers MUST NOT generate failure reports for the > >domain. URIs not supported by Mail Receivers MUST be ignored. The format > >for message-specific failure reporting is described in [ > >I-D.ietf-dmarc-failure-reporting <#I-D.ietf-dmarc-failure-reporting>]. > >========================= cut here ========================== > > > >Discuss at your convenience, please... > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank * | Chief Technology Officer *e:* [email protected] *p:* 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
