On 23 Jun 2004, John Levine wrote:
What about putting the MARID data in-line in SMTP via an extension?
The obvious problem is that there's no way to tell if the in-line data
is real without making another transaction back to the sender's domain
to check. If we have to use a separate TCP session to fetch a
possible cachable chunk of XML, the right way to do that is with http
and just fetch the policy document. It's defined, it's standard, it's
debugged, it's available, and it works.
I agree with you in general (and with Hadmut), but would point out that
http is also primarily one-key lookup protocol (which has been extended a
lot by means of cgi parameters) and retreiving entire policy document is
not the best idea if we're talking about it being so large that its
better off at the http server.
The best (in my opionion) is to actually work on specifications on new
policy document such that it can be deployed over existing pre-built
protocol. Protocol should be such that it works both over udp and over
tcp (udp preferred if client and server support it) and returns particular
data asked based on multiple lookup keys. My preference is something like
what CRISP, which is XML specification that should go along with BEEP
transport. Other XML possibility which make it easier to deply is one
level up based on SOAP with full protocols being either (or all of) SOAP
over HTTP and SOAP over BEEP and SOAP on UDP. Non-XML protocol option is
LDAP (its supposed to be possible to do it over UDP, but I've never seen
anybody implement it) and possibly something else I don't even know about.
You need a web server to do that, but I would think it'd be a lot
easier to set up a little web server than to deploy a yet to be
invented overloaded extension to SMTP.
Yes, agreed. And this was also already discussed at asrg before.
Alternatively, the sender could put some kind of signed thing into the
message that the recipient could check against a static set of signer
keys, but we have that, too. It's S/MIME.
There is still a need for client to reguarly retrieve CRLs. So we can
never completely remove the necessity to do call-back lookup.