On 17/02/2012 5:40 a.m., Tony Finch wrote:
Adrien de Croy<[email protected]> wrote:
With XSEND, you upload the message to IMAP first, then you say:
TAG XSEND UID
how do you provide the SMTP forward path? Is that scraped from the headers?
That's the right thing to do. You also need to do BCC: processing.
(sendmail -t does the right thing.)
I think the guys that developed SMTP would disagree with you. The
reason the envelope is even specified in SMTP rather than the receiver
simply scraping them out of the message, is that sometimes you need to
deliver a message somewhere other than the To: / bcc: headers.
The rationale for BURL is that there is more to the SMTP envelope than
just the sender and recipient addresses - in particular there are the DSN
attributes. There's a somewhat ugly and ill-defined split between
information for MTA processing (in the envelope) and information for MUA
processing (in the headers - see MDN for example). But in fact MTAs do
header processing too, so there no practical advantage to ESMTP envelope
extensions and a lot of complexity disadvantage.
There are a few envelope extensions: DSN, future release, message
tracking, CONNEG and CONPERM facsimile media conversion, and 8BITMIME +
BINARYMIME. If you want to eliminate BURL you need to either define a
mapping from headers to the extension parameters that you want to support,
or embed ESMTP inside IMAP.
yep, I'd definitely go for embedding SMTP into IMAP... since
a) SMTP is a trivially simple protocol for an IMAP server to use to
submit a message on behalf, whereas an IMAP client is much more complicated,
b) take a look at the security implications in the BURL RFC.
Adrien
Tony.
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5