> In the mean time, the authors may want to enforce strict sanity > checks on IMAP server output such as the reply payload length, and > also make sure that their vstream_limit code behaves when reads > are alternated with writes (either refuse to allow read/write/read, > or enforce the limit as promised).
OK > One question I have is why would anyone send an email message that > is 100% identical to a message that is already sitting in an IMAP > store? Because the message in the IMAP server is brand-new, having just been composed by the user. For instance: 1. As the user composes a new message, the MUA saves the new message in the IMAP "Drafts" mailbox, possibly by using CATENATE (RFC 4469) and URLAUTH (RFC 4467) to compose it out of parts of other messages already on the IMAP server. 2. The MUA connects to Postfix and uses a BURL command instead of a DATA command. 3. Postfix connects to the IMAP server to retrieve the body of the message from the Drafts mailbox. 4. After receiving a positive response from Postfix, the MUA moves the message from the Drafts mailbox to the Sent mailbox. Notice that in this example, the body of the message is pushed out of the client only once (to the IMAP server). Without BURL, it is pushed at least twice (once to Postfix and a second time to the Sent mailbox, and possibly also to the Drafts mailbox for auto-save during composition). RFC 4550 section 2 explains it better. On bandwidth-constrained devices such an optimization can have a significant effect. > Why is there a problem with sending mail to the SMTP server directly, > instead of taking an indirect route via an IMAP server? There is no such problem. The problem is the double- or triple-transmission that is currently needed: once to SMTP, again to IMAP (for saving a copy in Sent, and auto-save to Drafts). > explain why sending to an IMAP server is > faster than sending that same message to an SMTP server. It isn't, except for CATENATE (RFC 4469) and URLAUTH (RFC 4467). With these one can forward a huge attachment using minimal bandwidth. Then once the new huge message is complete, fast server-to-server communication (i.e., BURL) can be used to send it. The example in RFC 4550 section 2.4.1 shows how an arbitrarily-large attachment can be forwarded while using only a couple KB of bandwidth for mail headers, MIME headers, and plain-text comments. The savings is in the reduction of bandwidth between the client and the server -- both servers, IMAP and SMTP. The benefit is in being able to forward a multi-megabyte document from a low-network-bandwidth, high-network-latency device using only 2-3 TCP packets rather than thousands.
