schmonz

9 ms·

1.
Notqmail 1.09 Released(notqmail.org)
1 points by schmonz 2y ago|0 comments
2.
pkgsrc on macOS: Still Works(schmonz.com)
2 points by schmonz 2y ago|0 comments
3.
by schmonz 3y ago
The NetBSD Project is pleased to announce NetBSD 10.0, the eighteenth major release of the NetBSD operating system. It represents cumulative improvements to the operating system since NetBSD 9.x was originally branched in 2019.
4.
NetBSD 10.0 Released(netbsd.org)
131 points by schmonz 3y ago|61 comments
5.
by schmonz 6y ago
We’ve released notqmail 1.08, addressing these vulnerabilities (among other things). HN discussion thread for the 1.08 release: https://news.ycombinator.com/item?id=23252421
6.
Notqmail 1.08 Released(notqmail.org)
6 points by schmonz 6y ago|0 comments
7.
by schmonz 7y ago
I haven't experienced a need for more granular restrictions. Can you give an example of a problem it would solve?
8.
by schmonz 7y ago
You wanna write a new MTA from scratch? Me neither :-p
9.
by schmonz 7y ago
P.S. On the acceptutils page, check out the POP3 hole I found :-)
10.
by schmonz 7y ago
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&quo
11.
by schmonz 7y ago
Thank you!
12.
by schmonz 7y ago
Sorry, we think it's rested plenty long enough :-) 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 -- fo
13.
by schmonz 7y ago
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 proje
14.
by schmonz 7y ago
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 yo
15.
by schmonz 7y ago
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 trivia
16.
by schmonz 7y ago
Yes, and while I haven't run s/qmail myself, I have sometimes borrowed (and then usually refactored) some of his code, and have frequently collaborated with him on improving ucspi-tcp6, ucspi-ssl, etc. I'm still hoping he&#x2
17.
by schmonz 7y ago
People 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 a
18.
by schmonz 7y ago
Yes, for a long time it's been the case that to run qmail you have to really really want to run qmail. That's why I put so much effort for so many years into cross-platform packages of qmail in pkgsrc, and that's why we have
19.
by schmonz 7y ago
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.
20.
by schmonz 7y ago
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 roa
21.
by schmonz 7y ago
Extensibility is [an explicit goal]( https://github.com/notqmail/notqmail/wiki#goals ), for reasons such as these. If we introduce some more small interfaces -- 1998 qmail was already ripe with examples -- we'l
22.
by schmonz 7y ago
Yes, exactly right. One other PR left to merge, then we'll update the docs and cut 1.07.
23.
by schmonz 7y ago
"This implementation" is notqmail, which none of the netqmail people are involved in. netqmail 1.06, which none of us notqmail people were involved in, was produced by a handful of people I have often referred to as "list eld
24.
Maintaining Qmail in 2019(youtube.com)
1 points by schmonz 8y ago|0 comments
25.
by schmonz 10y ago
Writing Ikiwiki plugins is often very easy, because triggers for most events you'd want to get involved in are available, and because much of Ikiwiki's own functionality is implemented as plugins. Reading and understanding interna
26.
by schmonz 12y ago
I recently spent 4.5 years at a big bank developing identity-management tools. They were written in Perl. The first thing I did was screw up in production: http://www.schmonz.com/2014/06/01/tdd-in-context-1-ke
27.
by schmonz 13y ago
Sure, pkgsrc has made it easy to manage third-party software on Mac OS X for over a decade. Lots of other platforms too, with root or without. Homebrew is cool, but I'm pretty happy about being able to use the same package manager ever
28.
by schmonz 13y ago
If you think OS X's approach has done away with it, you're wrong. Maybe you've found it a worthwhile tradeoff, but flattening each application's dependency tree is still a tradeoff: you get truly independent applications
29.
by schmonz 13y ago
Upstream developers don't know best, either. Packagers sometimes make bad decisions, just like upstream does, because we're all people. "Install our software the way we think you should" is a point of view, but not a ver