mail-in-a-box / mailinabox

Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
https://mailinabox.email/
Creative Commons Zero v1.0 Universal
13.93k stars 1.43k forks source link

Change from TCP sockets to Unix domain sockets? #1963

Open myfirstnameispaul opened 3 years ago

myfirstnameispaul commented 3 years ago

It seems the various packages used with postfix (opendkim, opendmarc, and postgrey) are using TCP sockets, which is usually the default for most packages. As best I can tell, this server doesn't have any other reasons to run these as TCP sockets, but I may be missing something.

If I put together a PR to change to Unix Domain Sockets, is there any interest? This is how I configured back tha' day when "cheap" VPS came with 512MB RAM and HDDs. I realize squeezing every last drop out of servers these days is not as necessary as it was back then, but I know how to do it, so I thought I would go ahead and do it, if there is at least some interest.

From a StackOverflow question I discovered ipc-bench, a tool for comparing TCP and domain sockets locally to compare performance difference. Unfortunately, the tool is poorly documented and I barely figured out the basic commands for using it, but simple tests suggested >200% increase in performance for both latency and throughput.

Without actually going through and configuring, I've discovered one obvious problem which is that spampd is using TCP sockets and cannot be reconfigured for domain sockets without upgrading to 2.53, the latest version of spampd.

A previous issue with spampd was fixed with a workaround, though the maintainer did create a Launchapd bug report to update the Ubuntu repository to the latest version (which is already in 20.04 and Debian repositories), the bug report has sat motionless for over two years now.

Unless something changes (lots of 'this bug affects me' added to the bug report?), it appears that Ubuntu won't be adding the latest build of the spampd package to 18.04. Other options include building from source at install (sounds like a PITA) or creating a PPA. I've successfully built backported PPAs for myself in the past, but like the other changes suggested here I don't want to spend the time if there isn't at least some interest in using the PPA.

jvolkenant commented 3 years ago

I don't think milter communications listening on lo will be a performance bottleneck.

root@m:~# iperf3 -s -B 127.0.0.1 -4 > /dev/null &
[1] 8894
root@m:~# iperf3 -c 127.0.0.1
Connecting to host 127.0.0.1, port 5201
[  4] local 127.0.0.1 port 41210 connected to 127.0.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  1.70 GBytes  14.6 Gbits/sec    0   8.12 MBytes
[  4]   1.00-2.00   sec  1.61 GBytes  13.8 Gbits/sec    0   8.12 MBytes
[  4]   2.00-3.00   sec  1.62 GBytes  13.9 Gbits/sec    0   8.12 MBytes
[  4]   3.00-4.00   sec  1.52 GBytes  13.1 Gbits/sec    0   8.12 MBytes
[  4]   4.00-5.00   sec  1.48 GBytes  12.7 Gbits/sec    0   8.12 MBytes
[  4]   5.00-6.00   sec  1.54 GBytes  13.2 Gbits/sec    0   8.12 MBytes
[  4]   6.00-7.00   sec  1.45 GBytes  12.5 Gbits/sec    0   8.12 MBytes
[  4]   7.00-8.00   sec  1.29 GBytes  11.1 Gbits/sec    0   8.12 MBytes
[  4]   8.00-9.00   sec  1.53 GBytes  13.2 Gbits/sec    0   8.12 MBytes
[  4]   9.00-10.00  sec  1.59 GBytes  13.6 Gbits/sec    0   8.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  15.3 GBytes  13.2 Gbits/sec    0             sender
[  4]   0.00-10.00  sec  15.3 GBytes  13.2 Gbits/sec                  receiver

iperf Done.
root@m:~# fg
iperf3 -s -B 127.0.0.1 -4 > /dev/null
^C
JoshData commented 3 years ago

Unix sockets would be nicer for at least the reason that they are named, so we don't have to guess what port is for what. So, yes, I'd accept a PR that makes that change (except for spampd if it doesn't work).

myfirstnameispaul commented 2 years ago

Okay, I'm finally on this starting with opendmarc and it functions with the only issue being that Status Checks of course reports "OpenDMARC is not running (port 8893)."

I have opendmarc.sock owned by opendmarc:opendmarc in /var/spool/postfix/opendmarc/ (within the postfix chroot) and also owned by opendmarc:opendmarc.

The changes made were:

The only thing I'm left with is how to make status_checks.py evaluate a daemon running through a socket.

Any tips would be much appreciated, and I should be able to use such on postgrey and later dkimpy and spampd when working on 22.04 (installed version of spampd doesn't support sockets).

JoshData commented 2 years ago

The only thing I'm left with is how to make status_checks.py evaluate a daemon running through a socket.

It would be fine to skip that for now, since we don't have it for the other services like that, as you mentioned.

downtownallday commented 2 years ago

using socket.AF_UNIX (as first arg to socket.socket() call in status_checks.py::check_service::try_connect) and the path to the socket (in socket.connect()) might work