Mailing List Archive

Hello Amitai,

Am 20.06.20 um 23:19 schrieb Amitai Schleier:
> You probably saw here a month ago that we’ve shipped notqmail 1.08 with fixes for the Qualys-reported vulnerabilities and for a longstanding security bug in qmail-pop3d, among other changes (details: https://notqmail.org/1.08).
>
> It’s been gratifying for us to hear from people who are using notqmail. As we work toward 1.09 and beyond, it’d help us to hear from folks who have
>
> - Updated to notqmail (yay!)
> - Tried and failed to update (what blew up?)
> - Decided not to try yet (what were your reasons?)
the latter one - you have been too late ;)

I ran a gentoo/netqmail toaster that needed migration to new hardware
and after waiting about a year to let the announced "joined forces"
x/qmail happen I finally went with sqmail as it seemed to be the most
suitable alternative at this point in time. Its not perfect and I really
miss some things I need to workaround with clumsy hacks but Erwin is
always helpful, fast responding and the core system does a good job.

I still would be happy to see a "new qmail" with a stable maintainer
base and would be willing to migrate if there are benefits but at least
for me there wouldnt be any benefits doing so now.

best regards

Oli

--
Protect your environment - close windows and adopt a penguin!

On Sat, Jun 20, 2020 at 11:19:25PM +0200, Amitai Schleier wrote:
> - Decided not to try yet (what were your reasons?)

I'm running the FreeBSD package with custom scripts and CRAM support
removed. I agree with djb's original assessment of the mentioned
configuration problems, so I'm not really worried about that.

I'm waiting to see how issue #115 ("Convert the code to Rust") is
resolved. I would not like to maintain a menagerie of LLVM frontends to
build my infrastructure, so if notqmail is going to move away from C, I
want to know that before I depend upon it.

I'm also watching issue #2 ("Relook at /var/qmail for everthing"). FHS
is mostly dead and the few changes they're actually discussing are all
driven by freedesktop.org. Most of the current proposals are explicitly
not cross-platform, even amongst Linux distributions. Again, I'm not
urging any decisions one way or the other, but if the project goals
prioritize ease of use on Linux then it's not the right fit for me.

My existing installation is extremely stable and I'm not unhappy with
it. I am glad notqmail exists as a project and I'm perfectly happy to
wait as long as necessary to see how things unfold.

khm

On 23 Jun 2020, at 8:18, Oliver Welter wrote:

> Am 20.06.20 um 23:19 schrieb Amitai Schleier:
>
>> It’s been gratifying for us to hear from people who are using
>> notqmail. As we work toward 1.09 and beyond, it’d help us to hear
>
> I finally went with sqmail as it seemed to be the most
> suitable alternative at this point in time. Its not perfect and I
> really
> miss some things I need to workaround with clumsy hacks but Erwin is
> always helpful, fast responding and the core system does a good job.

Agreed, I always appreciate my interactions with him. I haven't gotten
to try s/qmail yet but I've consulted (and borrowed from :-) its code
more than once, and am relying on ucspi-ssl and ucspi-tcp6.

> I still would be happy to see a "new qmail" with a stable maintainer
> base and would be willing to migrate if there are benefits but at
> least
> for me there wouldnt be any benefits doing so now.

For former qmail and netqmail users with relatively basic setups, we're
hearing that notqmail already represents this upgrade path. For those of
you with larger investments in custom code, we know we have some ground
to make up before the potential benefit of migrating is worth the
potential cost.

One thing you (not just Oli but anyone) could easily do to help
notqmail, if you're so inclined: make sure the features you need are on
our radar. Check our plans for 1.09 and beyond at
<https://notqmail.org>, file a GitHub issue at
<https://github.com/notqmail/notqmail>, or just reply on- or off-list
with what's important to you in your current setup. That way we can plan
to make notqmail more interesting to you over time.

Thanks,

- Amitai

On 23 Jun 2020, at 9:40, Kurt H Maier wrote:

> I'm waiting to see how issue #115 ("Convert the code to Rust") is
> resolved. I would not like to maintain a menagerie of LLVM frontends
> to
> build my infrastructure, so if notqmail is going to move away from C,
> I
> want to know that before I depend upon it.

When that one showed up in our issue queue, I was quite surprised. I
mean, it's interesting. If security is one of qmail's most-valued
properties, C is a known dangerous implementation language, and qmail
has recently had a scare because of it, then we can't categorically rule
out the idea. But it would be a very costly tradeoff. I don't think we
have any notqmail developers who are eager to even evaluate Rust in our
project's context. Maybe much later. There's plenty of
easier-to-justify, easier-to-ship improvement (including tooling to
support our security goals) right in front of us.

> I'm also watching issue #2 ("Relook at /var/qmail for everthing"). FHS
> is mostly dead and the few changes they're actually discussing are all
> driven by freedesktop.org. Most of the current proposals are
> explicitly
> not cross-platform, even amongst Linux distributions. Again, I'm not
> urging any decisions one way or the other, but if the project goals
> prioritize ease of use on Linux then it's not the right fit for me.

I'm not aware of that one being actively worked on. I'm perfectly happy,
personally, with my /var/qmail full of symlinks pointing to
hier(7)-compatible locations. Once I made pkgsrc's qmail package do this
(upwards of 15 years ago) I never needed anything further. For what it's
worth, at least one of the notqmail developers is also a NetBSD
developer. :-)

> My existing installation is extremely stable and I'm not unhappy with
> it. I am glad notqmail exists as a project and I'm perfectly happy to
> wait as long as necessary to see how things unfold.

We figure most folks running qmail have gotten used to not changing it
very often, and so we expect not everyone is falling over themselves to
try something different. Eminently reasonable, of course. I probably
wouldn't have the round tuits to try it yet myself if it were someone
else's project ;-)

Please do stay tuned.

Thanks,

- Amitai

Hello Amitai,

Am 05.07.20 um 22:20 schrieb Amitai Schleier:
> On 23 Jun 2020, at 8:18, Oliver Welter wrote:
>
>> Am 20.06.20 um 23:19 schrieb Amitai Schleier:

> One thing you (not just Oli but anyone) could easily do to help
> notqmail, if you're so inclined: make sure the features you need are on
> our radar. Check our plans for 1.09 and beyond at
> <https://notqmail.org>, file a GitHub issue at
> <https://github.com/notqmail/notqmail>, or just reply on- or off-list
> with what's important to you in your current setup. That way we can plan
> to make notqmail more interesting to you over time.
>
I did not look at notqmail recently as I was already away so those
points might be already adressed but the main problem - that I also have
with sqmail - is proper support for a "multi-domain" setup, if possible
with direct SQL access and no need for one of this also outdated
backends (I still fiddle around with vpopmail).

The second big issue is abuse prevention in terms of rate-limiting
senders or password-brute-force attemps and on the sending side the
DKIM/SRS stuff.

I will try to have a look into netqmail and provide some more elaborated
feedback.

best regards

Oliver


--
Protect your environment - close windows and adopt a penguin!