Murray S. Kucherawy wrote:
All the errata is saying is that all DKIM APIs must return, at a
minimum, the "d=" and the evaluation result. There are no other
limits imposed.
The concern I have is that an SMTP vendor may erroneous model his
"Assessor" hook by recording two data points on the design presumption
the assessor functional signature is:
bool dkim_accessor(bool dkim_result, string d_tag_value);
When new assessors emerge, the potential is very high a different
signature is required thus the new accessor will not be compatible
with SMTP servers that do this.
For example, using our system, when we first produced our WCSAP
product back in 2003 which evaluates the SMTP envelope using SPF and
DNSRBL originally, the "API" prototype was fixed:
BOOL Call_WCSAP(
IP, // client connecting ip address
CDN, // client domain name (HELO/EHLO)
RP) // Return Path, (MAIL FROM)
The Assessors here were locked for SPF and DNSRBL lookups and it
return a TRUE and FALSE result. TRUE continue with DATA, FALSE, a 550
reply code was issued. The functionality was locked based on
existing well known "standard" technologies at the time. That is what
I see here.
What happen is that over time, it evolved where we needed to pass more
SMTP session and server information when a new assessor "scripting
rules" were added:
IP // client connecting ip address
CDN // client domain name (HELO/EHLO)
RP // Return Path, (MAIL FROM)
FP_LIST // Forwarding Path (RCPT TO)
SRV // Server Host domain
SRVIP // Server Host IP
AUTHID // ID of AUTHenticated user
and the return status was no long TRUE or FALSE but a 64 bit double word:
HIWORD - ACCEPT, REJECT, REJECT_BUT_KEEP
LOWORD - REPLY_CODE
After this change, its been stable and there was no need to change in
3-4 years.
So in my view, the SMTP system can potentially design the DKIM
assessor two fields signature hook and lock himself in. Now only
specific assessors are compatible with it. Since we don't have any
real experience of what assessors will need, I believe we can preempt
the potential problem for SMTP servers and Assessor Developers by
suggesting all information SHOULD be made available, and therefore
Assessor Developers will have a persistent and consistent protocol to
work with all DKIM compliant SMTP systems.
You're not the only developer on this list with decades of professional
experience in multiple environments, Hector. Let's leave the
resumes off the list, please. We're here to co-operate, not
compete.
Of course, there was no suggestion otherwise, but it shows there are
multiple valid viewpoints and I believe in general the RFC should
minimize implementation API discussions here, especially the socket
paragraph (get rid of it). I think it is not correct as stated and
could cause problems. I just don't think its necessary. The fact you
did state they can add more information, it should not be a subjective
thing. We are talking about the Assessor Interface, it should be a
fixed consistent interface that all Assessor developers can depend on.
Anyway, I think this thread has run its course. :-)
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html