[Top] [All Lists]

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

2006-06-05 15:56:23

On Jun 5, 2006, at 3:19 PM, william(at) 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.


Asrg mailing list