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

31–40 of 75 posts

Re: Announcing Notqmail

#31

Post by pilif »

geocar wrote: post #30
pilif wrote: post #29

Earlier quoted context omitted.

> 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.

Aside of the fact that I doubt your "most people" assertion here, it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix.

Because if you disable a feature you don't use, you won't be affected by the vulnerability.

If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot. If you don't use smtp authentication then that CVE is inconsequential and you can't count it as a black mark against Postfix with regards to the security of your specific setup.

Re: Announcing Notqmail

#32

Post by sigil »

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…

> You don't find that vulnerability in qmail because qmail doesn't have that feature.

But being selective about what features to add is itself a valid strategy for writing secure software — perhaps even the most effective one!

Re: Announcing Notqmail

#33

Post by Tepix »

stonogo wrote: post #8
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 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.

The standard postfix setup these days uses a DB backend and users can edit the database to create new email addresses and aliases.

Re: Announcing Notqmail

#34

Post by [deleted] »

sigil wrote: post #32
pilif wrote: post #29

Earlier quoted context omitted.

> 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…

> You don't find that vulnerability in qmail because qmail doesn't have that feature. But being selective about what features to add is itself a valid strategy for writing secure software — perhaps even the most effective one!

[deleted]

Re: Announcing Notqmail

#35

Post by stevekemp »

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.

A few years back I ran `qpsmtpd` which is a flexible mailserver written in Perl. It was extremely easy to hack upon, so you could write plugins for SMTP-time spam-detection, rejection, etc.

These days the project is stalled, I think most of the development moved over to a nodejs based project.

Anyway the project was pretty simple to work with, and scaled wonderfully:

http://smtpd.github.io/qpsmtpd/

Re: Announcing Notqmail

#36

Post by pilif »

sigil wrote: post #32
pilif wrote: post #29

Earlier quoted context omitted.

> 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…

> You don't find that vulnerability in qmail because qmail doesn't have that feature. But being selective about what features to add is itself a valid strategy for writing secure software — perhaps even the most effective one!

I agree. But if the software is lacking essential features so that everybody patches them back in it's a very ineffective strategy because anybody's home-grown patches are worse than properly maintained features.

I can put a machine on the net with a closed port 25. That's the most minimal implementation of an MTA and it's entirely secure. Guaranteed.

The thing is that qmail was severely lacking features back in the 90ies and it has received zero feature additions by its original author since then, so it's safe to assume that it's now lacking even more features to the point where anybody running qmail these days is nearly guaranteed to be running franken-qmail full of third-party patches which are surely less well maintained than proper Postfix.

That was my point.

Re: Announcing Notqmail

#37

Post by gypsyharlot »

xvilka wrote: post #17
schmonz wrote: post #9

Earlier quoted context omitted.

Hey dude! Been a little while. Hope you’re well. If we were starting from scratch, I’d be first to say let’s pick something safer than C. But we’re starting from where DJB left off, so there’s not much left to decide about language. Our roadmap aims to provide mostly Unix-process extension points such that new code can be written in any language. Postfix is great, and I certainly hold Viktor in high regard (haven’t m…

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

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...

Re: Announcing Notqmail

#38

Post by gypsyharlot »

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…

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...

Re: Announcing Notqmail

#39

Post by genghizkhan »

I run my own email server as well, and I've been using postfix/dovecot quite happily with zero issues. I've been contemplating opensmtpd as well, though I'm not sure where that stands when it comes to being run in production environments. Also, reconfiguring mailservers is a PITA, I'd rather stick with a setup which just works.

Could someone explain why one might want to use qmail (or this, its newest incarnation) over postfix or opensmtpd? Would I gain anything by shifting to qmail or opensmtpd?

Re: Announcing Notqmail

#40

Post by amaccuish »

schmonz wrote: post #14
amaccuish wrote: post #12

Earlier quoted context omitted.

I've got a similar thing with my postfix setup though. My users can go to their account portal and apply for an alias, which when approved (to avoid taking of important names like postmaster etc.) is added to their otherMailboxes LDAP attribute. They can delete the alias themselves when they're done with it. I'm tempted to start auto-allowing new aliases and just having a list of names that can't be used (postmaster,…

They can’t, unless qmail has been configured to know they control mail for domain.tld. The admin configuration mechanism for this (control/virtualdomains) is simple and powerful.

Sorry I'm confused. If your mail server is setup for control of a domain (e.g. domain.tld), then what stops someone from putting postmaster@domain.tld in this .qmail file?
Post reply on HN