Live data from Hacker News

Announcing Notqmail

schmonz.com

61–70 of 75 posts

Re: Announcing Notqmail

#61
post #58

Earlier quoted context omitted.

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…

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

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

Re: Announcing Notqmail

#62
post #52

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 will be a lot of work, no question about that. Fortunately none of it will be about Maildir, as folks like you have long since ironed out all those issues (thanks!). 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…

I wish you the best of luck with the project, I hope you are able to achieve all your goals.

Re: Announcing Notqmail

#63
post #53

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…

For the moment, we're targeting sysadmins who already run qmail (or netqmail). Much later, when we begin to approach feature parity with Postfix, notqmail might start being an interesting alternative. We hope that time will come. If you can't figure out why you'd run it right now, you're probably right :-)

Thank you! I will definitely keep a weather eye on this project! :)

Re: Announcing Notqmail

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

Agreed. Having had the opportunity to encounter, use, setup, and then later on, read the code and learn from qmail early on in my computer career I think it helped learn about proper system design with an eye towards security. Back when qmail was released there was nothing like it, the most popular MTA at the time was Sendmail and we all know how great that was :)

qmail had a great impact on system design for many years and especially in the mail delivery area. Things like Maildir redefined how even MUAs store and use email. djbdns also provided a breath of fresh air at the time it was released, worked much faster and much more secure than something like bind.

DJB also had many other (likely even more impactful) roles in the software industry, leading the fight against the encryption software export restrictions of the 90s.

https://en.wikipedia.org/wiki/Daniel_J._Bernstein

Re: Announcing Notqmail

#65
post #52

Earlier quoted context omitted.

It will be a lot of work, no question about that. Fortunately none of it will be about Maildir, as folks like you have long since ironed out all those issues (thanks!). 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…

I wish you the best of luck with the project, I hope you are able to achieve all your goals.

Thank you!

Re: Announcing Notqmail

#66

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'm an opensmtpd developer.

As far as opensmtpd is concerned, it is production ready and has been used in high volume environments sending mails to millions of recipients daily, handling multi-million queues.

The project was started in 2008 so when it comes to being run in production environments, I think we can claim that it's ready :-)

Now as for the what you would gain, I won't do proselytism, we have published a couple presentations on our website which describe how it works and some of the technical details behind it. You will also find lots of technical details on my blog where I post mostly about OpenSMTPD internals.

If you have a running Postfix, I suggest you don't shift but keep your working setup. If you intend to setup a new MX, you should definitely give a try and see how it goes for you.

Re: Announcing Notqmail

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

Hey! I'd not noticed you were involved. EDIT: Where are my manners. Hope you're well too! 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 There's more stuff too (delivery op…

Vanilla qmail was never an open relay unless you really intended to configure it as one. It's just that the only relay controls were IP-based. Back in the day, before AUTH was widely supported, I used a really nice "relay-ctrl" add-on from Bruce Guenter for POP-before-SMTP.

For mandatory user-facing TLS and AUTH on port 587, and opportunistic server-to-server TLS on port 25, I've written https://schmonz.com/qmail/acceptutils. For SMTP recipient checks, I've written https://schmonz.com/qmail/rejectutils. It's too soon to say how notqmail will solve these problems, but they're solvable and we intend to solve them. For DANE... definitely not there yet.

Re: Announcing Notqmail

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

Hey! I'd not noticed you were involved. EDIT: Where are my manners. Hope you're well too! 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 There's more stuff too (delivery op…

P.S. On the acceptutils page, check out the POP3 hole I found :-)

Re: Announcing Notqmail

#69
post #58

Earlier quoted context omitted.

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

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

You wanna write a new MTA from scratch? Me neither :-p

Re: Announcing Notqmail

#70
post #69

Earlier quoted context omitted.

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

You wanna write a new MTA from scratch? Me neither :-p

Eh, maybe. With Rust it's plausible to rebuild piece by piece.
Post reply on HN