The wording you're using seems inconsistent to me. Specifically, you're saying that x.7.30 means one thing when attached to a 200-series reply, but the opposite when attached to a 500-series reply. I would prefer to see two separate codes if you're going to do this.
But the bigger question is implementation. Who would make use of this, either as a sender or a receiver? -MSK On Fri, Aug 2, 2019 at 1:19 PM Дилян Палаузов <dilyan.palau...@aegee.org> wrote: > Hello Murray, > > ESC X.7.20, X.7.21 and X.7.22 are glued to return code 550, while I > propose an ESC, that works also with 250. > > Apart from this, X.7.20 and X.7.21 cannot be used instead of the proposed > X.7.30: > > If a site sees a valid DKIM signature, and previous experience with the > domain signing DKIM leads to increased trust in > this domain, then the signature is acceptable, but it does not have to > align with the From: address. > > With X.7.22: > > Description: This status code is returned when a message > contains one or more passing DKIM > signatures, but none are acceptable because > none have an identifier(s) > that matches the author address(es) found in > the From header field. This is a special > case of X.7.21. (This violates the advice > of Section 6.1 of RFC 6376.) > > If “none have an identifier that matches the author address found in the > From header field” means, that the DKIM part of > DMARC fails, then this ESC can be recommended by the DMARC specification > to signal to the sender, that the DKIM > implementations of sender and receiver disagree, as a light substitute to > the failure reports. > > Greetings > Дилян > > > On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote: > > On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов < > dilyan.palau...@aegee.org> wrote: > > > I mean an enhanced status code, as at > > > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > . > > > > RFC7372 registered some for exactly this purpose (though not specific to > DMARC). Its Security Considerations section talks about the privacy risks. > > > > I don't know if they're actually in use. > > > > -MSK > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
