51–60 of 75 posts
Just wanted to add that Erwin Hoffmann has actively maintained s/qmail (and related djb tools) for quite some time. =) Please feel free to check his website: * http://www.fehcom.de/sqmail/sqmail.html
I have to wonder how much work is going to be required to bring qmail up to a modern standard. There's no doubt that the author is an extremely intelligent programmer with a deep focus on security. In the intervening period Postfix has really gained in popularity, and is shipped pre-configured out of the box on some major Linux distributions. It is the default MTA for Fedora/Redhat etc for some years now. I wanted to…
It's possible to package qmail in such a way that it's trivial to install and run, supporting many modern features by default. I've done it. Here's a demo: https://youtu.be/Vq6vu9T3vow
But that required a lot of decision-making and a lot of effort by the packager. With notqmail, we hope to make packaging much much easier.
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) ov…
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.
Any reason why you don't (can't?)?
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 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 library. this djb-ism has seriously affected a lot of the ways i unix, to date. envdir is…
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.
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...
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.
Earlier quoted context omitted.
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...
I 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…
For a project like notqmail, I would worry about portability. qmail runs on a lot of platforms and getting Rust bootstrapped is a bear.
Earlier quoted context omitted.
> saying "Postfix is worse because it had a security vulnerability in a component that qmail doesn't even support" is unfair to postfix. Ok, well that's your opinion, and hopefully now you at least know why I have mine. I can't imagine forgiving Microsoft for all those AD/SMB and explorer CVE just because Linux doesn't support those things, but it's not really that important to me. > In every enterprise setup I have…
>it sounds like you're talking about users relaying and not machines relaying there is such a thing as machine- or even application-specific accounts that can be terminated or their credentials rotated. Even better; you could use something like Vault ( https://www.vaultproject.io/ ) to manage such application-specific credentials. All of this is much better than relying on IP addresses never changing and never being…
You've given some excellent examples of how qmail got this way, and what notqmail needs to change to be viable. I have my own running-in-production solutions to most of them -- for instance, https://schmonz.com/qmail/rejectutils for SMTP recipient rejection and https://schmonz.com/qmail/acceptutils for user-facing AUTH and TLS.
These may or may not become part of notqmail. But we believe that together we can carefully and safely evolve notqmail to meet modern needs.
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…
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…
So, yeah, qmail is fine as a starting base, but there are important things that a modern MTA/MSA needs to have:
- MSAs need to support user authentication in
SUBMIT (no open relays)
- MTAs and MSAs need to support TLS
- MTAs should -really, need to- support DANE
for authenticating SMTP servers
I'm not sure that portability is such a problem that you can't use Rust. Rust runs on all modern OSes, which is all you need to support in a new MTA/MSA. And Rust is fairly easy to get into, actually.