search for: rfc6409

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

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

On 12/12/2017, 1:39:08 PM, Stephan Bosch <stephan at rename-it.nl> 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

On 12/14/2017, 3:03:41 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > On 13.12.2017 21:41, Tanstaafl wrote: >> On 12/12/2017, 1:39:08 PM, Stephan Bosch <stephan at rename-it.nl> 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

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

On Sat Dec 16 2017 15:41:25 GMT-0500 (Eastern Standard Time), Tanstaafl <tanstaafl at libertytrek.org> 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

On 12/22/2017, 1:19:45 AM, Aki Tuomi <aki.tuomi at dovecot.fi> 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

On 12/16/2017, 5:10:14 AM, Stephan Bosch <stephan at rename-it.nl> 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

On 13.12.2017 21:41, Tanstaafl wrote: > On 12/12/2017, 1:39:08 PM, Stephan Bosch <stephan at rename-it.nl> 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

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 <tanstaafl at libertytrek.org> wrote: > On 12/14/2017,

> On December 20, 2017 at 4:39 PM Tanstaafl <tanstaafl at libertytrek.org> wrote: > > > On Sat Dec 16 2017 15:41:25 GMT-0500 (Eastern Standard Time), Tanstaafl > <tanstaafl at libertytrek.org> 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 > >

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

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

Sorry if this seems elementary - but a question on implementation/usage/purpose of this.? My understanding is at this time the SMTP proxy server is only that - it does not implement any further functionality.? So its availability now is purely for testing purposes.? Is that accurate? I secondly assume that this intended for trusted clients only - so this is not intended for processing email

...;; Fri, 19 Oct 2018 18:50:40 +0100 RFC 5321 specifies that the ?from? MUST exist but only specifies that the content SHOULD be the source host. (Assuming that Submission is ?an SMTP environment?. RFC 6409 makes some provision for header rewriting to hide machine names. https://tools.ietf.org/html/rfc6409#section-8.8 ) https://tools.ietf.org/html/rfc5321#section-4.4 The FROM clause, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined fro...

...chieve or not implemented for common SMTP software (e.g. BURL). > I secondly assume that this intended for trusted clients only - so > this is not intended for processing email submitted via port 25. It is a submission service. Port 25 is for mail transport. Read https://tools.ietf.org/html/rfc6409 for more details about the difference between the two. > And thirdly - if a separate firewall/anti-spam/virus/authentication > service is run outside of the MTA (like ASSP) then the Dovecot proxy > should be inserted between that and the final MTA? Dovecot submission is meant to be talki...

...17.119.239.130 X-SA-Exim-Mail-From: sender at rename-it.nl X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sogo.guto.nl X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 ?autolearn=ham version=3.3.2, No Subject: Re: New Dovecot service: SMTP Submission (RFC6409) X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on sogo.guto.nl) X-BeenThere: dovecot at dovecot.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Dovecot Mailing List <dovecot.dovecot.org> List-Unsubscribe: <https://dovecot.org/mailman/optio...