On 04/03/2010 15:47, Timo Sirainen wrote:
On Thu, 2010-03-04 at 10:05 -0500, Charles Marcus wrote:
On 2010-03-04 9:32 AM, Timo Sirainen wrote:
LEMONADE group solved this with IMAP URLAUTH (RFC 4467) and SMTP BURL (RFC 4468) extensions. The idea is basically (copy&pasting from RFCs):
C: RCPT TO:<ron@gryffindor.example.com> S: 250 2.1.5 ron@gryffindor.example.com OK. C: BURL imap://harry@gryffindor.example.com/outbox ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry :internal:91354a473744909de610943775f92038 LAST S: 250 2.5.0 Ok.So after receiving BURL command, SMTP server connects to IMAP server and fetches the message:
But wouldn't this also require the MUA to support the concept of an 'Outbox'?
MUA would have to support both of those URLAUTH and BURL extensions, so that it can register a temporary URL on the IMAP server, then connect to SMTP server and give that URL to BURL command (instead of sending the mail with DATA command).
So from MUA's point of view it's basically the same as before: save to IMAP and after that send via SMTP.
This seems like such a convolution...
Given that the RFC already proposes some changes to the IMAP side then it would seem sensible to get the IMAP server to do the proxy connection to the MTA and deliver. Perhaps a simple case of adding a flag when saving into a folder would mark the message as being required to be sent onwards?
I would guess the reason for the LEMONADE version is that they wanted it to be quite explicit if mail was not immediately able to be sent, rather than creating a bounce (REJECT vs BOUNCE). However, I should imagine a bit more thought about how to implement the IMAP side could allow an extension which handled submission and also gave immediate feedback in the case of obviously non-deliverable mail?
The other pain in the bum about most current clients is that they:
- send the email via smtp
- post the message to the Sent folder
- THEN they DOWNLOAD the message again from the Sent folder!! THIS is craziness!
Ed W