Re: [dmarc-ietf] 4.1 DMARC Basics
> On Mar 3, 2024, at 1:41 AM, ves...@tana.it wrote: > > Hi, > > the last two paragraphs of section 4.1 also show a neat asymmetry between rua > and ruf. The first sounds like the notification that feedback exists rather > than something a mail receiver should do. The second is good, but not > normative. > > > OLD > DMARC's feedback component involves the collection of information > about received messages claiming to be from the Author Domain for > periodic aggregate reports to the Domain Owner or PSO. The > parameters and format for such reports are discussed in > [I-D.ietf-dmarc-aggregate-reporting] > > A DMARC-enabled Mail Receiver might also generate per-message reports > that contain information related to individual messages that fail > authentication checks. Per-message failure reports are a useful > source of information when debugging deployments (if messages can be > determined to be legitimate even though failing authentication) or in > analyzing attacks. The capability for such services is enabled by > DMARC but defined in other referenced material such as [RFC6591] and > [I-D.ietf-dmarc-failure-reporting] > > > NEW > A DMARC-enabled Mail Receiver SHOULD collect authentication results > and generate aggregate reports that contain information about > received messages claiming to be from the Author Domain for periodic > aggregate reports to the Domain Owner or PSO. The parameters and > format for such reports are discussed in > [I-D.ietf-dmarc-aggregate-reporting] > > A DMARC-enabled Mail Receiver MAY also generate per-message reports > that contain information related to individual messages that fail > authentication checks. Per-message failure reports are a useful > source of information when debugging deployments (if messages can be > determined to be legitimate even though failing authentication) or in > analyzing attacks. The capability for such services is enabled by > DMARC but defined in other referenced material such as [RFC6591] and > [I-D.ietf-dmarc-failure-reporting] > > How's that? > > Best > Ale > Perfect. It makes it clear what’s critical, aggregate reports, and that you may provide at your own volition, leaving room for PII policies and the like. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 4.1 DMARC Basics
On Sun, Mar 3, 2024 at 4:41 AM wrote: > Hi, > > the last two paragraphs of section 4.1 also show a neat asymmetry between > rua and ruf. The first sounds like the notification that feedback exists > rather than something a mail receiver should do. The second is good, but > not normative. > > > OLD > DMARC's feedback component involves the collection of information > about received messages claiming to be from the Author Domain for > periodic aggregate reports to the Domain Owner or PSO. The > parameters and format for such reports are discussed in > [I-D.ietf-dmarc-aggregate-reporting] > > A DMARC-enabled Mail Receiver might also generate per-message reports > that contain information related to individual messages that fail > authentication checks. Per-message failure reports are a useful > source of information when debugging deployments (if messages can be > determined to be legitimate even though failing authentication) or in > analyzing attacks. The capability for such services is enabled by > DMARC but defined in other referenced material such as [RFC6591] and > [I-D.ietf-dmarc-failure-reporting] > > > NEW > A DMARC-enabled Mail Receiver SHOULD collect authentication results > and generate aggregate reports that contain information about > received messages claiming to be from the Author Domain for periodic > aggregate reports to the Domain Owner or PSO. The parameters and > format for such reports are discussed in > [I-D.ietf-dmarc-aggregate-reporting] > > A DMARC-enabled Mail Receiver MAY also generate per-message reports > that contain information related to individual messages that fail > authentication checks. Per-message failure reports are a useful > source of information when debugging deployments (if messages can be > determined to be legitimate even though failing authentication) or in > analyzing attacks. The capability for such services is enabled by > DMARC but defined in other referenced material such as [RFC6591] and > [I-D.ietf-dmarc-failure-reporting] > > Issue 127 open to track this. I think there's something here to work with. -- *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. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] 4.1 DMARC Basics
Hi, the last two paragraphs of section 4.1 also show a neat asymmetry between rua and ruf. The first sounds like the notification that feedback exists rather than something a mail receiver should do. The second is good, but not normative. OLD DMARC's feedback component involves the collection of information about received messages claiming to be from the Author Domain for periodic aggregate reports to the Domain Owner or PSO. The parameters and format for such reports are discussed in [I-D.ietf-dmarc-aggregate-reporting] A DMARC-enabled Mail Receiver might also generate per-message reports that contain information related to individual messages that fail authentication checks. Per-message failure reports are a useful source of information when debugging deployments (if messages can be determined to be legitimate even though failing authentication) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [RFC6591] and [I-D.ietf-dmarc-failure-reporting] NEW A DMARC-enabled Mail Receiver SHOULD collect authentication results and generate aggregate reports that contain information about received messages claiming to be from the Author Domain for periodic aggregate reports to the Domain Owner or PSO. The parameters and format for such reports are discussed in [I-D.ietf-dmarc-aggregate-reporting] A DMARC-enabled Mail Receiver MAY also generate per-message reports that contain information related to individual messages that fail authentication checks. Per-message failure reports are a useful source of information when debugging deployments (if messages can be determined to be legitimate even though failing authentication) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [RFC6591] and [I-D.ietf-dmarc-failure-reporting] How's that? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
