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
