At the end, fixing any possible segfault makes the smtp process more stable. It re-queued the same mail 6-7 times before the fix, and the crashing process resulted in delayed sending to the „correct“ recipients (because they were in Cc/Bcc). As expired certificates do appear in real-world scenarios, it is an important fix. Now TLSRPT will also report the expired cert condition, whereas it didn‘t before.
> Am 17.02.2025 um 20:14 schrieb Wietse Venema via Postfix-users > <postfix-users@postfix.org>: > > A. Schulze via Postfix-users: >> >> >> Am 16.02.25 um 19:11 schrieb Wietse Venema via Postfix-users: >>>>>> measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org >>> >>> I was able reproduce a crash sending mail to that address, without >>> needing any smtp_tls_policy_maps plugin stuff. >> >> I was unable to reproduce a segfault. postfix-3.10-20250207 (without the >> patch) >> handled my message to the address above as usual. >> Also all my other lab systems do not log any segfault. OK, maybe they simply >> hit no server with an expired certificate. >> >> Are there additional requirements that this error occur? >> >> But, as it is identified and fixed, maybe that does no longer matter ... > > It did not segfault unless there was a 'certificate expired' > condition. That required a tls security level that verifies > certificates. I used the level 'secure' and a certificate match > with tls-force.measurement.email-security-scans.org > > Wietse > _______________________________________________ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
