Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Notqmail

schmonz.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Announcing Notqmail

#21

Post by linsomniac »

sigil wrote: post #13
cryptonector wrote: post #7

Why not Postfix? I trust Wietse V. and Viktor D. a great deal, and I trust their coding abilities at least as much as if not more than DJB's for anything that isn't a cryptographic algorithm. FYI, "I’ve learned more C, reduced build-time complexity, ..." probably isn't confidence-inspiring. I work with C a great deal and have for a very long time, and I though I'm very comfortable with C, I treat it with fear and res…

Postfix has had 9 CVEs in 20 years, a few of them quite bad. [0] qmail has had 1 CVE in 20 years, a local DoS. [1] I trust djb to write correct code more than almost any other human on the planet. That includes all the non-crypto code found in qmail, daemontools, dnscache, ucspi-tcp, etc. If you’ve read it, you know how almost supernaturally careful and minimal it is. Your points about mere mortals writing C are well…

Can you revise that "9" number, because looking at it I feel like some of those are inappropriately filed against postfix.

I find it hard to pin a "postfixadmin" CVE on postfix, are we going to blame vmailmgr bugs on qmail? :-) The BSDDB one I'm on the fence about. "postfix_groups.pl" is marked as disputed. Another seems to be clearly a Debian package issue.

CVE-2011-0411 is interesting because, IIRC, qmail had no SSL/TLS abilities, and the hacks you had to put into place to enable it were abominations and likely opened up issues of their own.

Re: Announcing Notqmail

#22

Post by yellow_postit »

sigil wrote: post #13
cryptonector wrote: post #7

Why not Postfix? I trust Wietse V. and Viktor D. a great deal, and I trust their coding abilities at least as much as if not more than DJB's for anything that isn't a cryptographic algorithm. FYI, "I’ve learned more C, reduced build-time complexity, ..." probably isn't confidence-inspiring. I work with C a great deal and have for a very long time, and I though I'm very comfortable with C, I treat it with fear and res…

Postfix has had 9 CVEs in 20 years, a few of them quite bad. [0] qmail has had 1 CVE in 20 years, a local DoS. [1] I trust djb to write correct code more than almost any other human on the planet. That includes all the non-crypto code found in qmail, daemontools, dnscache, ucspi-tcp, etc. If you’ve read it, you know how almost supernaturally careful and minimal it is. Your points about mere mortals writing C are well…

Just a count of CVE, while interesting, I think misses calibrating by how much attention each has gotten. Given its popularity I'd assume much more security research and testing on postfix.

Re: Announcing Notqmail

#23

Post by atq2119 »

tptacek wrote: post #19
xvilka wrote: post #17

Earlier quoted context omitted.

Yes, Rust is a perfect fit for such a project.

Not that I disagree, but to inject some clarity: Python would be a perfect fit too. The major MTAs are written in C not because they need to be, but because C was the only serious option in the mid-late 1990s. Any modern language would work.

If all you care about it is memory safety, sure.

If you also care about performance, I'd be skeptical of such claims.

Re: Announcing Notqmail

#24

Post by pilif »

sigil wrote: post #13
cryptonector wrote: post #7

Why not Postfix? I trust Wietse V. and Viktor D. a great deal, and I trust their coding abilities at least as much as if not more than DJB's for anything that isn't a cryptographic algorithm. FYI, "I’ve learned more C, reduced build-time complexity, ..." probably isn't confidence-inspiring. I work with C a great deal and have for a very long time, and I though I'm very comfortable with C, I treat it with fear and res…

Postfix has had 9 CVEs in 20 years, a few of them quite bad. [0] qmail has had 1 CVE in 20 years, a local DoS. [1] I trust djb to write correct code more than almost any other human on the planet. That includes all the non-crypto code found in qmail, daemontools, dnscache, ucspi-tcp, etc. If you’ve read it, you know how almost supernaturally careful and minimal it is. Your points about mere mortals writing C are well…

The moment you start patching qmail you're not running qmail any more. None of the CVE numbers are meaningful to your custom-patched qmail.

qmail was good when you could use it in its default configuration. Unfortunately, very few sites could (much less still can).

Which brings us to the question of who you trust more: The maintainers of a full-featured MTA who have maintained their software for 20 years or some person's patches to scratch their itch before moving on and never touching it again?

Re: Announcing Notqmail

#25

Post by pilif »

atq2119 wrote: post #23
tptacek wrote: post #19

Earlier quoted context omitted.

Not that I disagree, but to inject some clarity: Python would be a perfect fit too. The major MTAs are written in C not because they need to be, but because C was the only serious option in the mid-late 1990s. Any modern language would work.

If all you care about it is memory safety, sure. If you also care about performance, I'd be skeptical of such claims.

for all sites memory safety trumps performance.

For most sites, performance is a total non-issue for providing the feature-set that qmail provided.

And if you are a site that processes enough email for performance to start becoming an issue, you're probably better off with a custom solution that's tailored to your specific issues

Re: Announcing Notqmail

#26

Post by pilif »

pmoriarty wrote: post #11
stonogo wrote: post #8

Earlier quoted context omitted.

Postfix cannot do what qmail can do. Specifically, users can create and destroy email addresses themselves with .qmail files. This is different and more powerful than Google's plus-addressing approach. There are many, many other features of qmail's implementation that Postfix cannot compete with. Postfix is not alone in this; no other MTA/MDA can do what qmail can do.

It would be really useful to have an exhaustive list of all these things that qmail can do that other MTA's can't.

it would be a very small list.

However, the exhaustive list of things other MTAs can do that qmail can't would be huge (starting with backscatter-proof bounces for example)

qmail was limited back in the 90ies and it's horribly behind the times now.

Re: Announcing Notqmail

#27

Post by ahje »

dsr_ wrote: post #4

I used qmail for about ten years. It was remarkably good from a sysadmin's perspective: - the config system mostly used the name of a directory where lots of software would use a filename (qmail.ini => /var/qmail/conf), the name of a file where other software would use a variable name, and the contents of the file as the value of the variable. This is really, really easy to read and write without writing a parsing li…

The question is if notqmail isn't a bit too late. I'm maintaining a qmail setup for a customer and the amount of duct tape we've put on that thing is rather ridiculous. As it is now, I'd rather replace the whole thing with a regular Postfix/Dovecot setup and be done with it.

Re: Announcing Notqmail

#28

Post by sigil »

linsomniac wrote: post #21
sigil wrote: post #13

Earlier quoted context omitted.

Postfix has had 9 CVEs in 20 years, a few of them quite bad. [0] qmail has had 1 CVE in 20 years, a local DoS. [1] I trust djb to write correct code more than almost any other human on the planet. That includes all the non-crypto code found in qmail, daemontools, dnscache, ucspi-tcp, etc. If you’ve read it, you know how almost supernaturally careful and minimal it is. Your points about mere mortals writing C are well…

Can you revise that "9" number, because looking at it I feel like some of those are inappropriately filed against postfix. I find it hard to pin a "postfixadmin" CVE on postfix, are we going to blame vmailmgr bugs on qmail? :-) The BSDDB one I'm on the fence about. "postfix_groups.pl" is marked as disputed. Another seems to be clearly a Debian package issue. CVE-2011-0411 is interesting because, IIRC, qmail had no SS…

Fine, let’s call it 7, since postfixadmin & the debian postinst script can’t be attributed to postfix proper.

I’m not sure this qualitatively changes the argument. CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code.

Re: Announcing Notqmail

#29

Post by pilif »

sigil wrote: post #28
linsomniac wrote: post #21

Earlier quoted context omitted.

Can you revise that "9" number, because looking at it I feel like some of those are inappropriately filed against postfix. I find it hard to pin a "postfixadmin" CVE on postfix, are we going to blame vmailmgr bugs on qmail? :-) The BSDDB one I'm on the fence about. "postfix_groups.pl" is marked as disputed. Another seems to be clearly a Debian package issue. CVE-2011-0411 is interesting because, IIRC, qmail had no SS…

Fine, let’s call it 7, since postfixadmin & the debian postinst script can’t be attributed to postfix proper. I’m not sure this qualitatively changes the argument. CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code.

> CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code.

CVE-2011-1720 is related to SMTP authentication which qmail doesn't support out-of-the box. So. Yes you're right: You don't find that vulnerability in qmail because qmail doesn't have that feature.

Can you run an SMTP server without authentication these days? Not if you have users using you as a relay. So I guess you have to custom patch qmail and now you're back to not running djb code in the first place.

CVE-2008-2936 I grant you. Though once we are at doing hardlinks to symlinks, we might hit other edge-cases too, some might even affect qmail in some way.

Re: Announcing Notqmail

#30

Post by geocar »

pilif wrote: post #29
sigil wrote: post #28

Earlier quoted context omitted.

Fine, let’s call it 7, since postfixadmin & the debian postinst script can’t be attributed to postfix proper. I’m not sure this qualitatively changes the argument. CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code.

> CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably expects to find, in djb code. CVE-2011-1720 is related to SMTP authentication which qmail doesn't support out-of-the box. So. Yes you're right: You don't find that vulnerability in qmail because qmail doesn't have that feature. Can you run an SMTP server without authentication these days? Not if you have users using you as…

Road warriors with Thunderbird may need SMTP authentication, but most people do relaying with just IP authentication just fine.
Post reply on HN