Submission/SMTP proxy server

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

Submission/SMTP proxy server

Daniel Miller
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 submitted via port 25.

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?

--
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Submission/SMTP proxy server

Stephan Bosch-2
Op 1/12/2018 om 8:18 PM schreef Daniel Miller:
> 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?

No. This is a proxy that adds functionality that is normally either
rather difficult to achieve 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 talking to the client directly, so it
would be in front of it all. So, I'd expect Dovecot<->ASSP<->MTA.
Dovecot would in that case take care of the authentication.

Regards,

Stephan.


Reply | Threaded
Open this post in threaded view
|

Re: Submission/SMTP proxy server

Daniel Miller
On 1/14/2018 6:18 PM, Stephan Bosch wrote:
> Op 1/12/2018 om 8:18 PM schreef Daniel Miller:
>> 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?
> No. This is a proxy that adds functionality that is normally either
> rather difficult to achieve or not implemented for common SMTP software
> (e.g. BURL).
My question was probably poorly phrased.  Based on the thread "New
Dovecot service: SMTP Submission (RFC6409)" of last month it appears
that BURL & URLAUTH are implemented in this proxy - but no clients
presently support them?  And the particular use case of directly placing
the mail into a "Sent" folder is not presently available (though
hopefully soon!)?  So again, at this time, what would I use this service
for besides testing it in advance of future development?
>
>> 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.
Understood.  Just wanted to verify.
>
>> 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 talking to the client directly, so it
> would be in front of it all. So, I'd expect Dovecot<->ASSP<->MTA.
> Dovecot would in that case take care of the authentication.
That would work with trusted networks - but when using various services
(including ASSP) to limit connections by IP's (particularly to combat
brute-forcing attacks) I would think Dovecot should be within the
protection and not directly exposed.  Or are there other security
features built-in that I'm not aware of?

--
Daniel