New Dovecot service: SMTP Submission (RFC6409)

[Stephan Bosch]

Op 14-12-2017 om 8:26 schreef María Arrea:
>
>     Stephan, thank you very much for your hard work. I want to ask 
> your opinion about jmap ( http://jmap.io/ ) , do you think is a viable 
> alternative to current IMAP + MSA ?
>

Difficult to tell at this point, as It is not finished yet. It all 
depends on whether people will want to implement it. Still, 
technology-wise I think it is solid and, as far as I know now, we'll be 
implementing it at some point.

Regards,

Stephan.

> Regards
>
>     María
>
> El 12/12/17 a las 00:14, Stephan Bosch escribió:
>> Hi,
>>
>> As some of you know, I started implementing the SMTP submission proxy a
>> few years ago. It acts as a front-end for any MTA, adding the necessary
>> functionality for an SMTP submission service, also known as a Mail
>> Submission Agent (MSA) (https://tools.ietf.org/html/rfc6409). The main
>> reason I created this, back then, was implementing the BURL capability
>> (https://tools.ietf.org/html/rfc4468). The main application of that
>> capability -- together with IMAP URLAUTH -- is avoiding a duplicate
>> upload of submitted e-mail messages; normally the message is both sent
>> through SMTP and uploaded to the "Sent" folder through IMAP. Using BURL,
>> the client can first upload the message to IMAP and then use BURL to
>> make the SMTP server fetch the message from IMAP for submission, thereby
>> avoiding a second upload. Apart from BURL, the submission proxy service
>> also adds the required AUTH support, avoiding the need to configure the
>> MTA for SASL authentication. More SMTP capabilities like CHUNKING and
>> SIZE are supported, without requiring the backend MTA supporting these
>> extensions. Other capabilities like DSN currently require support from
>> the backend/relay MTA.
>>
>> At this point, the submission proxy is still pretty basic. However, it
>> will provide a basis for adding all kinds of functionality in the (not
>> so distant) future. For the first time, it will be possible to act upon
>> message submission, rather than only message retrieval; e.g. plugins can
>> be devised that process outgoing messages somehow. Examples of the
>> things we could do are adding Sieve filtering support for outgoing
>> messages, or implicitly storing submitted messages to the Sent folder.
>> Once a plugin API is devised, you can create your own plugins.
>>
>> The reason I send this message now, is that this code is finally merged
>> into the Dovecot master repository. This means that it is part of the
>> upcoming 2.3 release. Now that it is merged, you can install and test it
>> from Github if you like. Feedback is of course appreciated. The
>> documentation is still pretty sparse, but there is currently not much to
>> configure. Just add "submission" to the protocols and configure the
>> relay MTA server. The configuration is currently only documented in the
>> example configuration in doc/example-config/conf.d/20-submission.conf.
>> The submission service is a login service, just like IMAP, POP3 and
>> ManageSieve, so clients are required to authenticate. The same
>> authentication configuration will also apply to submission, unless
>> you're doing protocol-specific things, in which case you may need to
>> amend your configuration for the new protocol. BURL support requires a
>> working IMAP URLAUTH implementation.
>>
>> I've updated the automated Xi Debian package builder to create an
>> additional dovecot-submissiond package. So, if you're using the Xi
>> packages, you only need to install that package and configure the 
>> relay MTA.
>>
>> Regards,
>>
>> Stephan.
>>
>>
>>
>>
>>
>