ietf-asrg
[Top] [All Lists]

Re: [Asrg] pre-rfc thought balloon: ESMTP DATAFIRST

2006-06-05 15:37:20

On Mon, 5 Jun 2006, Douglas Otis wrote:


On Jun 5, 2006, at 2:29 PM, David Nicol wrote:


The new ESMTP extension is tentatively called "DATAFIRST"

When a server identifies itself as supporting the DATAFIRST extension,
the SMTP transaction may be re-ordered from MAIL FROM, RCPT TO, DATA
to MAIL FROM, DATA, RCPT TO

This would the commit servers into accepting data without being provided any clue the sender knows who would be available to receive the information. A better system would seem to be a call-back mode for the data.

A new ESMTP extension DATA-CALLBACK.

The current DATA phase becomes a the header only portion of the message. A new header also provides a token used by the MUA to retrieve the rest of the data. The recipient could check the DKIM signatures before deciding whether the signing domain had a suitable reputation before even requesting the information. The bulk of the message would be held by the sender rather than by the intermediary for the recipient.

The above is main reason I worked on META Signatures. I specifically wanted signature in email header that could reference email data (which may not necessarily be present as part of the message) and where such signature can still be confirmed. EDigest (to be renamed Transmission-Digest in the next draft release) implements this all by allowing "u" as URL reference to actual digest data context and META obviously only signs header data fields. I believe I mentioned this on ASRG once before and published couple drafts 1-2 years ago. Some of the things I envisioned was doing im2000-like system entirely within context of SMTP with header becoming email service notification carrying information on where actual data can be retrieved as well as carrying authentication/accreditation (stamps-like) data within the signature (or within signed data header). The forwarding in this system also works perfectly well and does not make forwarder responsible for the message (because forwarder would simply send the header and let the final recipient retrieve the message from the original location) and similarly for mail lists (which could choose to forward the message adding reference to additional mime context for mail list footer). The support for data retrieval was supposed to be carried by means of SMTP extensions with server that has to send it further but next hop does not support it then has to retrieve the data, however if at later hop server supports retrieval it could just drop the body again (and this all has no
problems as far as signature confirmation!).

DKIM however can not be used for this - this is the signature that
does not separate header from email body properly and forces the
signature to be for entirely data segment rather then based on
actual context part(s) and only allows to verify the signature
once data has been retrieved.

If somebody is interested I have whole bunch of notes on all this - however considering what I've seen I do not see that internet
community (and more specifically email industry) would be willing
to implement all necessary extensions and I think new email protocol
is better way to go to really fix SMTP rather then several additional patches which are hard to fit within current infrastructure.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg