Hi Dilyan,
I'm not clear if you refer to the "DSN" extension (rfc3461). In fact, positive DSNs contain the A-R header field, and so can inform the sender when a message is accepted although some of SPF/ DKIM/ DMARC failed. I don't send failure reports, as they look plenty of privacy risks. Perhaps they could be sent to trusted sites only, but that way they'd lose generality. It's unfortunate that FR seem to be the only means to tell unwanted failures from real spam/ phishing successfully blocked by the protocol. Perhaps that distinction could be added to aggregate reports, even if it's not an exact science. Best Ale On Fri 02/Aug/2019 18:00:11 +0200 Дилян Палаузов wrote: > > why sites do not sent failure reports? > > Will a site, not sending failure report, be willing to use an Enhanced Status > Code, to signal, that the DKIM/SPF > implementations of the receiver and sender disagree? > > * * * New Enhanced Status Code for Failed DMARC Validation > > Code: X.7.30 > Assocaited basic status code: Any > Description: Used as partial substitution to failure reports, when DMARC > validation fails. 250 2.7.30 means, that the > message was delivered, ordinary or as junk, despite failed DMARC validation. > 550 5.7.30 is used when the message is > rejected, because the DMARC validation failed. This status code is only > usefull, when the receiving site does not send > failure reports. > > Regards > Дилян -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
