On Fri, Jul 23, 2021 at 12:35:50AM -0400, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> On Fri, Jul 23, 2021 at 11:21:14AM +1000, raf wrote: > > > > > The FORWARD_SECRECY_README suggests regenerating the > > > > Postfix SMTP server EDH parameters periodically. > > > > Would doing so necessitate a postfix reload? > > > > > > No. The new parameters get picked up by new smtpd(8) > > > processes as old ones exit after handling $max_use > > > connections or being idle at least $max_idle. > > > > Thanks for that. Am I right in thinking that the same > > doesn't apply when letsencrypt certificates are > > renewed? I read somewhere that people needed to > > automate the restarting of postfix and dovecot when > > that happens. > > For the same reason as above, Postfix also DOES NOT need to be reloaded > during regular (non-emergency) certificate rollover. Dovecot on the > other hand does need to be reloaded IIRC (I seem to need to do that > on my server). > > Lots of people who think they know something write HOWTO guides, but > most of them make some of it up. > > > I was more concerned that the documentation doesn't > > state clearly whether or not a reload is needed. > > Postfix reloads are required very rarely, pretty much only when you > change parameters that affect the master(8) process (e.g. routine > master.cf changes), qmgr(8), or tlsmgr(8). Some changes to master.cf > (listen addresses of network services) require a restart. > > On my server, very few Postfix processes have been running non-stop > since master(8) was started, the rest are recycled and pick up new > settings automatically: > > PID ELAPSED COMMAND > 76082 41-12:05:31 /usr/local/libexec/postfix/master -w > 76221 41-11:54:22 qmgr -l -t unix -u > 76224 41-11:54:21 tlsmgr -l -t unix -u > 8310 01:32:05 pickup -l -t unix -u -o > receive_override_options=no_header_body_checks > 9487 23:11 anvil -l -t unix -u > 9621 00:09 smtpd -n smtp -t inet -u -o stress= -s 2 -o > smtpd_discard_ehlo_keywords=silent-discard,DSN > 9622 00:09 proxymap -t unix -u > > If your changes are not critically urgent, no reload is generally > required. > > > Perhaps the absence of such a statement is to be interpreted to mean > > that it doesn't, but that would just be a guess, and TLS_README > > doesn't mention needing to reload when the certificate/key files are > > updated, but it seems that that is needed. > > No reload is generally required, the documentation strives to explicitly > call out the cases when a reload may be required or desirable, > otherwise, unless we failed to mention it, reload is not needed. > > > > In practice security is compromised by going around the > > > crypto, rather than cracking the algorithms. Focus on > > > the basics, keeping your endpoints up to date, monitoring, > > > ... Security is about operational discipline, the > > > cryptography gets all the press, but is almost never the > > > weak link. > > > > Very true, but the care and feeding of crypto matters > > too, otherwise https://ssl-config.mozilla.org and > > https://www.ssllabs.com wouldn't exist. > > Those are also overhyped, though not quite as much in the context of > HTTPS. In SMTP TLS is opportunistic, and if you crank up the crypto to > 11, often what happens is that more email is sent in the clear instead, > making "hardening" counter-productive. The same can also happen with > HTTPS, if a user is forced to use HTTP in order to avoid HTTPS breakage, > but much less often since browsers typically have new shiny crypto. > > > And my government's tax department wouldn't insist on payroll service > > providers and the like not using anything older than TLSv1.2 for their > > websites and APIs. But perhaps that's just part of keeping your > > endpoints up to date. > > The Web is a different story, and at this time TLS 1.0 is mostly gone > from the ecosystem, and 1.1 was pretty much never adopted, so turning > both off if is generally not imprudent. > > > Having said that, regenerating DH params does seem like > > overkill, and just gives the monitoring more to whinge > > about. :-) > > Very little TLS tuning has real benefit in Postfix, the defaults are > generally quite sufficient. > > -- > Viktor. Thanks so much for all that. It's much appreciated. It's good to know that I'll only need to reload dovecot and not postfix when the certificate renews. I had thought a postfix reload would also be needed after changing parameters in main.cf, or the contents of any read-once databases that it uses (i.e. pcre:, regexp:, cidr:, texthash:). But I see [DATABASE_README] that changes to those databases only require a postfix reload if they affect long-running processes like trivial-rewrite. And it seems [postconf(5)] that only a few main.cf parameter changes require a postfix reload. But there are about 50 parameters used by trivial-rewrite, so changes to any of those should probably warrant a postfix reload. But perhaps not. Knowing exactly which parameter changes require a postfix reload because they affect long-running processes seems complicated. I have a Makefile for /etc/postfix that scans any config files looking for databases that need to be rebuilt with postalias or postmap, and it reloads postfix when any config files or read-once databases are changed. I guess it's overdoing it, in terms of reloading postfix when it isn't strictly necessary, but making it smart enough to remember the important parameters and only reloading postfix when those specific parameters were changed would really be overdoing it, in terms of time spent implementing it. :-) Luckily, any temporary performance reduction caused by a postfix reload won't affect me. I've even seen a /etc/postfix/Makefile at a largeish corporate ISP that unnecessarily reloaded postfix whenever a hash: database was updated. That was inefficient but it must have been OK for them (because postfix is just that good!). My needs are tiny compared to theirs. The most valuable lesson for me here is to never leave main.cf in an intermediate state, assuming that it won't take effect until the next reload (i.e. always create databases before referring to them, not afterwards). I had been foolishly assuming that. Thanks again, Viktor. cheers, raf
