If we are inventing new extended codes, I would rather see support for this: http://tools.ietf.org/html/draft-macdonald-antispam-registry-02
This was created before DMARC, and there really isn't anything in there that would be a good match at the moment, but we can obviously extend it. On 8/9/13 3:35 PM, "Franck Martin" <[email protected]> wrote: > >On Aug 9, 2013, at 9:11 PM, Tim Draegen <[email protected]> wrote: > > >Franck Martin was running this down most recently, based on some chatter >on the mailman-dev list. > >I'll offer up Franck's thinking (of which I agree!): > >- Register 5.7.17 with IANA >- >http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-s >tatus-codes.xml >- ..to indicate a DMARC policy rejection. > >Unclear if such an entry would cover SPF, ADSP, etc, too. > > > > > >I think 5.7.17 should be a bit generic to indicate the email could not >be (domain?) authenticated, be it with SPF, ADSP, DMARC, and even TLS. >However it should not indicate a SMTP AUTH failure. > >We should take this discussion over to [email protected] > > > -- Jeff Macdonald _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
