Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags
> On Mar 1, 2024, at 5:39 PM, John R Levine wrote: > > On Fri, 1 Mar 2024, Seth Blank wrote: >>> 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. > > That would be fine with me. I proposed an http method similar to the one for > mta-sts and everyone said no need, mail is plenty fast. I have mta-sts https > set up and indeed, basically nobody uses it. Now. But do you think it has ponptential to catch on? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags
On Fri, Mar 1, 2024 at 5:20 PM Seth Blank wrote: > 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. > Normatively, I don't think it makes a difference. If you say this has to be a URI but "mailto" is the only supported one, you've done the logical equivalent of constraining the ABNF. Then, if later one someone does succeed in arguing that some other URI scheme is usable here, such an update would be a little simpler if it didn't require an ABNF update. Given that, I'd argue for not changing the ABNF. -MSK, p11g ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags
Seth Blank writes: On Fri, Mar 1, 2024 at 6:00 PM John Levine wrote: It appears that Todd Herr 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. I may be dumb, but don't see the improvement: A Mail Receiver MUST implement support for a "mailto:; URI A Mail Receiver MUST implement support for a URI I'm not sure the format description is the right place for those normative statements. The text would become simpler if they are moved away. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags
On Fri, 1 Mar 2024, Seth Blank wrote: 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. That would be fine with me. I proposed an http method similar to the one for mta-sts and everyone said no need, mail is plenty fast. I have mta-sts https set up and indeed, basically nobody uses it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags
On Fri, Mar 1, 2024 at 6:00 PM John Levine wrote: > It appears that Todd Herr 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank * | Chief Technology Officer *e:* s...@valimail.com *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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags
It appears that Todd Herr 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. >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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags
Colleagues, I mentioned in a different thread that I had an issue with the description of the rua and ruf tags in Section 5.3., General Record Format, specifically that I thought that they could be more consistent in their wording. Below please find the current text (rev -30) and my proposed replacement text. CURRENT TEXT: = cut here == rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). [ 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. 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. See Section 11.6 <#external-report-addresses> for additional considerations. = cut here == 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... -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* todd.h...@valimail.com *p:* 703-220-4153 *m:* 703.220.4153 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.
