Earlier quoted context omitted.
The usable qmail got owned by AI already, the unusable one not yet!
Not by AI, but by humans awhile ago. I think Qualys weaponized a wontfix LP64 integer overflow in it just a couple years ago?
Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
11–20 of 48 posts
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#12Earlier quoted context omitted.
Not by AI, but by humans awhile ago. I think Qualys weaponized a wontfix LP64 integer overflow in it just a couple years ago?
The Calif people found a nice bug in a qmail fork(what I consider usable qmail) some weeks ago.
(I don't think anyone should run qmail.)
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#13Earlier quoted context omitted.
Many years ago I used Exim because it was default for my distro of choice back then. But after a few emergency patchings caused by yet another RCE in Exim I learned that switching to Postfix massively improved my sleep quality.
There's a weird folk belief that Exim is a secure 2nd-generation MTA, but it's not; it's a 1st generation MTA, like Sendmail and Smail. The two "secure" 2nd generation MTAs are Postfix and qmail. You shouldn't use those either, really; there is no reason to run a memory-unsafe MTA, or, for that matter, an MTA that isn't backed by a real database.
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#14Earlier quoted context omitted.
Many years ago I used Exim because it was default for my distro of choice back then. But after a few emergency patchings caused by yet another RCE in Exim I learned that switching to Postfix massively improved my sleep quality.
There's a weird folk belief that Exim is a secure 2nd-generation MTA, but it's not; it's a 1st generation MTA, like Sendmail and Smail. The two "secure" 2nd generation MTAs are Postfix and qmail. You shouldn't use those either, really; there is no reason to run a memory-unsafe MTA, or, for that matter, an MTA that isn't backed by a real database.
I’ve been looking at Stalwart to replace my old exim setup, wondering if it’s a reasonable choice.
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#15Previously (2020): https://www.exim.org/static/doc/security/CVE-2020-qualys/CVE...
Previously (2019): https://www.cvedetails.com/vulnerability-list/vendor_id-1091...
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#16Earlier quoted context omitted.
There's a weird folk belief that Exim is a secure 2nd-generation MTA, but it's not; it's a 1st generation MTA, like Sendmail and Smail. The two "secure" 2nd generation MTAs are Postfix and qmail. You shouldn't use those either, really; there is no reason to run a memory-unsafe MTA, or, for that matter, an MTA that isn't backed by a real database.
Which one would you suggest using? I’ve been looking at Stalwart to replace my old exim setup, wondering if it’s a reasonable choice.
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#17There's a pattern here worth noting: the riskiest attack surfaces in complex C software often aren't in the core logic but at integration boundaries — where one component (Exim) makes assumptions about object lifecycles managed by another (GnuTLS). Those boundaries require simultaneous deep familiarity with both codebases, which is cognitively expensive for humans but maps well to automated analysis.
This is also why "use a well-audited TLS library" doesn't fully transfer safety — you inherit the library's correctness guarantees only for the paths the library authors tested, not for how you call it under load or error conditions.
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#18It says coordinated distro release today, and I've received a notice earlier today but that does not include the CVE number. That's confusing / does not seem very coordinated to release 2 separate security update notices in a day. https://lists.debian.org/debian-security-announce/2026/msg00...
exim4 (4.98.2-1+deb13u2) trixie-security; urgency=high
* Backport fix for Use-After-Free in GnuTLS BDAT/CHUNKING code path.
This is Exim-Security-2026-05-01.1, fixed upstream in 4.99.3.
-- Andreas Metzler Mon, 11 May 2026 19:14:46 +0200
The ID is now in the CVE database, but it was missing from the upstream advisory, too: https://exim.org/static/doc/security/EXIM-Security-2026-05-0...Not ideal, but at least we got the fix.
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#19>What follows is, before anything else, a story. One of those old, well-worn ones. Gag.
Re: Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim
#20>What follows is, before anything else, a story. One of those old, well-worn ones. Gag.
[flagged]
I too suffer from lack of interest in machine written posts. but the real sociological problem is because it is hard to tell the difference, disinterest turns into paranoia. And this hurts everyone.
However in this case, the article in question does not read like machine written, so perhaps the revulsion was just over the hyperbolic tone.