Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

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<[e-mail]>  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.