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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg