On Thu, Dec 08, 2022 at 11:29:35AM +0400, Sam wrote:
> Thank you very much for your quick reply and insight. I went ahead and
> disabled wrapper mode in master.cf (and there's no wrapper mode in
> main.cf), and I still can't telnet to port 465, even though it's in use
> in the container. When I try to do that, the connection is closed
> immediately (44465 forwards to docker's 465):
Postfix logs received connections and errors, and the logs make sense,
if you don't try to hide the essential details by enabling verbose
logging.
> telnet localhost 44465
> Trying ::1...
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> Connection closed by foreign host.
What actually handles this connection? Is there a proxy? Just NAT? Is
this in front of or behind the desired "haproxy"?
> This is what smtps looks like in master.cf
>
> smtps inet n - y - - smtpd
> -o smtpd_tls_wrappermode=no
That's a default setting, all you have to do is not set it to yes.
> Are there other things to be enabled to allow this? How can I debug
> this? postfix still doesn't print anything except when I do wrong
> config, even though I attempted to enable debug printing at level 3 for
> address 0.0.0.0/0.
DO NOT enable verbose logging. However, in containers, you generally
need to log via "postlogd", see:
https://www.postfix.org/MAILLOG_README.html
> On the other topic:
>
> So all network packets will be encrypted. This is also extremely
> tempting for me because I can centrally control encryption properties
> without touching anything from the inside (like allowing specific
> ciphers, disabling specific encryption protocols, etc), which I may
> need to do once every few years without digging back into every
> different application.
Not all applications are the same with respect to transport security
requirements, particularly MTA-to-MTA SMTP, with largely opportunistic
TLS.
However, if you're building a *pure* MSA, and there's absolutely no way
to bypass your TLS-terminating proxy and connect directly (otherwise you
become an open relay), and you've configured haproxy protocol support
correctly:
https://www.postfix.org/postconf.5.html#smtpd_upstream_proxy_protocol
and the cleartext channel between haproxy and Postfix is over a
physically secure network where sniffing passwords, ... is not a
concertn, and you or your successort don't later make mistakes in what
is not a common configuration scenario, then ...
> With that in mind (and given also that I don't fully understand SASL, so
> I may be missing something), why should postfix know about the security
> properties of the connection?
Because mistakes become less likely (see above).
> Why should it care? What kind of problem are we trying to solve here?
Too many moving parts. Your real management problem is not TLS
termination by user authentication and authorisation. By terminating
TLS in haproxy you lose the ability to use client certs for relay
authorisation, and, by using it at all, you potentially create various
bypass problems and exposure to traffic interception.
> My plan is to pass port 465 straight to haproxy, then haproxy does the
> encryption in and out.
And what happens between haproxy and Postfix?
> Can you please also elaborate on the fragile security boundaries on
> docker?
Docker attempts to emulate the Unix system-call layer and various kernel
facilities in a user-mode process. Such emulation is difficult to do
correctly, especially as kernels evolve and add new features. Docker
may be fine for containerising simple applications, but Postfix is not
that simple. Postfix runs multiple processes as different Unix uids,
using TCP, unix domain stream and datagram sockets, kevent, epoll,
chroot, ... I, personally, don't trust the added complexity of having
to emulate all that.
You're also complicating logging, communication with Dovecot (for
SASL, which is generally over unix-domain sockets), so you'd both
in the same container, by which point Docker's single application
per container model may not be a good fit...
I personally don't recommend this. If you're expert enough to
understand otherwise nobody will stop you from trying.
--
VIktor.
