New Dovecot service: SMTP Submission (RFC6409)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

New Dovecot service: SMTP Submission (RFC6409)

Stephan Bosch-2
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.





Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Tanstaafl
This is fantastic Stephan! Especially since I'll soon be rolling a new
Dovecot server to act as a backup for our current Office 365 mail, as
well as to be prepared in case I can ever talk the boss into migrating
back to dovecot (we were using Dovecot for a really long time until he
was convinced by others that we 'had' to be on Office 365).

I'll also be setting up a shiny new VPS for my own private mail server,
to provide better service that I currently get from my shared Dreamhost
account.

But can you confirm...

Would this also be called 'BURL' support?

And will this initial implementation work with current Postfix to
provide the basic Save-To-Sent feature?

I seem to recall there was some minor code required on the Postfix side,
and Wietse seemed to not have a problem implementing it, but had asked
about any IMAP Clients supporting BURL...

If this won't work with current versions of Postfix, maybe you or Timo
or someone could go poke him now that Dovecot supports it?

Anyway, thanks again, I'm really looking forward to being able to do
away with the 'Save-To-Sent' wastage.


On 12/11/2017, 6:14:26 PM, Stephan Bosch <[hidden email]> wrote:

> 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.
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Stephan Bosch-2


Op 12-12-2017 om 15:28 schreef Tanstaafl:

> This is fantastic Stephan! Especially since I'll soon be rolling a new
> Dovecot server to act as a backup for our current Office 365 mail, as
> well as to be prepared in case I can ever talk the boss into migrating
> back to dovecot (we were using Dovecot for a really long time until he
> was convinced by others that we 'had' to be on Office 365).
>
> I'll also be setting up a shiny new VPS for my own private mail server,
> to provide better service that I currently get from my shared Dreamhost
> account.
>
> But can you confirm...
>
> Would this also be called 'BURL' support?
>
> And will this initial implementation work with current Postfix to
> provide the basic Save-To-Sent feature?
>
> I seem to recall there was some minor code required on the Postfix side,
> and Wietse seemed to not have a problem implementing it, but had asked
> about any IMAP Clients supporting BURL...

The thing is: with the Dovecot submission proxy, the availability of
BURL support at Postfix/Exim/Sendmail is irrelevant. Dovecot handles the
full SMTP BURL/IMAP URLAUTH functionality without MTA involvement. That
should make configuration in most cases quite simple. The current
implementation does require that the proxy has direct access to the
user's mailbox for BURL (e.g. by running it on the same host as imap),
but that restriction should be resolved soon, allowing for more complex
setups.

However, keep in mind that for this particular feature we're just
providing the "chicken" as it were. The "egg", i.e. client support, is
still to come. Apart from Trojita (which I think is still not widely
used), I know of no IMAP client supporting BURL/URLAUTH for message
submission. I'd expect to see it first for clients that can truly
benefit; i.e., mobile clients such as K9.

Regards,

Stephan.



> On 12/11/2017, 6:14:26 PM, Stephan Bosch <[hidden email]> wrote:
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Robert Schetterer-2
In reply to this post by Stephan Bosch-2
Am 12.12.2017 um 00:14 schrieb Stephan Bosch:

> 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.
>
>
>
>
>

Hi Stephan, this is extreme cool !


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Tanstaafl
In reply to this post by Stephan Bosch-2
On 12/12/2017, 1:39:08 PM, Stephan Bosch <[hidden email]> wrote:
> However, keep in mind that for this particular feature we're just
> providing the "chicken" as it were. The "egg", i.e. client support, is
> still to come. Apart from Trojita (which I think is still not widely
> used), I know of no IMAP client supporting BURL/URLAUTH for message
> submission. I'd expect to see it first for clients that can truly
> benefit; i.e., mobile clients such as K9.

Oh... bummer...

I thought this was simply going to be an SMTP like service that any SMTP
client could utilize, keeping the BURL/URLAUTH pieces working only
between Dovecot and the MTA it works with. Meaning, instead of
connecting an SMTP service provided by Postfix, you connect to one
provided by Dovecot. I guess there is a good reason it couldn't be made
to work this way.

For obvious reasons, the likelihood that Thunderbird will add
BURL/URLAUTH support anytime in the next few years is probably nonexistent.

:(
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

María Arrea
In reply to this post by Stephan Bosch-2

     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 ?

     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.
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Aki Tuomi-2
In reply to this post by Tanstaafl


On 13.12.2017 21:41, Tanstaafl wrote:

> On 12/12/2017, 1:39:08 PM, Stephan Bosch <[hidden email]> wrote:
>> However, keep in mind that for this particular feature we're just
>> providing the "chicken" as it were. The "egg", i.e. client support, is
>> still to come. Apart from Trojita (which I think is still not widely
>> used), I know of no IMAP client supporting BURL/URLAUTH for message
>> submission. I'd expect to see it first for clients that can truly
>> benefit; i.e., mobile clients such as K9.
> Oh... bummer...
>
> I thought this was simply going to be an SMTP like service that any SMTP
> client could utilize, keeping the BURL/URLAUTH pieces working only
> between Dovecot and the MTA it works with. Meaning, instead of
> connecting an SMTP service provided by Postfix, you connect to one
> provided by Dovecot. I guess there is a good reason it couldn't be made
> to work this way.
>
> For obvious reasons, the likelihood that Thunderbird will add
> BURL/URLAUTH support anytime in the next few years is probably nonexistent.
>
> :(

Actually it's supposed to serve as SMTP-like service as well.

Aki
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Stephan Bosch-2
In reply to this post by María Arrea


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.
>>
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Tanstaafl
In reply to this post by Aki Tuomi-2
On 12/14/2017, 3:03:41 AM, Aki Tuomi <[hidden email]> wrote:

> On 13.12.2017 21:41, Tanstaafl wrote:
>> On 12/12/2017, 1:39:08 PM, Stephan Bosch <[hidden email]> wrote:
>> I thought this was simply going to be an SMTP like service that any SMTP
>> client could utilize, keeping the BURL/URLAUTH pieces working only
>> between Dovecot and the MTA it works with. Meaning, instead of
>> connecting an SMTP service provided by Postfix, you connect to one
>> provided by Dovecot. I guess there is a good reason it couldn't be made
>> to work this way.
>>
>> For obvious reasons, the likelihood that Thunderbird will add
>> BURL/URLAUTH support anytime in the next few years is probably nonexistent.

> Actually it's supposed to serve as SMTP-like service as well.

Meaning... it actually won't require Thunderbird to implement anything
(at least painful) to allow it to make use of it?

<he said in a meek, hopeful voice>

Thanks Aki,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Tanstaafl
One other point.

Adding support for something like this that also requires Clients to add
support for it is just begging for a feature that never gets used.

Stephan, are you sure there is no (fairly simple) way to make this an
SMTP service that any email client that supports SMTP can use?


On 12/14/2017, 10:57:44 AM, Tanstaafl <[hidden email]> wrote:

> On 12/14/2017, 3:03:41 AM, Aki Tuomi <[hidden email]> wrote:
>> On 13.12.2017 21:41, Tanstaafl wrote:
>>> On 12/12/2017, 1:39:08 PM, Stephan Bosch <[hidden email]> wrote:
>>> I thought this was simply going to be an SMTP like service that any SMTP
>>> client could utilize, keeping the BURL/URLAUTH pieces working only
>>> between Dovecot and the MTA it works with. Meaning, instead of
>>> connecting an SMTP service provided by Postfix, you connect to one
>>> provided by Dovecot. I guess there is a good reason it couldn't be made
>>> to work this way.
>>>
>>> For obvious reasons, the likelihood that Thunderbird will add
>>> BURL/URLAUTH support anytime in the next few years is probably nonexistent.
>
>> Actually it's supposed to serve as SMTP-like service as well.
>
> Meaning... it actually won't require Thunderbird to implement anything
> (at least painful) to allow it to make use of it?
>
> <he said in a meek, hopeful voice>
>
> Thanks Aki,
>
> Charles
>

Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Stephan Bosch-2
Op 12/14/2017 om 6:07 PM schreef Tanstaafl:
> One other point.
>
> Adding support for something like this that also requires Clients to add
> support for it is just begging for a feature that never gets used.
>
> Stephan, are you sure there is no (fairly simple) way to make this an
> SMTP service that any email client that supports SMTP can use?

It already is a normal compliant SMTP submission server. Just the BURL
part is something that requires additional client support.

Regards,

Stephan.

>
>
> On 12/14/2017, 10:57:44 AM, Tanstaafl <[hidden email]> wrote:
>> On 12/14/2017, 3:03:41 AM, Aki Tuomi <[hidden email]> wrote:
>>> On 13.12.2017 21:41, Tanstaafl wrote:
>>>> On 12/12/2017, 1:39:08 PM, Stephan Bosch <[hidden email]> wrote:
>>>> I thought this was simply going to be an SMTP like service that any SMTP
>>>> client could utilize, keeping the BURL/URLAUTH pieces working only
>>>> between Dovecot and the MTA it works with. Meaning, instead of
>>>> connecting an SMTP service provided by Postfix, you connect to one
>>>> provided by Dovecot. I guess there is a good reason it couldn't be made
>>>> to work this way.
>>>>
>>>> For obvious reasons, the likelihood that Thunderbird will add
>>>> BURL/URLAUTH support anytime in the next few years is probably nonexistent.
>>> Actually it's supposed to serve as SMTP-like service as well.
>> Meaning... it actually won't require Thunderbird to implement anything
>> (at least painful) to allow it to make use of it?
>>
>> <he said in a meek, hopeful voice>
>>
>> Thanks Aki,
>>
>> Charles
>>

Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Tanstaafl
On 12/16/2017, 5:10:14 AM, Stephan Bosch <[hidden email]> wrote:

> Op 12/14/2017 om 6:07 PM schreef Tanstaafl:
>> One other point.
>>
>> Adding support for something like this that also requires Clients to add
>> support for it is just begging for a feature that never gets used.
>>
>> Stephan, are you sure there is no (fairly simple) way to make this an
>> SMTP service that any email client that supports SMTP can use?
>
> It already is a normal compliant SMTP submission server. Just the BURL
> part is something that requires additional client support.

Ok, well, my ignorance is probably glaring here, but what I meant was,
the make the BURL/URLAUTH pieces strictly between Dovecot and the
backend SMTP server, make it invisible to the Client...
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Tanstaafl
On Sat Dec 16 2017 15:41:25 GMT-0500 (Eastern Standard Time), Tanstaafl
<[hidden email]> wrote:
> Ok, well, my ignorance is probably glaring here, but what I meant was,
> the make the BURL/URLAUTH pieces strictly between Dovecot and the
> backend SMTP server, make it invisible to the Client...

So, I take it the no response to this means that there is no way to put
the BURL/URLAUTH parts such that only server support is needed, nothing
special on the client side?

Bummer, that means it will be a looong time if ever that this feature is
usable.
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Marcus Rueckert-3
On 2017-12-20 14:39, Tanstaafl wrote:

> On Sat Dec 16 2017 15:41:25 GMT-0500 (Eastern Standard Time), Tanstaafl
> <[hidden email]> wrote:
>> Ok, well, my ignorance is probably glaring here, but what I meant was,
>> the make the BURL/URLAUTH pieces strictly between Dovecot and the
>> backend SMTP server, make it invisible to the Client...
>
> So, I take it the no response to this means that there is no way to put
> the BURL/URLAUTH parts such that only server support is needed, nothing
> special on the client side?
>
> Bummer, that means it will be a looong time if ever that this feature
> is
> usable.

Maybe take the time of the year into account and add a bit more waiting
time before drawing conclusions.
People might be busy with other things right now.
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Aki Tuomi-2
In reply to this post by Tanstaafl

> On December 20, 2017 at 4:39 PM Tanstaafl <[hidden email]> wrote:
>
>
> On Sat Dec 16 2017 15:41:25 GMT-0500 (Eastern Standard Time), Tanstaafl
> <[hidden email]> wrote:
> > Ok, well, my ignorance is probably glaring here, but what I meant was,
> > the make the BURL/URLAUTH pieces strictly between Dovecot and the
> > backend SMTP server, make it invisible to the Client...
>
> So, I take it the no response to this means that there is no way to put
> the BURL/URLAUTH parts such that only server support is needed, nothing
> special on the client side?
>
> Bummer, that means it will be a looong time if ever that this feature is
> usable.

Tanstaafl, maybe you could explain what you think the BURL/URLAUTH stuff is for, or do you have some particular use case you would be using it? Client support already is not required, and yes, it might take a long time before clients support it.

Aki
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Tanstaafl
On 12/22/2017, 1:19:45 AM, Aki Tuomi <[hidden email]> wrote:
> Tanstaafl, maybe you could explain what you think the BURL/URLAUTH
> stuff is for, or do you have some particular use case you would be using
> it? Client support already is not required, and yes, it might take a
> long time before clients support it.

Hi Aki,

I would primarily just like to be able to disable 'Save to Sent' action
in Thunderbird for accounts using a backend Dovecot+Postfix server that
supports this.

So, I guess I'm really confused about exactly what this is and how it
will work.

The reason I thought that Client support was required was this:

On 12/12/2017, 1:39:08 PM, Stephan Bosch <[hidden email]> wrote:
> However, keep in mind that for this particular feature we're just
> providing the "chicken" as it were. The "egg", i.e. client support, is
> still to come. Apart from Trojita (which I think is still not widely
> used), I know of no IMAP client supporting BURL/URLAUTH for message
> submission. I'd expect to see it first for clients that can truly
> benefit; i.e., mobile clients such as K9.

So, maybe this doesn't mean what I thought it meant... ?

Thank
Reply | Threaded
Open this post in threaded view
|

Re: New Dovecot service: SMTP Submission (RFC6409)

Timo Sirainen
On 22 Dec 2017, at 15.28, Tanstaafl <[hidden email]> wrote:

>
> On 12/22/2017, 1:19:45 AM, Aki Tuomi <[hidden email]> wrote:
>> Tanstaafl, maybe you could explain what you think the BURL/URLAUTH
>> stuff is for, or do you have some particular use case you would be using
>> it? Client support already is not required, and yes, it might take a
>> long time before clients support it.
>
> Hi Aki,
>
> I would primarily just like to be able to disable 'Save to Sent' action
> in Thunderbird for accounts using a backend Dovecot+Postfix server that
> supports this.
>
> So, I guess I'm really confused about exactly what this is and how it
> will work.

I guess we can support this at some point. At least once we add Sieve support for outgoing submission mails it should be possible to use fileinto "Sent" command in them. But this is kind of a special use case which can't be automatically configured and isn't implemented by all clients. So it might work for you, but not generally for everyone.

> The reason I thought that Client support was required was this:
>
> On 12/12/2017, 1:39:08 PM, Stephan Bosch <[hidden email]> wrote:
>> However, keep in mind that for this particular feature we're just
>> providing the "chicken" as it were. The "egg", i.e. client support, is
>> still to come. Apart from Trojita (which I think is still not widely
>> used), I know of no IMAP client supporting BURL/URLAUTH for message
>> submission. I'd expect to see it first for clients that can truly
>> benefit; i.e., mobile clients such as K9.
>
> So, maybe this doesn't mean what I thought it meant... ?

This just means that the BURL/URLAUTH extensions aren't really used by existing mail clients currently. But now that Dovecot supports it, perhaps some clients will start implementing them. You can still use the submission server without the BURL/URLAUTH extensions of course, just means that the benefits are a bit less (mainly could make the SMTP AUTH configuration easier).