Re: unexpected: postfix tls deploy-server-cert + smtpd_tls_chain_files
On Fri, Apr 01, 2022 at 12:48:57AM +1000, Nikolai Lusan wrote: > Hey, > > On Wed, 2022-03-30 at 17:35 +1100, raf wrote: > > > > Postfix picks up new certificates soon enough > > (controlled by the max_idle and max_use parameters). > > > > Did you have smtpd_tls_chain_files set to an old > > key/cert, as well as smtpd_tls_cert_file and > > smtpd_tls_key_file set to the updated ones? Was that > > the cause? > > The process I use to update my certificates uses rsync to overwrite the > old certs/keys with the new ones. My thought process initially was that > restarting postfix would have it pick up the new files - eventually by > inspecting the relevant hash files I found copies of old certs in them > ... hence rebuilding the hash files on update. > > - -- > Nikolai Lusan Thanks. It wouldn't have occurred to me to put keys/certs in a hash database, but I've only got one at a time. Checking the out-of-datedness of binary database files is important. There might have been warning messages in mail.log from postfix that it was out of date. I've seen such a warning recently, but I can't seem to produce one right now on my own server. So maybe I'm imagining things. cheers, raf
Fwd: [ANN]ounce of S-postgray v0.6.0
Hello. I hope it is ok to forward this. I have developed and released a postfix protocol graylisting server that possibly could interest some people on this list. I have the hope it proves worth its MTA :-) The online manual ([2] below) should be enough (so note groff HTML conversion is bad; the ball is ~127KB, the optimized binary package is 44KB on a GNU libc Linux system). Thanks, and ciao already here, --- Forwarded from Steffen Nurpmeso --- [.] Announcing the first release of S-postgray, a postfix[1] RFC 6647 graylisting policy server that aims in being fast and secure. The manual should provide detailed information, it can also be read online at [2]. I think this program is mature, and i do not expect a lot of changes in the future. It could be adjusted to run with other SMTP servers (Exim[3] should work already if it is configured to speak the postfix policy protocol, but has not been tested). What should definitely change is the build system, it is intermediate because of the SU tools used, those are part of the S-nail MUA and so need to be "baked in". Therefore: Either it builds, then it should run. Or not. :-) I have tested it on GNU and musl Linux, and on all BSDs. (Solaris needs some build system work, but should do, too.) To build this software simply run "make install". At the top of the makefile there are some variables, they can be overwritten from the command line: $ make DESTDIR=.xxx PREFIX=/usr LIBEXEC=sbin \ VAL_STORE_PATH=/var/lib/postfix \ install This will build and install the binary under [.xxx]/usr/sbin, and the default built-in path for database storage and the client/server communication socket will be /var/lib/postfix. There is a unit test ./s-postgray-test.sh (see README). The files to download are https://ftp.sdaoden.eu/s-postgray-0.6.0.tar.gz https://ftp.sdaoden.eu/s-postgray-0.6.0.tar.gz.asc They also exist in a XY-latest.* version, and are signed with my OpenPGP key available on some OpenPGP key servers, my website (also WKD), and my download area (ftp.sdaoden.eu/steffen.asc). stef...@sdaoden.eu / 1883A0DD (EE19 E1C1 F2F7 054F 8D39 54D8 3089 64B5 1883 A0DD) [1] https://www.postfix.org [2] https://www.sdaoden.eu/code-postgray.html [3] http://www.exim.org Have fun! Ciao from Germany, [.] -- End forward <20220331194300.av18f%stef...@sdaoden.eu> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Best way to filter mail when using recipient_delimiter
On 3/31/2022 1:21 PM, Togan Muftuolu wrote: Hi, As the subject says what is the best strategy or way to filter and in this case I would rather reject specific mail addresses that are using the format user+whate...@example.com So in this case I would like to reject any mail that has the +whatever suffix. My understanding is - Relocated doesn't make sense - virtual can't be because the domain part is not a virtual domain What I see is access as a possibility but up to now I have thought it as allowing access to the sender not the receiver. Am I missing the point here or is there a better way of doing this check and reject those mails with the certain +whatever part Thanks To reject the recipient, use a check_recipient_access table. -- Noel Jones
Best way to filter mail when using recipient_delimiter
Hi, As the subject says what is the best strategy or way to filter and in this case I would rather reject specific mail addresses that are using the format user+whate...@example.com So in this case I would like to reject any mail that has the +whatever suffix. My understanding is - Relocated doesn't make sense - virtual can't be because the domain part is not a virtual domain What I see is access as a possibility but up to now I have thought it as allowing access to the sender not the receiver. Am I missing the point here or is there a better way of doing this check and reject those mails with the certain +whatever part Thanks
Re: unexpected: postfix tls deploy-server-cert + smtpd_tls_chain_files
> On 31 Mar 2022, at 10:48 am, Nikolai Lusan wrote: > > The process I use to update my certificates uses rsync to overwrite the > old certs/keys with the new ones. My thought process initially was that > restarting postfix would have it pick up the new files - eventually by > inspecting the relevant hash files I found copies of old certs in them > ... hence rebuilding the hash files on update. Restarting (as opposed to "postfix reload") is only necessary when: * Upgrading to a new version of Postfix in which internal protocols changed. * Changes in inet_interfaces that require master(8) to listen on a different set of IP addresses for various "inet" services. Otherwise, you don't need to "restart" Postfix, and a "reload" is less disruptive. For non-emergency certificate updates, you might even just let max_use and max_idle take care of eventually (soon enough) replacing all running smtpd processes, and avoid the "reload" entirely. Assuming there's nothing wrong with the old certificate in the short term. -- Viktor.
Re: unexpected: postfix tls deploy-server-cert + smtpd_tls_chain_files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey, On Wed, 2022-03-30 at 17:35 +1100, raf wrote: > > Postfix picks up new certificates soon enough > (controlled by the max_idle and max_use parameters). > > Did you have smtpd_tls_chain_files set to an old > key/cert, as well as smtpd_tls_cert_file and > smtpd_tls_key_file set to the updated ones? Was that > the cause? The process I use to update my certificates uses rsync to overwrite the old certs/keys with the new ones. My thought process initially was that restarting postfix would have it pick up the new files - eventually by inspecting the relevant hash files I found copies of old certs in them ... hence rebuilding the hash files on update. - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmJFv1kACgkQ4ZaDRV2V L6TrkRAAlSg1rsudX3ctj+/kYp0izWVG/xCXZNSDAdJohOIb2ZM5waadp/DWdorb QtPGOOrE4HMCjvZsFRgLiHu0VEIx3HriHrn+j7SDHAoSSI3z0WmwU1gu/ZL86S9U QSeaRsXbqaxdfDWncjDySakfssrfEXokgHCTso/PCg5HBC4Uvfcl49DXSrkixXPB dn9WVAb8fukBY3m0Xb4qEskYd6Bm8rIDvphDZhSUPQY8Ach54QjFomMmq9xFnRNS bOWt23nmvawFAsKqkj6eHv//oTLwVomjronLf4PydDyZc3yHPK21zmYulk75QfUa kRnOT5ot1y8DjwMeBrcyguuFVpCVR4ZgtfaPB8yJVAidDfr943qSGqIGFksQOoDf wkfcLhEC8bQbjmg7NCei8kjYZiP0AjlsYrM97FqL8S4hP+MGTso2p+oLVT2dMBaH gVbNpnzMRkGOWoNeCNP5huDMIAsH9j656AZLJEuMQ0nDJV7bwuyZ0SQCEhQhGh/Z g6k7UX+R80QyXyiOK9DL1+3C3fMh6zBk8vyzd3qMDbuqnCQIm8olCkKeDgFyTaYC 1mRGemCuT3Ss2j8stvI/RgEutQMCG6trlc3oS7BQp0+GBcdCCEfRce/hWkamZ3xY tLdtsbTJzYbkaSHpA+OpQwh0r9JYg9HqL9qsBkNZjVyqWFQfm8U= =dAy9 -END PGP SIGNATURE-
