> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Hector Santos > Sent: Thursday, April 28, 2011 12:32 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Output summary > > > The only utility in revealing failed signature information is forensics. > > That sort of debugging function doesn't need to go in a protocol > > specification. > > -1. It is not a debugging function. > > It is about security (RFC4686) and deployments considerations > (RFC5863, see Section 7.3).
Neither of those citations give any value to a failed signature. > >> As the From: address is mandatory input for the signature, it may be a > >> logical step to also make it mandatory in the output? > > > > Given the above, do we still need to? > > To be more DKIM Mail Integration Consistent and Complete - yes. > > See RFC5585 Figure 1 DKIM Service Architecture. The AUID is needed for > the major CSP (Checking Signing Practice) black box flow in the DKIM > design. Since ADSP is predicated on the SDID, the AUID is not useful here. Moreover, the AUID in a failed signature is not useful as it could have been modified. And, once again, DKIM delivers those values but does not use them. You're talking about making a filtering decision based on them. Those happen in different layers. It's fine to have other layers do other amazing things, but we're trying to stay focused on this one. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
