On 4/27/11 11:39 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: John R. Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Wednesday, April 27, 2011 2:27 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Output summary
If you believe that, the output should only include signatures that
verified, right? So you aren't suppsed to report TEMPFAIL or PERMFAIL.
Except that if it TEMPFAILed, the output can optionally include a queued
copy of the message and part of a of SMTP transaction.
There are two layers of output: Output of the algorithm, and output of some
API that performs it. I think I was talking about the former, but I realize
the section could be read as the latter.
A truly minimal API output might just be the list of domains for which there
was a valid signature, and that set might be empty.
As for TEMPFAIL, you'd have to know which signature(s) were temp-failed in
order to decide about a later retry, which then leans us back toward giving
the whole list of signatures that were present and a status for each.
IMO section 7.2 in its current form allow such ambiguities between
output of algorithm and output of API, as the paragraph introduces the
term 'other parts of the mail system'. I suggest to use the same
terminology here as in par. 3.2:
"Verifiers wishing to communicate the results of verification to a
consuming agent..."
And for a consuming agent I think the bare minimum set of possible
statuses which MUST be communicated by the verifier contains just
SUCCESS and FAILED. A verifier MAY choose to add more information about
failure (tempfail and other statuses), but is not required to do so.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html