Submission/SMTP proxy server
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
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.
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
On 1/14/2018 6:18 PM, Stephan Bosch wrote: 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
participants (2)
-
Daniel Miller
-
Stephan Bosch