From: John R. Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Thursday, April 28, 2011 10:52 AM
To: Murray S. Kucherawy
Subject: Re: [ietf-dkim] Output summary
I wouldn't be opposed to doing so, except that 4871 says in two separate
places not to do that. Section 7 is, now that I look at it, really badly
written, since it implies that a "verifier" is an SMTP server.
I can take a run at fixing Section 7. What's the other place that says
not to do that?
Last paragraph of sec 5.2: " Verifiers SHOULD ignore failed signatures as
though they were not present in the message."
Is that inconsistent with the idea of only reporting signatures that verified
or those that TEMPFAILed? In that model, failed ones aren't reported which is
logically equivalent to them being ignored. Seems like a fit to me.
My preference would be to return a list of signatures that either passed
or TEMPFAILed, which could be the empty set if all of them PERMFAILed or
the message was unsigned, or none of them were acceptable in the first
place for whatever policy reasons. The caller can decide whether it
wants to try the whole shebang again later, or continue with what it
got. It's simple and complete.
That seems reasonable, but I wonder if that's a large enough change to
provoke a recycle. I suppose we can argue that the prior language was
inconsistent. What does opendkim do? My verifier, which sometimes runs
in the SMTP session and sometimes runs other places, treats tempfail
and permfail the same.
The return code provided by the final evaluation function does make the
distinction, although the caller could treat the two the same just as you do.
It also provides a mechanism for the caller to look through the signatures and
get a result for each so that if the caller doesn't want to use that distilled
result, it's free to do something more complicated.
NOTE WELL: This list operates according to