On Mon, Aug 18, 2025 at 6:04 AM Alessandro Vesely <[email protected]> wrote:
> Hi, > > I'd modify the last sentence of the 2nd paragraph like so: > > OLD > Failure reports are normally generated and sent almost immediately > after the Mail Receiver detects a DMARC failure. Rather than waiting > for an aggregate report, these reports are useful for quickly > notifying the Domain Owners when there is an authentication failure. > Whether the failure is due to an infrastructure problem or the > message is inauthentic, failure reports also provide more information > about the failed message than is available in an aggregate report. > > NEW > Failure reports are normally generated and sent almost immediately > after the Mail Receiver detects a DMARC failure. Rather than waiting > for an aggregate report, these reports are useful for quickly > notifying the Domain Owners when there is an authentication failure. > Failure reports also provide more information about the failed message > than is available in an aggregate report. This allows the failure > report consumer to determine with certainty whether the failure is due > to an infrastructure problem or the message is illicit. > > > Better or worse? > > > Best > Ale > I can live with either verbiage but for Ale's suggested new text I would propose something slightly different along the lines below.: "Legitimate" problem areas go beyond "infrastructure". Enumerating in detail the different ways authentication for legitimate mail can fail is best left for a BCP or informational document. Failure reports are normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure. Rather than waiting for an aggregate report, these reports are useful for quickly notifying the Domain Owners when there is an authentication failure. Failure reports also provide more information about the failed message than is available in an aggregate report. This allows the failure report consumer to better determine whether the failure is due to a Sender/path problem or the message is from an unrelated origin and potentially malicious. Michael Hammer
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
