Re: Reject when delivering to a pipe?
Charles Sprickman: > I think that as long as the script returns the appropriate error > code on failure you don't have to do anything special; from pipe(8): > >In the case of a non-zero exit status, a limited amount of command >output is logged, and reported in a delivery status notification. When >the output begins with a 4.X.X or 5.X.X enhanced status code, the >status code takes precedence over the non-zero exit status (Postfix >version 2.3 and later). The expected status codes may be found in /usr/include/sysexits.h. The text belw shows what they might look like. Postfix converts these into an appropeiate 4.X.X or 5.X.X enhanced status code and text, if the command output does not specify one. Wietse #define EX_USAGE64 /* command line usage error */ #define EX_DATAERR 65 /* data format error */ #define EX_NOINPUT 66 /* cannot open input */ #define EX_NOUSER 67 /* addressee unknown */ #define EX_NOHOST 68 /* host name unknown */ #define EX_UNAVAILABLE 69 /* service unavailable */ #define EX_SOFTWARE 70 /* internal software error */ #define EX_OSERR71 /* system error (e.g., can't fork) */ #define EX_OSFILE 72 /* critical OS file missing */ #define EX_CANTCREAT73 /* can't create (user) output file */ #define EX_IOERR74 /* input/output error */ #define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */ #define EX_PROTOCOL 76 /* remote error in protocol */ #define EX_NOPERM 77 /* permission denied */ #define EX_CONFIG 78 /* configuration error */ > Charles > > > On Oct 2, 2022, at 6:33 PM, Dan Mahoney wrote: > > > > Hello all, > > > > If I am piping my mail to a program (in this case, day job's RT install), > > is there some way in which I can exit that will cause a message to be > > bounced back to the sender? > > > > Or do I need a full-on milter to do this kind of rejection? > > > > -Dan > -- End of PGP section, PGP failed!
Re: Reject when delivering to a pipe?
On Sun, Oct 02, 2022 at 03:33:52PM -0700, Dan Mahoney wrote: > If I am piping my mail to a program (in this case, day job's RT > install), is there some way in which I can exit that will cause a > message to be bounced back to the sender? > > Or do I need a full-on milter to do this kind of rejection? Postfix supports Sendmail-compatible exit codes, as listed in /usr/include/sysexits.h: #define EX_OK 0 /* successful termination */ #define EX__BASE64 /* base value for error messages */ #define EX_USAGE64 /* command line usage error */ #define EX_DATAERR 65 /* data format error */ #define EX_NOINPUT 66 /* cannot open input */ #define EX_NOUSER 67 /* addressee unknown */ #define EX_NOHOST 68 /* host name unknown */ #define EX_UNAVAILABLE 69 /* service unavailable */ #define EX_SOFTWARE 70 /* internal software error */ #define EX_OSERR71 /* system error (e.g., can't fork) */ #define EX_OSFILE 72 /* critical OS file missing */ #define EX_CANTCREAT73 /* can't create (user) output file */ #define EX_IOERR74 /* input/output error */ #define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */ #define EX_PROTOCOL 76 /* remote error in protocol */ #define EX_NOPERM 77 /* permission denied */ #define EX_CONFIG 78 /* configuration error */ Of these (excluding of course EX_OK) EX_TEMPFAIL is the only "soft" failure code, the rest are hard failures. Pick the one that most closely meets your context. Of course not generating bounces is best whenever possible. -- Viktor.
Re: Reject when delivering to a pipe?
I think that as long as the script returns the appropriate error code on failure you don't have to do anything special; from pipe(8): In the case of a non-zero exit status, a limited amount of command output is logged, and reported in a delivery status notification. When the output begins with a 4.X.X or 5.X.X enhanced status code, the status code takes precedence over the non-zero exit status (Postfix version 2.3 and later). Charles > On Oct 2, 2022, at 6:33 PM, Dan Mahoney wrote: > > Hello all, > > If I am piping my mail to a program (in this case, day job's RT install), is > there some way in which I can exit that will cause a message to be bounced > back to the sender? > > Or do I need a full-on milter to do this kind of rejection? > > -Dan signature.asc Description: Message signed with OpenPGP
Reject when delivering to a pipe?
Hello all, If I am piping my mail to a program (in this case, day job's RT install), is there some way in which I can exit that will cause a message to be bounced back to the sender? Or do I need a full-on milter to do this kind of rejection? -Dan
Re: postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
On Sun, Oct 02, 2022 at 06:07:13PM -0400, Wietse Venema wrote: > > With other software, usually I was pretty successful with the following > > approach when I installed a binary package from the repository and then > > found out that something in the program needs patching: getting the > > corresponding source package, patching the file needed, rebuilding with > > exactly the same options as the original binary package was built, and > > That should work, assuming there are no significant changes in the > build infrastructure or installed libraries (Postfix by default > tries to auto-detect ICU and PCRE support, so results may differ). When upgrading from source, I run "make upgrade", which installs the changed files. If the Postfix version has changed, or when it seems prudent, I perform a "postfix restart". Other times, a "postfix reload" or just no action at all are sufficient. -- Viktor.
Re: postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
Jaroslaw Rafa: > Dnia 2.10.2022 o godz. 17:23:33 Wietse Venema pisze: > > > > If fact it's worse: you can't mix Postfix programs and libraries > > from different Postfix builds, even if they are built from the same > > Postfix source. > > What do you mean here by "different builds"? Different configurations such as different compiler command-line arguments, linker options, etc. > Does it mean that if I build Postfix two times, from the same source, on the > same system, and with the same build options each time, I cannot mix the > resulting binaries? If you build Postfix twice without changes, then the builds are not different. > With other software, usually I was pretty successful with the following > approach when I installed a binary package from the repository and then > found out that something in the program needs patching: getting the > corresponding source package, patching the file needed, rebuilding with > exactly the same options as the original binary package was built, and That should work, assuming there are no significant changes in the build infrastructure or installed libraries (Postfix by default tries to auto-detect ICU and PCRE support, so results may differ). Just to be sure, compare your makedefs.out file with the one installed in $meta_directory/makedefs.out. Wietse
Re: manually build 3.7.2 denies SASL although included in make command
Dnia 2.10.2022 o godz. 17:35:23 Wietse Venema pisze: > > I recommend that you use a pre-built package for your OS distribution. > That will solve the startup problem too. I guess he did use those packages, because he wrote that he did a release upgrade from Ubuntu 20.04 to 22.04 and then Postfix stopped working. The release upgrade must have upgraded the Postfix packages too. However, from my experience, relase upgrade is always a risky thing and something can always go wrong. I never recommend to people to do a release upgrade. What I recommend is freshly install a new OS release and migrate all configs (with manual adjustments if necessary) from the previous OS. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
Dnia 2.10.2022 o godz. 17:23:33 Wietse Venema pisze: > > If fact it's worse: you can't mix Postfix programs and libraries > from different Postfix builds, even if they are built from the same > Postfix source. What do you mean here by "different builds"? Does it mean that if I build Postfix two times, from the same source, on the same system, and with the same build options each time, I cannot mix the resulting binaries? Or does it refer only to the case when build options are different? If it is indeed the first case, what is the reason for it? With other software, usually I was pretty successful with the following approach when I installed a binary package from the repository and then found out that something in the program needs patching: getting the corresponding source package, patching the file needed, rebuilding with exactly the same options as the original binary package was built, and replacing only the file(s) I have modified. I did it for example with ProFTPd, Xymon server or Apache and each time everything worked well... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
manually build 3.7.2 denies SASL although included in make command
Martin:
> Today I tried to install postfix 3.7.2 manually. I was enable to include
> MySQL support
> as well as TLS support. But the SASL (sasl2 / cyrus) configuration as
> given by page
> https://www.postfix.org/SASL_README.html does not work at all. When
> trying to
> send mails the answer of postfix (logging to stdoud) says:
> postfix/smtpd[10184]: warning: smtpd_sasl_auth_enable is true, but SASL
> support is not compiled in
This warning is logged because Postfix was NOT built with -DUSE_SASL_AUTH.
Source code fragment:
if (var_smtpd_sasl_enable)
#ifdef USE_SASL_AUTH
// Code that initializes SASL support
#else
msg_warn("%s is true, but SASL support is not compiled in",
VAR_SMTPD_SASL_ENABLE);
#endif
You can find the build configuration in the makedefs.out file,
created in the Postfix top-level source direstory, or installed as
$(postconf -h meta_directory)/makedefs.out
I recommend that you use a pre-built package for your OS distribution.
That will solve the startup problem too.
Wietse
Re: postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
On 10/2/22 14:42, Viktor Dukhovni wrote:
On Sun, Oct 02, 2022 at 08:22:39PM +, Martin wrote:
# postfix stop
postfix/postfix-script: stopping the Postfix mail system
Oct 02 16:24:11 derdickehase postfix/postfix-script[3222]: stopping the Postfix
mail system
/usr/libexec/postfix/postfix-script: 216: kill: No such process
/usr/libexec/postfix/master: symbol lookup error: /usr/libexec/postfix/master:
undefined symbol: var_compat_level
Bingo. Your Postfix software is not properly installed. My Postfix 3.6.4
"master" executable does not have a "var_compat_level" symbol:
Before you take any of my advice, please wait for confirmation from
someone here who is more of an expert than me. It is USUALLY very safe
to do package re-installation on systems that use apt, especially for
software with a high-profile reputation like postfix, but I would really
hate to suggest something that makes things worse rather than better.
And please at a minimum do make a tarball of /etc and store that backup
somewhere safe beforehand so you have all the current configs just in
case. Even better would be a backup of the full system.
What I would try to fix this since you're on Ubuntu:
sudo apt install --reinstall `dpkg -l | grep -E "\s+postfix" | awk
'{print $2}'`
If you are at all worried about what packages that will reinstall, run
the part in backquotes by itself to see the package list:
dpkg -l | grep -E "\s+postfix" | awk '{print $2}'
On my mailserver that only yields postfix packages.
Thanks,
Shawn
p.s.: I know that shellcheck recommends $(command) rather than
backquotes, but I like the backquotes.
Re: postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
Viktor Dukhovni: > On Sun, Oct 02, 2022 at 08:22:39PM +, Martin wrote: > > > [... lots of prose ...] > > > > # postfix stop > > postfix/postfix-script: stopping the Postfix mail system > > Oct 02 16:24:11 derdickehase postfix/postfix-script[3222]: stopping the > > Postfix mail system > > /usr/libexec/postfix/postfix-script: 216: kill: No such process > > /usr/libexec/postfix/master: symbol lookup error: > > /usr/libexec/postfix/master: undefined symbol: var_compat_level > > Bingo. Your Postfix software is not properly installed. My Postfix 3.6.4 > "master" executable does not have a "var_compat_level" symbol: The symbol var_compat_level exists only in Postfix 3.0 .. 3.5. Viktor is right: you cannot mix Postfix programs and libraries from different Postfix versions. If fact it's worse: you can't mix Postfix programs and libraries from different Postfix builds, even if they are built from the same Postfix source. Wietse
Re: postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
On Sun, Oct 02, 2022 at 08:22:39PM +, Martin wrote: > [... lots of prose ...] > > # postfix stop > postfix/postfix-script: stopping the Postfix mail system > Oct 02 16:24:11 derdickehase postfix/postfix-script[3222]: stopping the > Postfix mail system > /usr/libexec/postfix/postfix-script: 216: kill: No such process > /usr/libexec/postfix/master: symbol lookup error: > /usr/libexec/postfix/master: undefined symbol: var_compat_level Bingo. Your Postfix software is not properly installed. My Postfix 3.6.4 "master" executable does not have a "var_compat_level" symbol: # objdump -T /usr/libexec/postfix/master | grep compat_level DF *UND* Base compat_level_from_string DO *UND* Basecompat_level and correspondingly in libpostfix-global we see: # objdump -T /usr/lib64/postfix/libpostfix-global.so | grep compat_level 00034be0 gDF .text 008d Base compat_level_relop_register 00034760 gDF .text 0150 Base compat_level_from_string 000349f0 gDF .text 00c5 Base compat_level_from_numbers 0004e7c0 gDO .bss 0008 Basecompat_level 00034ac0 gDF .text 0120 Base compat_level_to_string Your "master" executable appears to be from an older Postfix version. -- Viktor.
postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
Hi postfix friends, with a release-upgrade from 20.04 LTS to 22.04 LTS there has been a postfix update to 3.6.4 and now not a single (sub-)process of postfix starts and there's no log entry nor error message in mail.err, the process seems to die absolutely silently. I'm still using my old configuration files (sorry for that) because it has been a lot of work to get postfix/postgrey/amavisd and many more processes working together properly. In the "old world" everything starts up as expected: root@berilia:/etc/postfix# netstat -tulpn | grep master tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 7429/master tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 7429/master tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 7429/master tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 7429/master tcp6 0 0 :::587 :::* LISTEN 7429/master tcp6 0 0 :::465 :::* LISTEN 7429/master tcp6 0 0 :::25 :::* LISTEN 7429/master But now, in the 3.6.4 world there's no process for smtp: root@jerakeen:/var/log# netstat -tulpn | grep master root@jerakeen:/var/log# So I looked into the /var/log/mail.log and *.err, but there's no message except for this after reloading the config: Oct 1 22:04:42 jerakeen postfix/postfix-script[1901]: refreshing the Postfix mail system Oct 1 22:04:58 jerakeen postfix/postfix-script[1911]: refreshing the Postfix mail system Oct 1 22:08:04 jerakeen postfix/postfix-script[1927]: refreshing the Postfix mail system Oct 1 22:12:46 jerakeen postfix/postfix-script[2029]: refreshing the Postfix mail system Oct 1 22:22:35 jerakeen postfix/postfix-script[2058]: refreshing the Postfix mail system Postfix itself says it's running (but with remark "exited" in brackets). Then I thought: "Well, let's try what they said about debugging, catching all necessary information with strace (in my case)". But: After reload I can see ... nothing. It seems that postfix for some reason does not start any subprocesses (or how the "master" process should be called). On the other hand: There's no "postfix" process at all although the systemctl statement says that postfix ist active. In my old system I can see these processes: root@berilia:/etc/postfix# ps -ef | grep -i postfix root 7429 1 0 Sep21 ? 00:00:38 /usr/lib/postfix/master postfix 7437 7429 0 Sep21 ? 00:00:04 qmgr -l -t fifo -u postfix 7438 7429 0 Sep21 ? 00:00:03 tlsmgr -l -t unix -u postfix 24361 7429 0 21:16 ? 00:00:00 pickup -l -t fifo -u postfix 24563 7429 0 22:35 ? 00:00:00 smtpd -n smtp -t inet -u -o stress= -s 2 postfix 24565 7429 0 22:35 ? 00:00:00 anvil -l -t unix -u root 24580 23931 0 22:39 pts/1 00:00:00 grep --color=auto -i postfix On my new system which has worked fine until upgrading it to 3.6.4 I can see no single postfix entry: root@jerakeen:/var/log# ps -ef | grep -i postfix root 2136 1514 0 22:41 pts/1 00:00:00 grep --color=auto -i postfix Do you have an idea how to proceed? I now see that postfix does not start at all, but without any trace when reloading config, I can't see a chance to get information why postfix does not start anymore. Right now I'm working on a virtual machine (VirtualBox, latest version), but this worked fine with ubuntu 20.04 LTS and the corresponding postfix version. Yesterday I did a do-release-upgrade and everything works fine right now, even Apache2/PHP/phpmyadmin/roundcube ... but postfix is on strike some- how. - Act II: Postfix does not start at all as I saw right now. And the stopping also gives strange messages: root@jerakeen:~# postfix stop postfix/postfix-script: stopping the Postfix mail system Oct 02 16:24:11 derdickehase postfix/postfix-script[3222]: stopping the Postfix mail system /usr/libexec/postfix/postfix-script: 216: kill: No such process /usr/libexec/postfix/master: symbol lookup error: /usr/libexec/postfix/master: undefined symbol: var_compat_level postfix/postfix-script: waiting for the Postfix mail system to terminate Oct 02 16:24:11 derdickehase postfix/postfix-script[3225]: waiting for the Postfix mail system to terminate /usr/libexec/postfix/master: symbol lookup error: /usr/libexec/postfix/master: undefined symbol: var_compat_level ... postfix/postfix-script: waiting for the Postfix mail system to terminate Oct 02 16:24:15 derdickehase postfix/postfix-script[3237]: waiting for the Postfix mail system to terminate postfix/postfix-script: warning: stopping the Postfix mail system with force Oct 02 16:24:16 derdickehase postfix/postfix-script[3239]: warning: stopping the Postfix mail system with force What can I do? Installing Postfix from source in an older or in a newer version? --- Act III Today I tried to install postfix 3.7.2 manually. I was enable to include MySQL support as well as TLS support. But the SASL (sasl2 / cyrus) configuration as given by page https://www.postfix.org/SASL_README.html does not work at all. When tr
postfix 3.6.4 (ubuntu server 22.04 LTS) does not start - manually build 3.7.2 denies SASL although included in make command
Hi postfix friends, usually I've always found a solution when I ran into postfix problems. Even the change from postfix 2.11 on old 14.xx ubuntu distribution to the 20.04 LTS (forgot the postfix version) was not a big deal, everything ran smooth. But now, with a release-upgrade from 20.04 LTS to 22.04 LTS there has been a postfix update to 3.6.4 and now not a single (sub-)process of postfix starts and there's no log entry nor error message in mail.err, the process seems to die absolutely silently. I'm still using my old configuration files (sorry for that) because it has been a lot of work to get postfix/postgrey/amavisd and many more processes working together properly. In the "old world" everything starts up as expected: root@berilia:/etc/postfix# netstat -tulpn | grep master tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 7429/master tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 7429/master tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 7429/master tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 7429/master tcp6 0 0 :::587 :::* LISTEN 7429/master tcp6 0 0 :::465 :::* LISTEN 7429/master tcp6 0 0 :::25 :::* LISTEN 7429/master But now, in the 3.6.4 world there's no process for smtp: root@jerakeen:/var/log# netstat -tulpn | grep master root@jerakeen:/var/log# So I looked into the /var/log/mail.log and *.err, but there's no message except for this after reloading the config: Oct 1 22:04:42 jerakeen postfix/postfix-script[1901]: refreshing the Postfix mail system Oct 1 22:04:58 jerakeen postfix/postfix-script[1911]: refreshing the Postfix mail system Oct 1 22:08:04 jerakeen postfix/postfix-script[1927]: refreshing the Postfix mail system Oct 1 22:12:46 jerakeen postfix/postfix-script[2029]: refreshing the Postfix mail system Oct 1 22:22:35 jerakeen postfix/postfix-script[2058]: refreshing the Postfix mail system Postfix itself says it's running (but with remark "exited" in brackets). Then I thought: "Well, let's try what they said about debugging, catching all necessary information with strace (in my case)". But: After reload I can see ... nothing. It seems that postfix for some reason does not start any subprocesses (or how the "master" process should be called). On the other hand: There's no "postfix" process at all although the systemctl statement says that postfix ist active. In my old system I can see these processes: root@berilia:/etc/postfix# ps -ef | grep -i postfix root 7429 1 0 Sep21 ? 00:00:38 /usr/lib/postfix/master postfix 7437 7429 0 Sep21 ? 00:00:04 qmgr -l -t fifo -u postfix 7438 7429 0 Sep21 ? 00:00:03 tlsmgr -l -t unix -u postfix 24361 7429 0 21:16 ? 00:00:00 pickup -l -t fifo -u postfix 24563 7429 0 22:35 ? 00:00:00 smtpd -n smtp -t inet -u -o stress= -s 2 postfix 24565 7429 0 22:35 ? 00:00:00 anvil -l -t unix -u root 24580 23931 0 22:39 pts/1 00:00:00 grep --color=auto -i postfix On my new system which has worked fine until upgrading it to 3.6.4 I can see no single postfix entry: root@jerakeen:/var/log# ps -ef | grep -i postfix root 2136 1514 0 22:41 pts/1 00:00:00 grep --color=auto -i postfix Do you have an idea how to proceed? I now see that postfix does not start at all, but without any trace when reloading config, I can't see a chance to get information why postfix does not start anymore. Right now I'm working on a virtual machine (VirtualBox, latest version), but this worked fine with ubuntu 20.04 LTS and the corresponding postfix version. Yesterday I did a do-release-upgrade and everything works fine right now, even Apache2/PHP/phpmyadmin/roundcube ... but postfix is on strike some- how. - Act II: Postfix does not start at all as I saw right now. And the stopping also gives strange messages: root@jerakeen:~# postfix stop postfix/postfix-script: stopping the Postfix mail system Oct 02 16:24:11 derdickehase postfix/postfix-script[3222]: stopping the Postfix mail system /usr/libexec/postfix/postfix-script: 216: kill: No such process /usr/libexec/postfix/master: symbol lookup error: /usr/libexec/postfix/master: undefined symbol: var_compat_level postfix/postfix-script: waiting for the Postfix mail system to terminate Oct 02 16:24:11 derdickehase postfix/postfix-script[3225]: waiting for the Postfix mail system to terminate /usr/libexec/postfix/master: symbol lookup error: /usr/libexec/postfix/master: undefined symbol: var_compat_level postfix/postfix-script: waiting for the Postfix mail system to terminate Oct 02 16:24:12 derdickehase postfix/postfix-script[3228]: waiting for the Postfix mail system to terminate /usr/libexec/postfix/master: symbol lookup error: /usr/libexec/postfix/master: undefined symbol: var_compat_level postfix/postfix-script: waiting for the Postfix mail system to terminate Oct 02 16:24:13 derdickehase postfix/postfix-script[3231]: waiting for the Postfix mail system to terminate /usr/libexec/postfix/master: symbol lookup error: /usr/libexec/postfix/master: undefined symbol: var_compat_l
Re: no shared cipher revisited
Le 02/10/2022 à 11:51, Matus UHLAR - fantomas a écrit : On 10/1/22 16:16, Viktor Dukhovni wrote: 4096-bit RSA certificates mostly work, but are pointless crypto exhibitionism, waste CPU, can run into client implementation limitations, and so are not a good idea. On 01.10.22 17:20, Shawn Heisey wrote: My cert from letsencrypt is 4096 bit. yes, Let's Encrypt clients generate 4096 keys by default, which is silly because intermediate R3 certificate is only 2048-bit. Silly, yes for the common usage and totally pointless. But keep in mind that key generation/primality test are not definitive primatily answer. A very extensively tested 2048 key is more secure than a very basically and lightly tested 4096 key. Key generation/test is something that is often badly neglected... Emmanuel.
Re: no shared cipher revisited
I do have it listening on port 465, hopefully I got the config right so that does not allow authentication. I think I also disabled TLS below 1.2 on port 587. On 10/1/22 20:44, Viktor Dukhovni wrote: What would be the use of "465" if SASL authentication is not allowed? It is should be configured essentially the same way (modulo wrapper mode, and the service name) as port 587. On 01.10.22 21:25, Shawn Heisey wrote: I am leaning towards completely disabling smtps and removing the permit on the AWS firewall. Since 465 is not an actual standard, I think everyone is using 587. I guess if I disable 465 and anyone is using it, I'll hear about it. not only it is a standard for nearly 4 years, it's also better because there's no possibility to have plaintest on 465 if you forget something I've also had problems with AV blocking tls on 587 in the past. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Despite the cost of living, have you noticed how popular it remains?
Re: no shared cipher revisited
On 10/1/22 16:16, Viktor Dukhovni wrote: 4096-bit RSA certificates mostly work, but are pointless crypto exhibitionism, waste CPU, can run into client implementation limitations, and so are not a good idea. On 01.10.22 17:20, Shawn Heisey wrote: My cert from letsencrypt is 4096 bit. yes, Let's Encrypt clients generate 4096 keys by default, which is silly because intermediate R3 certificate is only 2048-bit. I configure let's encrypt clients to create 2048 keys. At the link below is part of a report from SSL labs indicating which browsers can't handle my settings for https: https://www.dropbox.com/s/o1il6wbst3seuid/browser_compatibility_4096_bit.png?dl=0 The browsers that don't work are ones that I don't care about. The vast majority of users will have something newer. browsers don't communicate with postfix, MTAs and MUAs do. thus, you can get into troubles with otherwise perfect MUAs. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows."
Re: no shared cipher revisited
On Sat, Oct 01, 2022 at 09:32:49PM +, Eddie Rowe wrote: > > You should have at least an RSA certificate (2048-bit key, not more), and > > only > I do not recall seeing this on the PostFix web site that discusses TLS > settings as I struggle to setup TLS with our existing wildcard certificate. > Can you confirm a 4096-bit certificate will not work? Who convinced you to use 4096-bit RSA in the first place? Even all those intermediate CA only use 2048-bit anyway. Bastian -- First study the enemy. Seek weakness. -- Romulan Commander, "Balance of Terror", stardate 1709.2
