On 2024/08/19 15:26, Theo Buehler wrote: > On Mon, Aug 19, 2024 at 02:57:28PM +0200, Renaud Allard wrote: > > > > > > On 8/19/24 12:04 PM, Peter Nicolai Mathias Hansteen wrote: > > > > > > So quite odd, the whole thing. > > > > > > > That's indeed quite odd if connecting with openssl s_client works. > > I really think you should try out asking exim devs. > > It would be helpful to have a reproducer or a backtrace. It is > impossible to gather much info from this discussion.
Install the debug-exim package to match the exim package that you've installed (whether that's self built or from the snapshot - reinstall the main package if unsure whether they match). Then # mkdir /var/crash/exim (i assume that is the process name; adjust if not) # sysctl kern.nosuidcoredump=3 Trigger a crash, see if you get a /var/crash/exim/$PID.core and if so, point egdb at it. Alternative: bisect around upstream commits touching TLS? these, maybe others? https://github.com/Exim/exim/commit/5d5ad9fb16a2511ff2e0e7d4528d399f06f608da https://github.com/Exim/exim/commit/fe105877d57ac7e05a4333e0d072f232d212b9fe > While it is impossible to be sure where exactly the bug lies, it sure > looks as if exim had another pretty bad bug in a release. The diff > doesn't show much information since it's mostly pointless churn. > > I think it is about time to seriously consider removing exim from the > ports tree for good. That would be OK with me. Of course people can still fetch from the Attic and build themselves if they really need it, but the extra steps needed for that (+ OS updates) will increase the motivation to port the config across to another MTA. (If it _does_ stay, perhaps it should switch to using gnutls).
