On Fri, Feb 17, 2012 at 10:00:07AM +1300, Adrien de Croy wrote:
>
>
> 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.
Rarely. I don't even know an IMAP client which supports doing that.
It's not like SMTP would disappear if you need something more complex.
> >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
Simple, heh.
> 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.
Definitely agree that
Client <-----> IMAP ------> SMTP
is much simpler dataflow than
+--------------------+ +--------------+
| | <------------ | |
| MUA (M) | | IMAPv4Rev1 |
| | | Server |
| | ------------> | (Server I) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |----------------------> | SMTP |
| | Submit |
|-----------------------------| Server |
| (Server S) |
+--------------+
Half as many communication channels.
Bron.
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
