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

["william(at)elan.net" <william at elan.net>]

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.net

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg