List, we're migrating to 2.2 from a 1.x version. There has been mention from time to time of a dovecot SMTP submission server. Last I saw was Timo suggesting this would be a 2.3 feature, but that there was already a 'basic' capability in 2.2 that, more or less, merely provided a secured/authorised SMTP submission. I haven't found anything about this in the wiki, but the feature is of interest to us. I would like to *not* have our MTA capable of being exploited as a relay (it isn't, at the moment) whereas users are logging into our dovecot from offsite using imaps with passwords. While moving to 2.2, I'd like to try to use a secure SMTP submission *separate* from the MTA so that that software, with whatever vulnerabilities or weaknesses it might have, remained locked down and could not relay, if at all possible.
(Imaps with passwords means the login details are not transmitted in cleartext and, so, leak no security to an observer of the communications channel. Doubtless there are other weaknesses somewhere but, at least, when using hotel wifi, for example, there is little chance of revealing login details to a packet sniffer. It won't be perfect, there are probably other vulnerabilities, not least in the underlying OSs at each end, but the connection - which is a serious vulnerability in many places - will be as good as is practical to make it.)
So, is there some kind of SMTP submission service for a logged in dovecot user, and how would a client make use of that? Is it possible to setup 2.2.15 for this? And, crucially, would the connections between the client (eg at a hotel in some unreliable location) be encrypted right from the start, not using STARTTLS, as is the case in imaps? And, just to be really demanding, could we configure its use on a non-standard port?
regards, Ron
to make it short
- dovecot is no MTA submission server
- if you find a security issue in postfix running on 587 over TLS cry out loud
- dovecot offers a SASL provider for postfix submission
that's it and if you think that combination is not secure enough pull the network cables
Am 16.11.2014 um 00:03 schrieb Ron Leach:
List, we're migrating to 2.2 from a 1.x version. There has been mention from time to time of a dovecot SMTP submission server. Last I saw was Timo suggesting this would be a 2.3 feature, but that there was already a 'basic' capability in 2.2 that, more or less, merely provided a secured/authorised SMTP submission. I haven't found anything about this in the wiki, but the feature is of interest to us. I would like to *not* have our MTA capable of being exploited as a relay (it isn't, at the moment) whereas users are logging into our dovecot from offsite using imaps with passwords. While moving to 2.2, I'd like to try to use a secure SMTP submission *separate* from the MTA so that that software, with whatever vulnerabilities or weaknesses it might have, remained locked down and could not relay, if at all possible.
(Imaps with passwords means the login details are not transmitted in cleartext and, so, leak no security to an observer of the communications channel. Doubtless there are other weaknesses somewhere but, at least, when using hotel wifi, for example, there is little chance of revealing login details to a packet sniffer. It won't be perfect, there are probably other vulnerabilities, not least in the underlying OSs at each end, but the connection - which is a serious vulnerability in many places - will be as good as is practical to make it.)
So, is there some kind of SMTP submission service for a logged in dovecot user, and how would a client make use of that? Is it possible to setup 2.2.15 for this? And, crucially, would the connections between the client (eg at a hotel in some unreliable location) be encrypted right from the start, not using STARTTLS, as is the case in imaps? And, just to be really demanding, could we configure its use on a non-standard port?
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
to make it short
- dovecot is no MTA submission server
submission server in dovecot is on its way ( my last info )
- if you find a security issue in postfix running on 587 over TLS cry out loud
- dovecot offers a SASL provider for postfix submission
yeah
that's it and if you think that combination is not secure enough pull the network cables
Am 16.11.2014 um 00:03 schrieb Ron Leach:
List, we're migrating to 2.2 from a 1.x version. There has been mention from time to time of a dovecot SMTP submission server. Last I saw was Timo suggesting this would be a 2.3 feature, but that there was already a 'basic' capability in 2.2 that, more or less, merely provided a secured/authorised SMTP submission. I haven't found anything about this in the wiki, but the feature is of interest to us. I would like to *not* have our MTA capable of being exploited as a relay (it isn't, at the moment) whereas users are logging into our dovecot from offsite using imaps with passwords. While moving to 2.2, I'd like to try to use a secure SMTP submission *separate* from the MTA so that that software, with whatever vulnerabilities or weaknesses it might have, remained locked down and could not relay, if at all possible.
(Imaps with passwords means the login details are not transmitted in cleartext and, so, leak no security to an observer of the communications channel. Doubtless there are other weaknesses somewhere but, at least, when using hotel wifi, for example, there is little chance of revealing login details to a packet sniffer. It won't be perfect, there are probably other vulnerabilities, not least in the underlying OSs at each end, but the connection - which is a serious vulnerability in many places - will be as good as is practical to make it.)
So, is there some kind of SMTP submission service for a logged in dovecot user, and how would a client make use of that? Is it possible to setup 2.2.15 for this? And, crucially, would the connections between the client (eg at a hotel in some unreliable location) be encrypted right from the start, not using STARTTLS, as is the case in imaps? And, just to be really demanding, could we configure its use on a non-standard port?
i dont see your point...
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
On 11/16/14 02:24, Robert Schetterer wrote:
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
to make it short
- dovecot is no MTA submission server
submission server in dovecot is on its way ( my last info )
- if you find a security issue in postfix running on 587 over TLS cry out loud
- dovecot offers a SASL provider for postfix submission
yeah
that's it and if you think that combination is not secure enough pull the network cables
Am 16.11.2014 um 00:03 schrieb Ron Leach:
List, we're migrating to 2.2 from a 1.x version. There has been mention from time to time of a dovecot SMTP submission server. Last I saw was Timo suggesting this would be a 2.3 feature, but that there was already a 'basic' capability in 2.2 that, more or less, merely provided a secured/authorised SMTP submission. I haven't found anything about this in the wiki, but the feature is of interest to us. I would like to *not* have our MTA capable of being exploited as a relay (it isn't, at the moment) whereas users are logging into our dovecot from offsite using imaps with passwords. While moving to 2.2, I'd like to try to use a secure SMTP submission *separate* from the MTA so that that software, with whatever vulnerabilities or weaknesses it might have, remained locked down and could not relay, if at all possible.
(Imaps with passwords means the login details are not transmitted in cleartext and, so, leak no security to an observer of the communications channel. Doubtless there are other weaknesses somewhere but, at least, when using hotel wifi, for example, there is little chance of revealing login details to a packet sniffer. It won't be perfect, there are probably other vulnerabilities, not least in the underlying OSs at each end, but the connection - which is a serious vulnerability in many places - will be as good as is practical to make it.)
So, is there some kind of SMTP submission service for a logged in dovecot user, and how would a client make use of that? Is it possible to setup 2.2.15 for this? And, crucially, would the connections between the client (eg at a hotel in some unreliable location) be encrypted right from the start, not using STARTTLS, as is the case in imaps? And, just to be really demanding, could we configure its use on a non-standard port?
i dont see your point...
There isn't.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On 16/11/2014 07:24, Robert Schetterer wrote (re-ordered):
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
- if you find a security issue in postfix running on 587 over TLS cry out loud
I'm thinking beyond that; I want to get to the position that when there is an issue in the MTA, our systems are less exposed than they might otherwise be. It's not about the MTA.
that's it and if you think that combination is not secure enough pull the network cables
That's pretty much what we have at the moment, but we need to be able to submit from offsite, and I'm keen to implement that together with our migration to 2.2. Of course offsite submission is easy, but in our experience that is also vulnerable.
Am 16.11.2014 um 00:03 schrieb Ron Leach:
There has been mention from time to time of a dovecot SMTP submission server. Last I saw was Timo suggesting this would be a 2.3 feature, but that there was already a 'basic' capability in 2.2 that, more or less, merely provided a secured/authorised SMTP submission. I would like to *not* have our MTA capable of being exploited as a relay (it isn't, at the moment) whereas users are logging into our dovecot from offsite using imaps with passwords. [snip most of background]
So, is there some kind of SMTP submission service for a logged in dovecot user, and how would a client make use of that? Is it possible to setup 2.2.15 for this? And, crucially, would the connections between the client (eg at a hotel in some unreliable location) be encrypted right from the start, not using STARTTLS, as is the case in imaps? And, just to be really demanding, could we configure its use on a non-standard port?
i dont see your point...
I wondered whether the background might hinder an answer but it normally helps, I'm sorry it was unclear, and especially so since you took the time to read it.
Let me list the approach we'd prefer:
(i) MTA open on port 25 for inbound email.
(ii) MTA not open on any other port, because (for example, our) MTAs are constantly faced on port 25 with password attacks, malformed packets, malformed messages that contain scripts, and malformed protocol sequences; all these show up in the logs. In the past, at least one of those succeeded. We have a saying: 'once bitten, twice shy'. So, now I would prefer that any MTA we use (that is capable of outbound messaging) be *not* capable of relaying from any inbound SMTP protocol. (Because inbound SMTP is the focus of so much attack. Though current versions of MTAs are conscientiously engineered to be as secure as is practical, they will be broken. They may even be broken through no action or omission of their own designers; you may have seen recent discussions on a cryptography list [1] where the optimising option in a popular tool chain resulted in some protection algorithm being rendered ineffective. But that's just one example of a long line of subsequently revealed security weaknesses, so architectures based on assumptions that the implementations are now perfect and that they will remain perfect even though the toolchains, the OSs, the crypto routines and the attacks evolve would be ill-founded. And attacks don't become weaker, they constantly improve.)
(iii) Users who are logged in to Dovecot (ie, authorised by Dovecot, so not authorised by any software which is subject of attack and which will be compromised from time to time) able to submit outbound messages through Dovecot on the internal network to an MTA which will only relay from the internal network.
(iv) No use of STARTTLS; all client messaging to be secure at and from the point of protocol initiation. SSL=required, in terms of the Dovecot conf.
This type of approach goes some way towards limiting the exposure from a compromised MTA (attacks will succeed, from time to time), irrespective of the cause of that compromise. (Let me be clear, I am sure any compromise will be unexpected and undeserved by the highly respected and careful and committed designers of the leading MTAs; the compromises that occur will be despite their efforts.) Simply, I'm trying to create a mail environment where remote submission of outbound mail is practical, whilst ensuring that any MTA compromise can be undamaging.
submission server in dovecot is on its way ( my last info )
So I guess the basic SMTP submission feature is not in 2.2.
Off topic for Dovecot list, but I might think instead about separate inbound and outbound MTAs to achieve containment of inbound MTA compromise.
Robert (and Harald), thanks,
Ron
[1] Among very many threads, on GCC bug 30475, in April this year: http://www.metzdowd.com/pipermail/cryptography/2014-April/021074.html
Am 17.11.2014 um 08:23 schrieb Ron Leach:
submission server in dovecot is on its way ( my last info )
So I guess the basic SMTP submission feature is not in 2.2.
i guess it will released, when it is ready
meanwhile use i.e postfix, follow best practice advices, decide what security fits best to your needs. I agree this might be difficult sometimes but you always have have the chance asking on lists and/or hire somebody helping you.
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 17 Nov 2014, Ron Leach wrote:
Let me list the approach we'd prefer:
(i) MTA open on port 25 for inbound email.
(ii) MTA not open on any other port, because (for example, our) MTAs are constantly faced on port 25 with password attacks, malformed packets,
OK: You've been hacked through SMTP once, ...
(iii) Users who are logged in to Dovecot (ie, authorised by Dovecot, so not authorised by any software which is subject of attack and which will be compromised from time to time) able to submit outbound messages through Dovecot on the internal network to an MTA which will only relay from the internal network.
... now you try yet another product with exactly the same problem; your IMAP/POP servers are attacked as well. And most systems do not separate IMAP and SMTP passwords.
(iv) No use of STARTTLS; all client messaging to be secure at and from the point of protocol initiation. SSL=required, in terms of the Dovecot conf.
Personally, I do not think that is more secure.
Off topic for Dovecot list, but I might think instead about separate inbound and outbound MTAs to achieve containment of inbound MTA compromise.
I believe this approach is the best way for you concerns anyway. Make this separate server inbound only on port 587, no other services. You could combine it with an almost instantly sync of users which are logged in via IMAP/POP in Dovecot incl. IP and allow any requests for those user/IP combinations. Sort of: SMPT-after-POP but with SMTP auth and all. Or open IPs only after IMAP/POP-Login succeeded. Or ...
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBVGmsEnz1H7kL/d9rAQI/6ggAizgKj3eSpMlBLLV15B5oConMD8aLxLTM vVn94UmqPNGd8ZqBRM3t07pHT/JCiH4UYvzF5kIXAUQpWebIEit3KH0l/ZlMGd2B aulwvcuAnJpMoKI6zxiwXxedMec9CDjqImOOIHuOWlJtQcdgR3lOETjWsxtBHdKy Y6DJRlCP+VRlh/gS7+9msCDzvnfmINphhRDZT2wvUmHt7oK87ElpxpeWFvpBfxyY 46zOShXd04NEujlp/W1nEIXw7qPL9V1RUglzZfpSnxpdsLqPzCUSjCHD8MNQolDn Nii4p96/Vyxb0RptnMlHAH/tGUA2ead0+pWigCQS7eHok2NV0A6AHw== =BDPM -----END PGP SIGNATURE-----
Am 17.11.2014 um 08:23 schrieb Ron Leach:
On 16/11/2014 07:24, Robert Schetterer wrote (re-ordered):
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
- if you find a security issue in postfix running on 587 over TLS cry out loud
I'm thinking beyond that; I want to get to the position that when there is an issue in the MTA, our systems are less exposed than they might otherwise be. It's not about the MTA.
and why do you then want the MTA inside dovecot?
if there is an issue in postfix, well, that's it and not more because by using dovecots SASL provider it has even no access to the user database at all
that's it and if you think that combination is not secure enough pull the network cables
That's pretty much what we have at the moment, but we need to be able to submit from offsite, and I'm keen to implement that together with our migration to 2.2. Of course offsite submission is easy, but in our experience that is also vulnerable.
what expierience?
Let me list the approach we'd prefer:
(i) MTA open on port 25 for inbound email.
(ii) MTA not open on any other port, because (for example, our) MTAs are constantly faced on port 25 with password attacks, malformed packets, malformed messages that contain scripts, and malformed protocol sequences; all these show up in the logs.
so what
In the past, at least one of those succeeded. We have a saying: 'once bitten, twice shy'. So, now I would prefer that any MTA we use (that is capable of outbound messaging) be *not* capable of relaying from any inbound SMTP protocol. (Because inbound SMTP is the focus of so much attack
jesus christ than disable sasl on port 25 and you are done
On 17/11/2014 07:23, Ron Leach wrote:
On 16/11/2014 07:24, Robert Schetterer wrote (re-ordered):
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
- if you find a security issue in postfix running on 587 over TLS cry out loud
I'm thinking beyond that; I want to get to the position that when there is an issue in the MTA, our systems are less exposed than they might otherwise be. It's not about the MTA.
that's it and if you think that combination is not secure enough pull the network cables
That's pretty much what we have at the moment, but we need to be able to submit from offsite, and I'm keen to implement that together with our migration to 2.2. Of course offsite submission is easy, but in our experience that is also vulnerable.
Am 16.11.2014 um 00:03 schrieb Ron Leach:
There has been mention from time to time of a dovecot SMTP submission server. Last I saw was Timo suggesting this would be a 2.3 feature, but that there was already a 'basic' capability in 2.2 that, more or less, merely provided a secured/authorised SMTP submission. I would like to *not* have our MTA capable of being exploited as a relay (it isn't, at the moment) whereas users are logging into our dovecot from offsite using imaps with passwords. [snip most of background]
So, is there some kind of SMTP submission service for a logged in dovecot user, and how would a client make use of that? Is it possible to setup 2.2.15 for this? And, crucially, would the connections between the client (eg at a hotel in some unreliable location) be encrypted right from the start, not using STARTTLS, as is the case in imaps?
And, just to be really demanding, could we configure its use on a non-standard port?i dont see your point...
I wondered whether the background might hinder an answer but it normally helps, I'm sorry it was unclear, and especially so since you took the time to read it.
Let me list the approach we'd prefer:
(i) MTA open on port 25 for inbound email.
(ii) MTA not open on any other port, because (for example, our) MTAs are constantly faced on port 25 with password attacks, malformed packets, malformed messages that contain scripts, and malformed protocol sequences; all these show up in the logs. In the past, at least one of those succeeded. We have a saying: 'once bitten, twice shy'. So, now I would prefer that any MTA we use (that is capable of outbound messaging) be *not* capable of relaying from any inbound SMTP protocol. (Because inbound SMTP is the focus of so much attack. Though current versions of MTAs are conscientiously engineered to be as secure as is practical, they will be broken. They may even be broken through no action or omission of their own designers; you may have seen recent discussions on a cryptography list [1] where the optimising option in a popular tool chain resulted in some protection algorithm being rendered ineffective. But that's just one example of a long line of subsequently revealed security weaknesses, so architectures based on assumptions that the implementations are now perfect and that they will remain perfect even though the toolchains, the OSs, the crypto routines and the attacks evolve would be ill-founded. And attacks don't become weaker, they constantly improve.)
(iii) Users who are logged in to Dovecot (ie, authorised by Dovecot, so not authorised by any software which is subject of attack and which will be compromised from time to time) able to submit outbound messages through Dovecot on the internal network to an MTA which will only relay from the internal network.
(iv) No use of STARTTLS; all client messaging to be secure at and from the point of protocol initiation. SSL=required, in terms of the Dovecot conf.
This type of approach goes some way towards limiting the exposure from a compromised MTA (attacks will succeed, from time to time), irrespective of the cause of that compromise. (Let me be clear, I am sure any compromise will be unexpected and undeserved by the highly respected and careful and committed designers of the leading MTAs; the compromises that occur will be despite their efforts.) Simply, I'm trying to create a mail environment where remote submission of outbound mail is practical, whilst ensuring that any MTA compromise can be undamaging.
submission server in dovecot is on its way ( my last info )
So I guess the basic SMTP submission feature is not in 2.2.
Off topic for Dovecot list, but I might think instead about separate inbound and outbound MTAs to achieve containment of inbound MTA compromise.
Robert (and Harald), thanks,
Ron
[1] Among very many threads, on GCC bug 30475, in April this year: http://www.metzdowd.com/pipermail/cryptography/2014-April/021074.html
Hi Ron,
Firstly these questions mostly relate to MTA configuration and are hence probably on the wrong list now; however:
I second Reindl's views here.
The issues you describe as vulnerabilities all stem from bad configuration.
Run Postfix 2.11.x (production ready, hardened) or Postfix 2.12.x (development, but run by the author... also hardened).
Ensure you're running postscreen within Postfix. Use of the deep protocol tests will eject script kiddies like crazy. Basic postscreen goes after zombie attacks and is still very effective on its own. Either way the attackers won't even get close to an inbound SMTPd process.
As Reindl said switch off SASL on port 25 (hence in the SMTP conversation following the ehlo line, the client isn't even offered AUTH and hence the chance to login to try to relay).
In Postfix SASL isn't switched on by default - either on port 25 or 587. To enable it edit the master.cf file uncommenting the section for submission (587) with a few options passed in via -o: -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject
As others have said moving the MSA - Mail Submission Agent - out of Postfix into Dovecot or another IMAP server doesn't help. If anything you're moving a service out of extremely well tested and battle-hardened code into relatively new untested code. Which would you trust more?
Join the postfix list, if you aren't already a member, and submit more questions there regarding hardening your configuration further. Steps you may wish to look at in future include setting up DKIM to sign all outbound mail, and verify all inbound mail. Add whitelisting and blacklisting services to your setup as appropriate.
You really can't get stronger mail injection than using the standard submission port only accepting AUTH via TLS encrypted connections on port 587 and Postfix running postscreen (with or without deep protocol tests) to reject the majority of zombie type spammers. The postfix documentation is good and very thorough.
-- Kind Regards,
Mark Homoky IT Consultant
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 26 Nov 2014, Mark Homoky wrote:
On 17/11/2014 07:23, Ron Leach wrote:
On 16/11/2014 07:24, Robert Schetterer wrote (re-ordered):
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
Off topic for Dovecot list, but I might think instead about separate inbound and outbound MTAs to achieve containment of inbound MTA compromise.
@Ron: This seems to be the most sensible option for your concerns anyway, but with a well-known MSA. The inbound MTA need not advertise its existance to the web and, if port 587 is the only one, you could bann port probes, because few attackers will start with port 587.
As Reindl said switch off SASL on port 25 (hence in the SMTP conversation following the ehlo line, the client isn't even offered AUTH and hence the chance to login to try to relay). [cut] You really can't get stronger mail injection than using the standard submission port only accepting AUTH via TLS encrypted connections on port 587
If both port 25 and port 587 are open on the same server, is there any statitic about how much attackers probe port 25 before 587 and if disabling AUTH on port 25 helps at all in that case?
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBVHbQIXz1H7kL/d9rAQLPRQf+P6PQeJ/A1Ht4/f3ulQr2RceeLwQVkdZu tozkdSOrAs3kynbv0f32axgPy1pZIE2VS4mgFPjBKm3fYDSZMM34NqbNGy+v7vrq FNHDLjTOUusYrXcU57TWWdA8uOBLcfrWemLcnlq75ziELqEBqOtrBpfuYVdN9DB8 927V6Q5To5rTLvul3ZzK+V0YSUu7fkXl9sgHUYpbbtyengUVDYDSL+tQUGhYT5ob Mc/KDP5ZNek956etjMWgrCl1XbMKJdRRi6ZWvdVU7+W8aQkrXErdRp69fgRMTwk2 TNWD+9gN5XMBjZL/ZTIDz2Pi70gQaKDVGeyXD0ALUAmJpIFBoGwrlw== =XrHX -----END PGP SIGNATURE-----
Am 27.11.2014 um 08:17 schrieb Steffen Kaiser:
On Wed, 26 Nov 2014, Mark Homoky wrote:
On 17/11/2014 07:23, Ron Leach wrote:
On 16/11/2014 07:24, Robert Schetterer wrote (re-ordered):
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
Off topic for Dovecot list, but I might think instead about separate inbound and outbound MTAs to achieve containment of inbound MTA compromise.
@Ron: This seems to be the most sensible option for your concerns anyway, but with a well-known MSA. The inbound MTA need not advertise its existance to the web and, if port 587 is the only one, you could bann port probes, because few attackers will start with port 587.
As Reindl said switch off SASL on port 25 (hence in the SMTP conversation following the ehlo line, the client isn't even offered AUTH and hence the chance to login to try to relay). [cut] You really can't get stronger mail injection than using the standard submission port only accepting AUTH via TLS encrypted connections on port 587
If both port 25 and port 587 are open on the same server, is there any statitic about how much attackers probe port 25 before 587 and if disabling AUTH on port 25 helps at all in that case?
at my site, brute force is done on both ports, typical search for weak passwords, so no cure having submission only for mail clients ( but for sure this should be state of art )
but in most cases its like
submission/smtpd[27698]: warning: unknown[...]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
this maybe related to have autoconfig/autodiscover up and running for all domains,forgotten and/or missconfigured (typos) on mobile clients etc, so someone may argue this isnt a good idea in case of security
Looking to all my servers, over the time, all types of hacking on all ports are done, in case of mail it might be a good idea to have i.e fail2ban etc to cover sasl logins, as alternative you may have a look at https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/
Most advance in having submission seperate ( whatever software ) , is the chance to have other restrictions enabled ( more easy ), typical i.e you do postscreen on port 25 , and may use other policies for older mail clients at submission
To be honest, i dont understand discussions about security and upcomming dovecot SMTP submission server as long it has no bugs and same advanced config options i.e like postfix submission, after all everyone is free to use it or not.
-- Steffen Kaiser
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Am 27.11.2014 um 08:17 schrieb Steffen Kaiser:
On Wed, 26 Nov 2014, Mark Homoky wrote:
On 17/11/2014 07:23, Ron Leach wrote:
On 16/11/2014 07:24, Robert Schetterer wrote (re-ordered):
Am 16.11.2014 um 02:24 schrieb Reindl Harald:
Off topic for Dovecot list, but I might think instead about separate inbound and outbound MTAs to achieve containment of inbound MTA compromise.
@Ron: This seems to be the most sensible option for your concerns anyway, but with a well-known MSA. The inbound MTA need not advertise its existance to the web and, if port 587 is the only one, you could bann port probes, because few attackers will start with port 587.
As Reindl said switch off SASL on port 25 (hence in the SMTP conversation following the ehlo line, the client isn't even offered AUTH and hence the chance to login to try to relay). [cut] You really can't get stronger mail injection than using the standard submission port only accepting AUTH via TLS encrypted connections on port 587
If both port 25 and port 587 are open on the same server, is there any statitic about how much attackers probe port 25 before 587 and if disabling AUTH on port 25 helps at all in that case?
surely, nobody cares about 587 because it's typically only possible with autentication to submit mail and so in no way useable for deliver spam or as open relay
that below is from a honeypot network but keep in mind that in case oftry a different port from the same IP "last_port" after testing 25/587 changes to that one
mysql> select count(*) from dnsbl where dnsbl_last_port=25; +----------+ | count(*) | +----------+ | 790 | +----------+ 1 row in set (0.00 sec)
mysql> select count(*) from dnsbl where dnsbl_last_port=587; +----------+ | count(*) | +----------+ | 2 | +----------+ 1 row in set (0.01 sec)
participants (6)
-
Brad Smith
-
Mark Homoky
-
Reindl Harald
-
Robert Schetterer
-
Ron Leach
-
Steffen Kaiser