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