7 ms·
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
by cryptonector 7y ago
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 respect -- I have found far too many security vulnerabilities just from staring at C source code to do anything else. Now, I too have "learned more C" over the years, but I wouldn't write a sentence like that as part of justification for some project written in C -- I would fear that others would wonder if I don't just know enough C to be dangerous. Perhaps one should not write "I've learned more C" as part of anything other than justification for moving to Rust.
- stonogo 7y agoPostfix 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.
- pmoriarty 7y agoIt would be really useful to have an exhaustive list of all these things that qmail can do that other MTA's can't.
- pilif 7y agoit 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.
- amaccuish 7y agoI'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, webmaster) etc, that some services use for domain ownership verification. As an aside I do hope qmail offers similar limiting abilities. It wouldn't be great if a user could make themselves receive webmaster@domain.tld emails!
- schmonz 7y agoThey 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.
- amaccuish 7y agoSorry 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?
- schmonz 7y agoPeople can put whatever they want in their own .qmail files. That doesn't affect anything unless qmail believes those .qmail files are relevant to what it's delivering. A user controls .qmail files for a domain if and only if an admin has configured qmail to delegate that domain to that user.
- amaccuish 7y agoAhh I see. So it's a per domain thing, and you can't restrict more granularly. That's a shame.
- 7y ago
- Tepix 7y agoThe standard postfix setup these days uses a DB backend and users can edit the database to create new email addresses and aliases.
- schmonz 7y agoHey 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 met Wietse). It’s just that some of us really like qmail. :-)
- xvilka 7y agoYes, Rust is a perfect fit for such a project.
- tptacek 7y agoNot 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.
- atq2119 7y agoIf all you care about it is memory safety, sure. If you also care about performance, I'd be skeptical of such claims.
- pilif 7y agofor 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
- stevekemp 7y agoA 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/ http://smtpd.github.io/qpsmtpd/
- peterwwillis 7y agoThis reads a bit like if you posted that you were going to restore your Camaro Z28 with modern parts, and someone replied, "Why not a Corvette?"
- sigil 7y agoPostfix 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 taken though! [0] https://www.cvedetails.com/vulnerability-list.php?vendor_id=8450&product_id=14794 https://www.cvedetails.com/vulnerability-list.php?vendor_id=... [1] https://www.cvedetails.com/vulnerability-list.php?vendor_id=16391 https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
- linsomniac 7y agoCan 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.
- sigil 7y agoFine, 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.
- pilif 7y ago> 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.
- gypsyharlot 7y agohttps://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...
- cryptonector 7y agoI think that blog is wrong. Rust is not a magical language. It's just got the right features to be a C replacement, which is mostly: a simple type system (much simpler than C++'s or Java's) that has the right extensibility (traits, no inheritance) and can have an ABI that programmers can reason about due to monomorphization (no v-table dispatch). All the borrow checker stuff amounts to: just enough pain that to avoid it you must design better APIs.
- schmonz 7y agoYep, after reading the post I'm not any less impressed by (or interested in) Rust. If the post's claim were "Wait until Rust changes more slowly before investing more heavily in it," I might be able to agree. For a project like notqmail, I would worry about portability. qmail runs on a lot of platforms and getting Rust bootstrapped is a bear.
- cryptonector 7y agoFor any new MTA/MSA you don't need to run on old HP-UX systems. You can elect to only run on systems that support Rust, which is to say: all the modern OSes.
- schmonz 7y agoYou wanna write a new MTA from scratch? Me neither :-p
- cryptonector 7y agoEh, maybe. With Rust it's plausible to rebuild piece by piece.