Salient quote below:
>In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515):
[snip]
>Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html):
>>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits."
1. https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-...
edit: added quote from referenced url
It sounds like the Debian packager didn’t follow the instructions. That doesn’t seem like the fault of the software.
qmail is a great demonstration that if you declare enough things out of scope, you can claim that the software is secure.
Vendors replied to complaints with: “We don’t support those processors”.
No buddy, you don’t support stable software. It’s buggy even on a single core, it’s just less obvious.
setproctitle is enough logging for a mailer, said nobody ever.
Correct code is easy to read because it's close to its theoretical minimum size. It reminds me of the quote "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
I also ran several other mail systems at the same time (and still do). Exchange's smtpd is still a bit of a pain and I never put it on the internet directly.
Nowadays (last 15 years) I use Exim for a MTA/proxy - at home and at work.
Exim is hugely configurable. If you use it on Debian/Ubuntu and you have somewhat complex needs then ditch the split config thingie and simply create your own /etc/exim4/exim4.conf from scratch.
You can test a config with "exim -bhc <ip.add.re.ss>" to simulate a SMTP session from <ip.add.re.ss>, before you restart Exim to make the config active. So:
helo me
mail from: name@example.co.uk
rcpt to: name@another.example.co.uk
data
etc etc
At each stage you get a debug output of what would happen. You have to be a bit careful with this because a new Exim daemon will use the new config. For small changes do it "inline", for major changes, copy the conf to a new name and specify it with -C and test until it works. There are a lot of options.Documentation is complete for Exim. If you find a flaw then Jeremy and co will fix it - the Exim devs are very, very driven, for want of a better word. You will get short shrift on the mailing lists if you obviously haven't tried to do any research but you will soon get some extremely knowledgable help if you show willing. No Disqus etc - just old school mailing lists and that is the way it should be.
The big boys are destroying SMTP gradually but it can and does still work, if you are careful.
EDIT: <formatting>
Ouch I never made this connection but now that you bring it up, I can't unsee it.
Not that the whole thing was very well handled.
So much could be learned in modern *nix distributions from this philosophy...