Murray S. Kucherawy wrote: >> -----Original Message----- >> From: John R. Levine [mailto:jo...@iecc.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