Hector Santos wrote: > ----- Original Message ----- > From: "Jim Fenton" <[EMAIL PROTECTED]> > To: "Eric Allman" <[EMAIL PROTECTED]> > Cc: "Mark Delany" <[EMAIL PROTECTED]>; <ietf-dkim@mipassoc.org> > Sent: Monday, May 01, 2006 7:59 PM > Subject: Re: [ietf-dkim] Re: dkim-base-01 nits and semi-nits > > > >> "Treat as unsigned" seems a little ambiguous when there might be >> multiple signatures. It might be interpreted as "treat the message as >> though it is completely unsigned" as opposed to "consider this signature >> invalid" which I think is your intent. >> > > Jim, > > I hope not. > > I understand the proposed pseudo procedure to handling multiple signatures, > looking for one that "works,", but it completely fascinates me to think how > failure state information can be ignored. > > How can one treat, view or interpret a failure signature as "unsigned" when > in fact, it was signed? > I don't think the wording "consider this signature invalid" requires the verifier to consider a signature failure as "unsigned". Yes, as I said in http://article.gmane.org/gmane.ietf.dkim/1751, I think one should consider failed signatures as if they aren't there, but I'm not sure that's something to include in the -base specification. Other opinions? How prescriptive should we be about how the verifier handles this?
Here's a good "if a tree falls in the woods..." sort of question to ponder: If someone attaches a DKIM-Signature header field that they know is invalid to a message, was the message signed? If not, how can you say that "in fact, it was signed"? > Continuing processing is one thing, but treated it as it never happen? I > fail to see this logic. Even if not rejected, but logged or flagged, that is > not treated it as it was unsigned. > > If I was a domain signer, and I was responsible for this mail with my > reputation on the line, I would want the verifier to prune all failures > because it was not what I expected and I don't want potentially harmful > mail, which is probably isn't mind to begin with, reaching the intended > end-user. > Keep that thought for the SSP discussion. > And even if the verifier is not going to reject, I certainly do not want it > to ignore the fact there was a failure with mail purported to be from > domain. > > So what or how should the verifier do? What is expected of them by domain > signers? > > I can only see this work if the verifiers gets help from the domain itself > having an email policy that tells verifiers how to handle failures. > That's a direction we could go with SSP, when we get to that discussion. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
