Jon Callas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
There's nothing wrong with a receiver looking at (e.g.) Yahoo!'s i=
and noting that it is exactly an email address and processing it. But
if Yahoo! changes to using a hex string that is the internal user ID,
the receiver must cope.
Jon, good points.
Shouldn't the errata simply say the i= is Identity Assessor defined
and the only prerequisites is the RHS @domain syntax.
i = opaque @ rfc4871.defined
I think must is made about "identity assessors", perhaps maybe modeled
or framed around existing trust based services and it is they that is
requiring the i= input. So I think the errata is trying to say:
"Look, we i= know its not well undefined, we see it as opaque.
But regardless of it being opaque or not, it MUST be passed
to Identity Assessors."
I think this is short changing that can be passed to any augmented,
add-on technology, in-house or otherwise.
I think maybe a simple solution would to state something to the effect:
Receivers "SHOULD" make the following information available
for potential integrated solutions:
- DKIM-Signature Headers
- If multiple, only one valid is required?
- DKIM result
- Possible Authentication-Results Headers
- Additional Headers as defined by Identity Assessors the
implementation wishes to support.
This is important for systems that happen to transform final
destination mail storage that is not exactly 2822.
Here is an example model as I see it:
For SMTP, lets look at the SMTP process model data points:
CIP = connection IP address
CDN = client domain name (EHLO/HELO)
RP = return path (MAIL FROM)
FP = forwarding path (RCPT TO)
PL = 2822 Payload (DATA)
For the sake of illustration, SPF has to his process model:
SPF_RESULT = SPF(CIP, CDN, RP)
That is all SPF needs to produce a result.
Like wise, DKIM-base can be modeled as:
(1) DKIM_RESULT = DKIM(PL)
Why only PL?
Per specs, this is minimum requirement for DKIM-base. It means DKIM
can be used in in-transient SMTP sessions or POST SMTP operations or
even non-SMTP transport environments. All it really needs is the 2822
payload. The DKIM verification function is not limited to being
called during the SMTP session. The mail (payload) can be accepted by
SMTP to be processed in a delayed fashion.
In either case,
What is DKIM_RESULT?
Where it is saved?
This is important because it will help the design for other integrated
DKIM processors or as Dave calls this - Identity Accessors. I call
them "Batteries." <g>
For an in-house integrated system, they can solved this more easily.
They have control of all I/O and storage. Its all internal.
But the design for a generic service offering is different. So it is
they that need to define what is required. So the question becomes:
(2) OVERALL_RESULT = DKIM_ACCESSOR( ??? )
What is passed to the DKIM_ACCESSOR() ?
That depends on the add-on application. But I think Dave' errata is
saying, d=/i= must be passed to Identity Accessors.
Ok fine, but I ask why?
Is this because of some perceived or existing trusted-service out
there and that is what they needs to function?
Why not other headers? Why not the Authentication-Results? Why can't
that be the passed?
What not passed SPF results or SMTP process state variables?
This is all important because it helps define the API, storage
methods, and the designs for making these "call outs".
So this is why I think we should basically state what are the formal
DKIM-BASE processing outputs that "SHOULD" be stored, regardless of
what Identity Assessors.
The pool of data that is general available will be:
- SMTP Process Variables
CIP = connection IP address
CDN = client domain name (EHLO/HELO)
RP = return path (MAIL FROM)
FP = forwarding path (RCPT TO)
PL = 2822 Payload (DATA)
- DKIM Verification
DKIM_RESULT
DKIM-Signature Header (from PL)
Authentication-Results (added DKIM() verifier)
In my opinion, it is the identify assessors that need to cope and live
with this reality of whats possible. It it the IA that needs to
define what it wants for input.
I don't think the DKIM specification should be changed to say only the
I= is required to be passed.
Finally, just consider John's Levine VBR system. Here, its process
model would be:
VBR_RESULT = VBR(DKIM_RESULT, VBR_HEADER)
So by stating the the DKIM-BASE system should make the Payload header
available for potential higher level add-ons, at at minimum, it SHOULD
consider storing or making available the 2822 message block.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html