Hello Alessandro, I mean an enhanced status code, as at https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml .
Would you reply to messages failing DMARC with such a code, irrespective of whether the message was accepted or rejected? Are there privacy risks connected with such ESC? Regards Дилян On Fri, 2019-08-02 at 19:18 +0200, Alessandro Vesely wrote: > 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
