[ietf-dkim] Output summary
John R. Levine
johnl at iecc.com
Thu Apr 28 10:52:19 PDT 2011
>> 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."
> 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.
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
More information about the ietf-dkim