[Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.

[Stephan Bosch]

On 5/9/2013 6:05 PM, Charles Marcus wrote:
> On 2013-05-09 10:35 AM, Stephan Bosch <stephan at 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.