Murray S. Kucherawy wrote:
-----Original Message-----
From: John R. Levine [mailto:johnl(_at_)iecc(_dot_)com]
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.
+1
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.
+1, "A DKIM Complete API...."
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.
Murray,
How do you reconcile section 7.2 Communicate Verification Results with
this new section for verifiers?
I think this proposed Output Summary new section may fit better under
section 7.2. After all that is what we are trying to do -
communicating or reporting verification results. Since A-R is now
considered to be added as a possible header to sign, we are further
reinforcing the DKIM Mail Integration with A-R.
I am just throwing this out there (mod as necessary) to 7.2
------------------
7.2. Communicate Verification Results
To make DKIM verification output useful, there are mandatory outputs
that MUST be made available to consumers of DKIM results.
Verifiers may report results in whatever manner they see fit but
the recommended reporting method is using the Authentication-Results
[RFC5451] header.
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to
search for results header fields to visibly mark authenticated
mail for end users should verify that such header field was added
by the appropriate verifying domain and that the verified identity
matches the author identity that will be displayed by the MUA. In
particular, MUA filters should not be influenced by bogus results
header fields added by attackers. To circumvent this attack,
verifiers may wish to delete existing results header fields after
verification and before adding a new header field.
All verifications MUST produce status code output indicating whether
or not the signature was validated (PERMFAIL or TEMPFAIL as described
n Section 7.1)
Reporting SHOULD by done for each signature until the first valid
signature is found. Reporting invalid signatures is out of scope.
but MAY be reported using Authentication-Results headers.
For trust assessment reporting, the mandatory SDID (d=) value is
required for the signer assessment for valid signatures only.
Trust reporting MUST not be done for invalid signatures.
Additional reporting can be done using additional DKIM output
values including non-DKIM related values. One consideration for
the values to report would be values that are bound to the signature
such as:
- identity (i=)
- selector (s=)
- AUID (From: domain)
------------------
My overall concernr with the proposed section 4.9 is that will
handicap implementation following the strict DKIM interpretation.
When they finally see there are added-value protocols like A-R, they
will need to change they code again.
Case in point, the ALT-N API. Its verifier output structure was
insufficient to supply the values for the A-R reporting. I did not
want to duplicate a RFC5322 streaming parser since the verifier
already did that. So the output structure was changed, the function
modified to set the values. This allowed me to start generating the
A-R record, for example:
Authentication-Results: dkim.winserver.com;
dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
adsp=none author.d=cloudmark.com signer.d=mipassoc.org;
Refresh readers need the insight to determine what are all the
"useful" values to report.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html