Murray S. Kucherawy wrote:
OK, so now I guess I'm confused. My understanding is that if "i=" isn't
specified it takes the value of "d=", so I'm not clear how it can be
undefined?
Maybe the wording of the errata draft could be improved (I'll propose new
text shortly if I can), but here's my understanding:
I believe you're confusing the semantics of the DKIM signature with the
definition of the DKIM interface.
Again, think of this in terms of an API definition. Let's say you're
building a DKIM library to sell or give away. Obviously you need to know
what outputs are required, i.e. what application developers will expect from
you.
Are you trying to say?
DKIM_RESULT = DKIM_VERIFY(ENVELOPE, PAYLOAD)
FINAL_RESULT = DKIM_ASSESSOR(DKIM_RESULT, DKIM_TAG_QUERY("D") )
<<-- minimum requirement?
The errata draft is attempting to state clearly that the output of your
library has to include the yes/no result of the verification and the "d="
value.
What does the verification process entail?
Think of another example, like the socket interface to TCP vs. the TCP
protocol itself. There's what's going on in the protocol stack and then
there's what's going on in the C libraries we actually use.
How about higher layer wrappers and classes for sockets which have
different models, sync vs async for example? <g>
Could be that the language used in RFC4871 and the errata draft don't make
that distinction clear, but I believe that's what we're trying to achieve
here.
I got that impression too when it was first put out. But I think it was
odd since implementators will do what is necessary to make whatever is
necessary. Any API interface and I/O will be defined by the ASSESSOR.
It will define what is needed to do its work. The input is simple - RFC
2822 payload. If you are saying the basic model for an accessor is
BOOL DKIM_ASSESSOR(BOOL DKIM_RESULT, STRING D_TAG_VALUE)
thats cool. But why limit yourself? The process environment data
points are well defined:
envelope fields
payload fields
That prototype is based on the presumption of a ADSP model perhaps or
some other specific unspoken functionality. What the errata should
make clear is WHY and specific 2822 headers and possibly meta data
(envelope) available for accessors at a minimum, may be required. So
make sure its there for API to be developed.
Look at it this way:
In our SMTP framework, we provide two SMTP Rule Base Messaging
processing hooks. One for ENVELOPE processing before reaching DATA: and
one for Payload Processing, run after receiving DATA but before a
response is issued. So we have something like this:
//
// Incoming mail, check the envelope
// What SMTP_ENV_HOOK() does is out of scope
//
ERES = SMTP_ENV_HOOK(IP, HELO, MAILFROM, RCPTTO)
CASE ERES
TEMPORARY_FAILURE: REJECT, SEND 45x
PERMANENT_FAILURE: REJECT, SEND 55x
PASS: SEND 250
END CASE
//
// DATA state reached,
//
PAYLOAD = RECEIVE_PAYLOAD()
//
// Process the payload before DATA response
// Run 2822 payload filters, maybe a bunch of them
//
DRES = SMTP_DATA_HOOK(IP, HELO, MAILFROM, RCPTTO, PAYLOAD)
CASE DRES
TEMPORARY_FAILURE: REJECT, SEND 45x
PERMANENT_FAILURE: REJECT, SEND 55x
PASS: SEND 250, Message Accepted for delivery
END CASE
//
// Wait for QUIT, RSET for complete transaction
// End session
//
So in our hook system, 2822 filters will be written and in general data
points are available for any scripts written.
Now, this is a DYNAMIC SMTP processing model. You also have a POST
SMTP processing model:
//
// Incoming mail, check the envelope
// What SMTP_ENV_HOOK() does is out of scope
//
ERES = SMTP_ENV_HOOK(IP, HELO, MAILFROM, RCPTTO)
CASE ERES
TEMPORARY_FAILURE: REJECT, SEND 45x
PERMANENT_FAILURE: REJECT, SEND 55x
PASS: SEND 250
END CASE
//
// DATA state reached,
//
PAYLOAD = RECEIVE_PAYLOAD()
SEND 250, Message Accepted for delivery
//
// - Wait for QUIT, RSET for complete transaction
// - End session,
// - Queue Payload plus Meta Data (envelope)
// - Maybe signal a DKIM application server
//
So if what you are saying that ACCESSORS need to work POST SMTP, two
data points at a minimum must be available:
- There result of DKIM verification
- The D= tag of the signature
again, thats cool. But its very limiting and can reduce the possible
ASSESSORS that can be designed in the future. If Dave had a specific
ASSESSOR in mind, it should be stated what that is.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html