On 5/9/2013 6:05 PM, Charles Marcus wrote:
On 2013-05-09 10:35 AM, Stephan Bosch stephan@rename-it.nl wrote:
Currently, I'm building an SMTP submission proxy server.
Can you elaborate on this?
It basically acts as a front-end to your normal MTA. First of all, it provides a convenient way to add SMTP AUTH support to any MTA. But the main goal for this project is to implement an SMTP submission server with full support for the LEMONADE profile (https://tools.ietf.org/html/rfc4550). It acts as a proxy server, so it doesn't queue anything; once the client sees a success reply for the message submission, it is already accepted in the actual MTA queue.
For authentication it uses the normal Dovecot login strategy. This means that after authentication, it can run with the user's privileges and access the user's mail storage directly. However, I also plan to provide support for running it as a completely unprivileged service.
Does this mean for example, that we could use dovecot as our submission server ...
Yes.
... and auto-save-to-sent, avoiding the overhead of the 'Copy to Sent' behavior we are currently forced to use where a message is first uploaded when it is sent, then again when it is saved to the sent folder?
Depends a bit on what you have in mind. The LEMONADE profile has a forward-without-download scheme for this, using the SMTP BURL extension (https://tools.ietf.org/html/rfc4468) and IMAP CATENATE (https://tools.ietf.org/html/rfc4469) and URLAUTH (https://tools.ietf.org/html/rfc4467). Using CATENATE, the client can combine existing message parts with new text to compose a new message. Using SMTP BURL and IMAP URLAUTH, the SMTP server can access that message directly from the IMAP server without the need for the client to download it first.
Some more direct approach is also possible, e.g. let the submission server store the message in the Sent folder implicitly (as Google apparently does). This has a few problems though, mainly that the mail client will have to be configured correctly not to store an additional copy of its own. Unfortunately, there is no standardized method of signalling this from server to client. Google probably filters out the duplicates, we don't really know. Also, which folder does the user use as Sent folder? We could use the IMAP SPECIAL-USE (https://www.ietf.org/rfc/rfc6154.txt) extension to find out. Anyway, adding support for implicitly storing sent messages in the \Sent folder should be easy enough, but it is not a fool-proof solution. Timo was discussing this a while back on the SMTP mailinglist, but people there weren't too enthusiastic about standardizing a feature like this so far.
This would be awesome, as we deal with a lot of large attachments, and when people are working from home, it can take many many seconds (even a minute or so for very large attachments depending on their internet connection speed) to send, and then it has to do it all over again to save to sent.
The LEMONADE profile is rather elaborate and not many clients or servers support it yet. I'm hoping that by providing a chicken, more eggs will follow soon.
To provide some sort of solution for the short term, I guess I'll just add an optional auto-save-to-sent feature. When the submission service has direct access to the user's mail storage, that is trivial to implement. However, if the submission service is unprivileged, that will be a little more difficult. Probably, in that case I'll make it use a special support service to perform the actual delivery to the sent folder. Any suggestions are welcome.
Regards,
Stephan.