Eliot Lear wrote:
John,
I want to not constrain the document to the point where it does not
reflect the complexities of the reality in which we find ourselves.
You've stated that reality below, by the way. A very simple decision
tree one could easily envision is something along the following:
[Sender]---->[Signer]-->[...]--->[verifier]-->[DBLs]--->...
...-> [pass]-->[dkim|spf|other]-->[assessor]-->[...]-->[mda]
Or, put in other terms:
[Outlook]---->[Exchange]-->[...]--->[sendmail]-->[RBLs]--->...
...-> [pass]-->[milters]-->[spamassassin]---->[mda]
These diagrams aren't perfect, but I think the illustrate one approach
we see in the wild.
It has to be generalized which I believe is one of a fundamental
philosophical differences between Developers vs Administrators:
Model 1:
Sender -> SMTP <--> DATA <--> DKIM/ACCESSOR(S)
Model 2:
Sender -> SMTP --> accept -> post smtp --> DKIM/ACCESSOR(S)
In model 1, all process variables are readable to the dynamic DATA
shims, hooks, processed online in real time during the SMTP session.
Rejection here provides feedback and satisfies all technical (and
legal) requirements (practices). If one implements ADSP, the term
discardable is more of a rejection.
In model 2, we have the post smtp (accept first) framework where how
data is passed to the DKIM/ACCESSORS depends on the storage framework
of the backend. Here you can have, for example:
- 1 file per message in a RFC 822/2822/5322 format
- can come with index and/or meta files.
- some proprietary or open spec database,
- SQL, SDK/API I/O, RPC client/server, etc.
This model 2 is more flexible for mail bot scripting, especially if
the storage is raw in RFC format. This is also where lost of
controls of what is stripped, added, signed or not signed. Just as
note, ours is a proprietary database with a RPC client/server API, so
we have full control of what "accessors" will have access and they
must adhere to our storage format. This is why to open to the door
for 3rd party developers, we use the DATA approach which gives them
access to the temporary RFC storage prior to full acceptance and final
database storage.
The problem model 2 presents today is the ACCEPT/BOUNCE RFC 5321
requirement dilemma. Thus ADSP needs terms like DISCARDABLE to make
it acceptable to just drop and discard messages - not like a SMTP
REJECT which has notifications designs built in.
Anyway, the point is until we recognize the different models here and
how depending on the model, an approach is taken, with one side
(model 2) thinking the other model 1 doesn't exist, will never
significantly exist (even when all indications show this is the
direction with more powerful machines) or that they believe that all
storage is 1 way only, then it will have to get consensus with across
the board considerations.
This is why I agree with you, that we should not lock in what
information is preserved for accessors because we don't even know what
these accessors are and/or how and when they are going to be processed.
We need to generalized this protocol so that it fits both dynamic SMTP
and post SMTP models.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html