Re: [Asrg] pre-rfc thought balloon: ESMTP DATA-CALLBACK (was ESMTP DATAFIRST)

[Douglas Otis <dotis at mail-abuse.org>]

On Jun 5, 2006, at 3:19 PM, william(at)elan.net wrote:
> On Mon, 5 Jun 2006, Douglas Otis wrote:
> > 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.
>
>
> 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.

Actually, with the inclusion of the bh= header, the body can be  
checked separately with DKIM.  The just the hash of the body is signed.


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

If email becomes more reputation based, a call-back mechanism should  
eliminate much of the risks associated with auto-executed malware.   
It would also isolate the ESP from being responsible for filtering  
this part of the message, which is why this was seen as relating to a  
filtering overhead concern.  This mechanism could also support point  
to point TLS protections, keeping email confidential.  The data must  
still match that of a sha-256 hash and does not require the message  
to be encrypted by the application.

-Doug

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