Err 507 - Too many patches.
Jens Bauer
I've been satisfied with the netqmail-1.06 for a long time.
But now I need to add WebMail (Dovecot and SquirrelMail); so I started
modifying my poor netqmail.
I found out I'd need SMTP-AUTH and perhaps TLS would be a good idea as
well (even though I will probably only use IMAP with Dovecot on the LAN).
I also need qmail-remote AUTH-LOGIN, so I can relay a couple of users
through my ISP.
After around 4 days of focused work, I had Dovecot and SquirrelMail
installed, along with the TLS patch plus my old patches updated, so they
do not conflict with the TLS patch.
But when I needed the qmail-remote patch, I had to write the code on top
of the TLS patch, as the other qmail-remote patch would be placed in a
disabled block of code.
Unfortunately I'm a lousy programmer I guess (I used to think of myself
as knowing exactly what I'm doing, though). My ISP sent back a rant,
when I tried to relay my own mail to my own account at the ISP:
217.198.208.12 does not like recipient.
Remote host said: 503 5.5.1 Incorrect command sequence
Giving up on 217.198.208.12.
Uhm... What I'm trying to say is that it's becoming a bit cumbersome
handling all those patches.
It appears that many patches are based on the stock qmail-1.03, which of
course is good, but why not netqmail, which is the latest ?
I know that netqmail is not exclusively D.J. Bernstein's code, however,
I'd claim that the code includes a few fixes and is carefully updated.
-Furthermore, I'd say if patching it anyway, it's not the pure original
code anyway... ;)
What I'm wishing for is a git repository with an active netqmail, which
includes the functionality that various patches provides (and some try
to provide).
I've been at sf.net, but it seems there's no repository there.
Are anyone currently working on netqmail, or is the ship abandoned ?
(I'd kinda hate starting a new repository, to make the sources and
patches drift further apart)
Love,
Jens
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
John Puttergill
> Hi all,
>
> I've been satisfied with the netqmail-1.06 for a long time.
> But now I need to add WebMail (Dovecot and SquirrelMail); so I started
> modifying my poor netqmail.
> I found out I'd need SMTP-AUTH and perhaps TLS would be a good idea as
> well (even though I will probably only use IMAP with Dovecot on the LAN).
> I also need qmail-remote AUTH-LOGIN, so I can relay a couple of users
> through my ISP.
handles all of your requirements, it offers a lot of features that you
may or may not want to incorporate, but gives you a fairly easy to
understand qmail-smtp run script (admittedly I had to spend quite a few
days reading and re-reading his documentation ... and have still not
managed to subscribe to his mailing list) ... you will find this the
closest to a complete distribution of qmail you can get, while still
based on qmail 1.03 rather than netqmail it incorporates all the patches
certainly to netqmail 1.05 plus all of his, which give you far greater
functionality in to-days environment. I have certainly had far fewer
issues since I adopted his combined patch available here
http://qmail.jms1.net/patches/combined-details.shtml
However all that said one seldom has any real issues with qmail in spite
of its 16 years in existence!!!
And thanks to all the people on this list and those who kept netqmail
alive for all these years.
Erwin Hoffmann
On Sun, 8 May 2011 19:22:43 +0200
"Jens Bauer" <qm...@bruger.mine.nu> wrote:
> Hi all,
>
> I've been satisfied with the netqmail-1.06 for a long time.
> But when I needed the qmail-remote patch, I had to write the code on top
> of the TLS patch, as the other qmail-remote patch would be placed in a
> disabled block of code.
I don't know, what kind of 'qmail-remote' patch you use ....
> Uhm... What I'm trying to say is that it's becoming a bit cumbersome
> handling all those patches.
> It appears that many patches are based on the stock qmail-1.03, which of
> course is good, but why not netqmail, which is the latest ?
> I know that netqmail is not exclusively D.J. Bernstein's code, however,
> I'd claim that the code includes a few fixes and is carefully updated.
> -Furthermore, I'd say if patching it anyway, it's not the pure original
> code anyway... ;)
A lot of people gave up qmail, because it is simply unusable these days.
Not because of the failure of DJB, but because of the patching it needs.
> What I'm wishing for is a git repository with an active netqmail, which
> includes the functionality that various patches provides (and some try
> to provide).
I guess, nobody is going for that.
> I've been at sf.net, but it seems there's no repository there.
Actually, I don't have the faintest idea, how many patches for qmail are around these days.
The main ones (sources; not compilations):
a) Andre Oppermann's qmail LDAP patch (+ concurrency).
b) Frederik Vermeulens TLS patch.
c) Manvendra Bhangui IndiMail (if you consider it a patch).
d) My Spamcontrol patch.
Unfortunately, these patches are pretty much incompatible with each other (however, IndiMail uses some features I have invented).
Plus a lot of special patches, providing recipient checking, SPF, DKIM and other features.
To my understanding,
i) SMTP Auth is a must,
ii) STARTTLS/TLS is a must,
iii) Recipients checking during the SMTP dialog is a must,
iv) we can argue about SPF, DKIM, and other issues -- however, these shall be 'pluggable' anyway.
Thus, please set up a table and check your requirements against the features of those major patches.
Unfortunately, in the qmail community there is no common understanding, how to carry on.
> Are anyone currently working on netqmail, or is the ship abandoned ?
> (I'd kinda hate starting a new repository, to make the sources and
> patches drift further apart)
regards.
--eh.
--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de
Erwin Hoffmann
On Sun, 08 May 2011 19:34:58 +0100
John Puttergill <jo...@itsjustit.co.uk> wrote:
> On 08/05/11 18:22, Jens Bauer wrote:
> I think you might find that John Simpson provides a combined patch that
> handles all of your requirements, it offers a lot of features that you
> may or may not want to incorporate, but gives you a fairly easy to
> understand qmail-smtp run script (admittedly I had to spend quite a few
> days reading and re-reading his documentation ... and have still not
> managed to subscribe to his mailing list) ... you will find this the
> closest to a complete distribution of qmail you can get, while still
> based on qmail 1.03 rather than netqmail it incorporates all the patches
> certainly to netqmail 1.05 plus all of his, which give you far greater
> functionality in to-days environment. I have certainly had far fewer
> issues since I adopted his combined patch available here
> http://qmail.jms1.net/patches/combined-details.shtml
That is *exactly* the way to bring qmail down the drain.
Simply merging a lot of buggy patches (look at the history) is certainly not what corresponds to DJB's level of quality.
Sorry.
> However all that said one seldom has any real issues with qmail in spite
> of its 16 years in existence!!!
Yeah. And spit on those, who are not using DJB coding rules within their patch.
Side note: Look at the DKIM bug in Exim.
>
> And thanks to all the people on this list and those who kept netqmail
> alive for all these years.
regards.
Manvendra Bhangui
>
> Hi all,
>
> I've been satisfied with the netqmail-1.06 for a long time.
> But now I need to add WebMail (Dovecot and SquirrelMail); so I started
> modifying my poor netqmail.
Hi. Nice seeing you here after a long time. I think we worked together
solving the bounce issue with netqmail on Mac OS X 10.5.
>
> What I'm wishing for is a git repository with an active netqmail, which
> includes the functionality that various patches provides (and some try
> to provide).
>
> I've been at sf.net, but it seems there's no repository there.
>
> Are anyone currently working on netqmail, or is the ship abandoned ?
> (I'd kinda hate starting a new repository, to make the sources and
> patches drift further apart)
>
I have been actively developing code for IndiMail which uses qmail as
the MTA. Whenever I see a good idea proposed / implemented by someone,
I steal it :). e.g I use quite may features invented by Erwin. I have
found his QHPSI the most elegant and efficient solution for virus
scanning. IndiMail enhances the QHPSI function further by giving you
the ability to load plugins. You will find most of the features (DKIM,
Domainkeys, BATV, TLS, SMTP Auth). IndiMail also provides a hook to
NSS which allows you to integrate any IMAP/POP3 server which uses PAM
or getpw() functions to integrate with IndiMail without modifying a
single line of code anywhere. If I have modified/added any code to
qmail, it has been done using djb functions only. No stdio.h, no
string.h, etc
http://indimail.blogspot.com/2010/04/configuring-dovecot-with-indimail.html
I have a git repository too and you can clone it.
git clone git://indimail.git.sourceforge.net/gitroot/indimail/indimail
The source code is Open Source and Free. You can use the source or
binary (RPM/Deb) for most Linux distros at openSUSE build service.
Pop User
> Hi John (sorry for the double post),
>
> On Sun, 08 May 2011 19:34:58 +0100
> John Puttergill <jo...@itsjustit.co.uk> wrote:
>
>> On 08/05/11 18:22, Jens Bauer wrote:
>
>> I think you might find that John Simpson provides a combined patch that
>> handles all of your requirements, it offers a lot of features that you
>> may or may not want to incorporate, but gives you a fairly easy to
>> understand qmail-smtp run script (admittedly I had to spend quite a few
>> days reading and re-reading his documentation ... and have still not
>> managed to subscribe to his mailing list) ... you will find this the
>> closest to a complete distribution of qmail you can get, while still
>> based on qmail 1.03 rather than netqmail it incorporates all the patches
>> certainly to netqmail 1.05 plus all of his, which give you far greater
>> functionality in to-days environment. I have certainly had far fewer
>> issues since I adopted his combined patch available here
>> http://qmail.jms1.net/patches/combined-details.shtml
>
> That is *exactly* the way to bring qmail down the drain.
>
> Simply merging a lot of buggy patches (look at the history) is certainly not what corresponds to DJB's level of quality.
>
> Sorry.
>
I'm a bit floored to hear you say that. What is Spamcontrol if not a collection of patches? Yes several of the patches are written by you but many of the patches come from elsewhere and I found such terrible failures in Spamcontrol 2.5 I had to revert to 2.4. I have been considering where to go next and have been considering the jms1 patch since when I report problems to you you try to tell me that obvious bugs aren't bugs. Specifically the Spamcontrol problems with mfcheck which the original mfcheck patch did not have.
Quoting you...
> I just reproduced your error report:
>
> Connected to mail.fehcom.de.
> Escape character is '^]'.
> 220 mail.fehcom.net ESMTP
> helo greatamericanbabies.com
> 250 mail.fehcom.net
> mail from: <spa...@greatamericanbabies.com>
> 451 DNS temporary failure (#4.3.0)
> 250 ok
> quit
> 221 mail.fehcom.net
>
> Well you are right: This is an issue.
>
> However, I don't consider this a bug. DNS temporary errors happen all over the time.
> DNS uses UDP, UDP uses IP; both are unreliable protocols.
>
You don't consider a 451 error followed by a 250 a bug? What on earth is it? When is it valid for a mail server to return TWO results for a single operation? It completely breaks pipelining. The exact same situation existed with a recipient check failure giving a 421 then immediately a 250. You said "Actually, at that point it is not clear, what should happen." It may no be clear if it should be a temp failure or allowed through but it is certainly clear that it MUST BE ONE OR THE OTHER. Prior to that you had a bug that caused any error code returned from qmail-queue to hang other than 32 or 33. Your response was "Actually; I don't consider this as a bug rather a feature (works as designed)." A feature? If qmail-queue were to return error 53 (Write error; e.g., disk full.) it is a FEATURE that that smtp connection should hang forever?
Sure the jms1 patch has a lot of bugs in his history file and you don't. That could be because you don't consider ANYTHING A BUG.
I am still on 2.4 because of my failure to convince you that there were problems with 2.5 and haven't spent the time to review both 2.6 and the jms1 patch and decide which to switch to or perhaps just patching everything myself. My experience with John Simpson when I was trying to use his mkvalidrcptto script was excellent. My experience with you regarding obvious problems with Spamcontrol was a failure on my part to convince you that OBVIOUS bugs were even bugs.
kristen
Despite comments against John's work with qmail, I have found
his patches to be all I need and qmail functions well.
Kristen
Erwin Hoffmann
On Mon, 09 May 2011 12:31:46 -0400
Pop User <pop...@christest2.dc.k12us.com> wrote:
> On 5/8/2011 3:16 PM, Erwin Hoffmann wrote:
> > Hi John (sorry for the double post),
> >
> > On Sun, 08 May 2011 19:34:58 +0100
> > John Puttergill <jo...@itsjustit.co.uk> wrote:
> >
> >> On 08/05/11 18:22, Jens Bauer wrote:
> >
> >> I think you might find that John Simpson provides a combined patch that
> >> handles all of your requirements, it offers a lot of features that you
> >> may or may not want to incorporate, but gives you a fairly easy to
> >> understand qmail-smtp run script (admittedly I had to spend quite a few
> >> days reading and re-reading his documentation ... and have still not
> >> managed to subscribe to his mailing list) ... you will find this the
> >> closest to a complete distribution of qmail you can get, while still
> >> based on qmail 1.03 rather than netqmail it incorporates all the patches
> >> certainly to netqmail 1.05 plus all of his, which give you far greater
> >> functionality in to-days environment. I have certainly had far fewer
> >> issues since I adopted his combined patch available here
> >> http://qmail.jms1.net/patches/combined-details.shtml
> >
> > That is *exactly* the way to bring qmail down the drain.
> >
> > Simply merging a lot of buggy patches (look at the history) is certainly not what corresponds to DJB's level of quality.
> >
> > Sorry.
> >
>
> I'm a bit floored to hear you say that. What is Spamcontrol if not a collection of patches?
Yes. This was up to version 2. Starting with this version, I tried to implement some basics, which I thought are missing.
This is in the History file.
> Yes several of the patches are written by you but many of the patches come from elsewhere and I found such terrible failures in Spamcontrol 2.5 I had to revert to 2.4. I have been considering where to go next and have been considering the jms1 patch since when I report problems to you you try to tell me that obvious bugs aren't bugs. Specifically the Spamcontrol problems with mfcheck which the original mfcheck patch did not have.
Maybe. I don't know out of my head.
> Quoting you...
>
> > I just reproduced your error report:
> >
> > Connected to mail.fehcom.de.
> > Escape character is '^]'.
> > 220 mail.fehcom.net ESMTP
> > helo greatamericanbabies.com
> > 250 mail.fehcom.net
> > mail from: <spa...@greatamericanbabies.com>
> > 451 DNS temporary failure (#4.3.0)
> > 250 ok
> > quit
> > 221 mail.fehcom.net
> >
> > Well you are right: This is an issue.
Sure.
> > However, I don't consider this a bug. DNS temporary errors happen all over the time.
> > DNS uses UDP, UDP uses IP; both are unreliable protocols.
> You don't consider a 451 error followed by a 250 a bug? What on earth is it? When is it valid for a mail server to return TWO results for a single operation? It completely breaks pipelining. The exact same situation existed with a recipient check failure giving a 421 then immediately a 250. You said "Actually, at that point it is not clear, what should happen." It may no be clear if it should be a temp failure or allowed through but it is certainly clear that it MUST BE ONE OR THE OTHER. Prior to that you had a bug that caused any error code returned from qmail-queue to hang other than 32 or 33. Your response was "Actually; I don't consider this as a bug rather a feature (works as designed)." A feature? If qmail-queue were to return error 53 (Write error; e.g., disk full.) it is a FEATURE that that smtp connection should hang forever?
Certainly not.
> Sure the jms1 patch has a lot of bugs in his history file and you don't. That could be because you don't consider ANYTHING A BUG.
This is not true. See the Errata section on Spamcontrol's web site.
> I am still on 2.4 because of my failure to convince you that there were problems with 2.5 and haven't spent the time to review both 2.6 and the jms1 patch and decide which to switch to or perhaps just patching everything myself. My experience with John Simpson when I was trying to use his mkvalidrcptto script was excellent. My experience with you regarding obvious problems with Spamcontrol was a failure on my part to convince you that OBVIOUS bugs were even bugs.
Feel free to do what ever you like.
----
As with many of us, we develop SW in our spare time. There is hardly anybody else actually (beta) testing or auditing the code.
Of course, obvious bugs and mistakes shall be avoided -- as much as possible. The problem -- what I tried to focus on in my first mail -- is the lack of a community to share the good ideas and implementations and sort out the less qualified solutions.
Look at the SMTP Auth stuff: The original implementation from Krysztof Dabrowski was taken from qmail-popup. This was ok, but the checkpassword interface was spoiled, among others flaws. With my current SMTP Auth implementation, now throughout qmail-smtpd and qmail-remote a full solution is provided. Check John Simpsons implementation. A Auth Username like "Erwin Hoffmann" simply won't work for qmail-remote.
We have so many concurrent solutions for a problem (you mentioned yourself the 'validrcptto') or a lack of a feature which makes it pretty difficult to obtain a streamlined and consistent solution -- putting different patches together.
At least, I started that path years from now.
Thus, I am not blaming John Simpsons' work (because this would be blaming myself, because he is using partially my stuff as well) but I'm certainly unsatisfied with the current level of diversification regarding qmail. To be honest: I participated in the development as well. Check my current (Start)TLS implementation for qmail-remote.
It would be helpful, if the qmail community would take the chance to support the active contributers.
Sorry for not solving your problems in the first place.
Pop User
>
> As with many of us, we develop SW in our spare time.
Yes, and we are thankful you do it. My response was based on one person who does work on qmail referring to another persons work on qmail as "*exactly* the way to bring qmail down the drain".
It is really uncalled for.
FLoh Leeber
as you are posting to a public mailing list I strongly request you to enter
a real name a your From address, especially if you are having such an
explicit point of view, that means, people not involved and not knowing you
until now (like me) get the impression that you are hiding yourself for
whatsoever reason.
regards FL
----- Original Message -----
From: "Pop User" <pop...@christest2.dc.k12us.com>
To: "Erwin Hoffmann" <f...@fehcom.de>
Cc: "John Puttergill" <jo...@itsjustit.co.uk>; "Jens Bauer"
<qm...@bruger.mine.nu>; "Qmail List" <qm...@list.cr.yp.to>
Sent: Monday, May 09, 2011 10:36 PM
Subject: Re: Err 507 - Too many patches.
> On 5/9/2011 3:28 PM, Erwin Hoffmann wrote:
>>
>> As with many of us, we develop SW in our spare time.
>
> Yes, and we are thankful you do it. My response was based on one person
> who does work on qmail referring to another persons work on qmail as
> "*exactly* the way to bring qmail down the drain".
>
> It is really uncalled for.
>
Jeremy Kister
> Hi all,
A bit OT, but I'm surprised no one else said:
i found your subject delightfully clever.
--
Jeremy Kister
http://jeremy.kister.net./
FLoh Leeber
I think the biggest disadvantage of qmail today is that it is not compatible
with how we all use Linux/Unix and how we want to maintain our systems. The
disallowance to bundle a binary package together with the fact that there is
de-facto no active development (and I consider making patches rather as a
cry for help than an indication for progress) normally would rule out such a
software completely.
I have been using qmail for several years now on a Debian server, and it is
the only package on it which requires intensive care when I want to change
something or add a feature. While the original limited features are working
very well, the world turned forward and today愀 mail handling gets always
more complicated. User want SSL, TLS, smtp auth etc. A mail server needs to
be a flexible pice of software.
The problem starts when installing the Debian source package for
compilation. The maintainer has already included some patches, and with
every other patch I have to add the merging gets more impossible. So I have
to ask myself every timeI get a *.rej file from patching: Why am I using
that stuff? Only because it supports Maildir format and integrates with
vpopmail so easily? Well, this can be done with others also...
Finally I will give qmail a last chance now: I will try one of those
all-in-one patches on the bare-metal 1.03 sources, and if it works, I will
never modify the installation again. If it fails, I will switch to a
supported package where I can press on my update button and lean back to
watch the show.
Dont take me wrong guys, I respect the effort of so many unpaid hours
invested in improving this stuff, but honestly, the gift of Dr. B to the
world is limited. It caused pain and headache for me already enough and even
if it is the worlds safest email server, it愀 complications in daily use can
be endless.
Its always the same with things coming from university: When they go beyond
being a proof-of-concept, most of them fail because the authors are too much
focused on the theoretical solution. But the masses need also soft features.
And social integration :-)
regards FL
----- Original Message -----
From: "John Puttergill" <jo...@itsjustit.co.uk>
To: "Jens Bauer" <qm...@bruger.mine.nu>
Cc: "Qmail List" <qm...@list.cr.yp.to>
Sent: Sunday, May 08, 2011 8:34 PM
Subject: Re: Err 507 - Too many patches.
> On 08/05/11 18:22, Jens Bauer wrote:
>> Hi all,
>>
>> I've been satisfied with the netqmail-1.06 for a long time.
>> But now I need to add WebMail (Dovecot and SquirrelMail); so I started
>> modifying my poor netqmail.
>> I found out I'd need SMTP-AUTH and perhaps TLS would be a good idea as
>> well (even though I will probably only use IMAP with Dovecot on the LAN).
>> I also need qmail-remote AUTH-LOGIN, so I can relay a couple of users
>> through my ISP.
> I think you might find that John Simpson provides a combined patch that
> handles all of your requirements, it offers a lot of features that you may
> or may not want to incorporate, but gives you a fairly easy to understand
> qmail-smtp run script (admittedly I had to spend quite a few days reading
> and re-reading his documentation ... and have still not managed to
> subscribe to his mailing list) ... you will find this the closest to a
> complete distribution of qmail you can get, while still based on qmail
> 1.03 rather than netqmail it incorporates all the patches certainly to
> netqmail 1.05 plus all of his, which give you far greater functionality in
> to-days environment. I have certainly had far fewer issues since I adopted
> his combined patch available here
> http://qmail.jms1.net/patches/combined-details.shtml
>
> However all that said one seldom has any real issues with qmail in spite
> of its 16 years in existence!!!
>
> And thanks to all the people on this list and those who kept netqmail
> alive for all these years.
>
>
Harald Hanche-Olsen
> I think the biggest disadvantage of qmail today is that it is not
> compatible with how we all use Linux/Unix and how we want to maintain
> our systems. The disallowance to bundle a binary package [...]
Correct me if I am wrong, but didn't Dan Bernstein release all his
software, qmail included, into the public domain in 2007? If so, you
can do binary packaging and all the restructuring you want.
> Dont take me wrong guys, I respect the effort of so many unpaid hours
> invested in improving this stuff, but honestly, the gift of Dr. B to
> the world is limited.
I am not getting into a discussion of the present value of qmail (we
still use it in our department), but surely, at the time it was
written, it was a huge and important contribution, as sendmail seemed
to have another security hole opening up every hour.
- Harald
Kevin Chadwick
FLoh Leeber wrote:
> I will switch to a
> supported package where I can press on my update button and lean back to
> watch the show.
>
You should rarely need to update good code unless you wish to. Take
OpenBSD (DJBs fav OS when writing qmail, I believe) and qmail and your
very unlikely to need to touch it for years, if ever, security wise.
You will never say that about debians stock kernel. OpenBSDs apache 1.3
still kicks ass out of apache 2 with it's new license security wise.
> Dont take me wrong guys, I respect the effort of so many unpaid hours
> invested in improving this stuff, but honestly, the gift of Dr. B to the
> world is limited. It caused pain and headache for me already enough and even
> if it is the worlds safest email server, it´s complications in daily use can
> be endless.
It's gonna have greater competition soon. Not quite ready yet but
OpenBSD now has it's own secure smtp daemon which also boasts safe
usage of ram for part of the queue system. It's a shame qmail was
prevented from likely being adopted by OpenBSD all those years ago, it
would most likely be near perfect and modernised now.
OpenBSD, qmail, rocks, literally.
FLoh Leeber
Still I think the "update of good code" is not because the code is flawed,
but because the world is changing, and despite many modern trends just
ballons in the end (I don´t use Web 2.0, no Twitter, no iPhone, not even a
smartphone etc. because I think i really don´t need their features), some of
the ideas which raised through the years need adoption, simply because they
make damn good sense.
For Apache I can say that had 1.3 around for a long time, but then,
realizing that also on Debian it will be time for a change:
- better multithreading
- IPv6 support
- mod_deflate
are only 3 things why an update makes sense. By the way, where is the IPv6
capability of qmail these days, anyone?
regards FL
----- Original Message -----
From: "Kevin Chadwick" <ma1l...@yahoo.co.uk>
To: "Qmail List" <qm...@list.cr.yp.to>
Sent: Tuesday, May 10, 2011 12:21 PM
Subject: Re: Err 507 - Too many patches.
On Tue, 10 May 2011 08:58:15 +0200
FLoh Leeber wrote:
> I will switch to a
> supported package where I can press on my update button and lean back to
> watch the show.
>
You should rarely need to update good code unless you wish to. Take
OpenBSD (DJBs fav OS when writing qmail, I believe) and qmail and your
very unlikely to need to touch it for years, if ever, security wise.
You will never say that about debians stock kernel. OpenBSDs apache 1.3
still kicks ass out of apache 2 with it's new license security wise.
> Dont take me wrong guys, I respect the effort of so many unpaid hours
> invested in improving this stuff, but honestly, the gift of Dr. B to the
> world is limited. It caused pain and headache for me already enough and
> even
> if it is the worlds safest email server, it´s complications in daily use
> can
> be endless.
It's gonna have greater competition soon. Not quite ready yet but
OpenBSD now has it's own secure smtp daemon which also boasts safe
usage of ram for part of the queue system. It's a shame qmail was
prevented from likely being adopted by OpenBSD all those years ago, it
would most likely be near perfect and modernised now.
OpenBSD, qmail, rocks, literally.
Kevin Chadwick
FLoh Leeber wrote:
> - better multithreading
Well the hardware hack and so rthreads is still in the process of being
dealt with at OpenBSD. It still handles a rediculous number of web
pages and is complimented by relayd. I think php/web optimisation is
far more effective, though possibly out of your control.
> - IPv6 support
I never favoured IpV6. Then one of the authors of netqmail and
the firewall macos is adopting from OpenBSD referred to it as ipvshit
and i'll steer clear for as long as I can. see below
___________________________________________________________________________
> >> Unless you are an ISP with more than 2^24 customers.
> > you are talking bullshit. there is oh so much v4 space allocated that
> Currently an ISP with more then 2^24 customers can't NAT them all
> (as 10/8 has only 2^24 addresses) or has to allocate more than one
> /8 for his customers, which makes routing etc. more difficult.
you are talking bullshit, still.
who sez that your made up isp has to hand out network-wide unique IPs
to his customers?
why do i even waste time on some ipvshit advocate that acts like a
politician claiming we have to eat shit because there wouldn't be an
alternative, making up a case out of nothing to "prove" his case?
> > as if one incompetent isp mattered.
> I'm sure most chinese and indian ISPs will agree.
you sure know what you're talking about, that's obvious.
look at the oh so bright future yourself, look at the code required to
deal with that misdesigned piece of shit.
did i just say "designed"? sorry. it's obvious that nothing remotely
related to design was involved.
u_int8_t
mask2prefixlen(in_addr_t ina)
{
if (ina == 0)
return (0);
else
return (33 - ffs(ntohl(ina)));
}
u_int8_t
mask2prefixlen6(struct sockaddr_in6 *sa_in6)
{
u_int8_t l = 0, *ap, *ep;
/*
* sin6_len is the size of the sockaddr so substract the offset
of
* the possibly truncated sin6_addr struct.
*/
ap = (u_int8_t *)&sa_in6->sin6_addr;
ep = (u_int8_t *)sa_in6 + sa_in6->sin6_len;
for (; ap < ep; ap++) {
/* this "beauty" is adopted from sbin/route/show.c ...
*/ switch (*ap) {
case 0xff:
l += 8;
break;
case 0xfe:
l += 7;
return (l);
case 0xfc:
l += 6;
return (l);
case 0xf8:
l += 5;
return (l);
case 0xf0:
l += 4;
return (l);
case 0xe0:
l += 3;
return (l);
case 0xc0:
l += 2;
return (l);
case 0x80:
l += 1;
return (l);
case 0x00:
return (l);
default:
fatalx("non continguous inet6 netmask");
}
}
return (l);
Kevin Chadwick
Pop User wrote:
> Yes, and we are thankful you do it. My response was based on one person who does work on qmail referring to another persons work on qmail as "*exactly* the way to bring qmail down the drain".
>
> It is really uncalled for.
Seems to me that he was referring to the danger of buggy patches being
used without peer review. It seems johns collation have received some of
that, but this danger should always be aired and is called for, it
doesn't mean that Johns work isn't good. There are levels and levels of
correctness, contributors to OpenBSD learn this very quickly from the
echos of laughter. I once put a seemingly fine patch for qmail onto the
OpenBSd mailing list.
________________________________________________________________________
> Does anyone know if the following patch is a good idea for OpenBSD or
> simply never needed no matter how many mails you process.
>
> http://vorlon.cwru.edu/~tmb2/qmail-1.03/qmail-1.03-maildir-uniq.patch
I would not use that patch. There are some sloppy mistakes (e.g., not
correctly mangling hostnames to spec), so it makes me nervous whether
or not the author made sure the fntmptph and fnnewtph buffers are
large enough for his new string formats.
They're certainly not if an attacker controlled what gethostname(3)
returns, but that's a bit of a stretch...
_________________________________________________________________________
For the record I had an obscure bug in gcc on OpenBSD which had been
fixed in freebsd and was preventing starttls from working. I prefer TLS
but starttls is needed for server to server and allows spamd. Erwin was
extremely helpful in spotting the issue which was outside of the box.
A big thankyou to djb and all qmail patchers, especially eh. The main
thing a patched qmail needs is more peer review.
Christopher Weimann
Andy Bradford
> I think the biggest disadvantage of qmail today is that it is not
> compatible with how we all use Linux/Unix and how we want to maintain
> our systems.
Seems to work for what I need it to do just fine.
> Its always the same with things coming from university: When they go
> beyond being a proof-of-concept, most of them fail because the authors
> are too much focused on the theoretical solution.
Wow, I hardly think qmail was just a ``proof-of-concept.'' A proof?
Maybe, I'll concede that, but it has definitely gone beyond theoretical
and into practical.
Andy
Barry Miller
>
> It's gonna have greater competition soon. Not quite ready yet but
> OpenBSD now has it's own secure smtp daemon which also boasts safe
> usage of ram for part of the queue system. It's a shame qmail was
> prevented from likely being adopted by OpenBSD all those years ago, it
> would most likely be near perfect and modernised now.
I've been using qmail for some time now (I'm the BJM in the qmail-1.02
THANKS file), and remember the Dan vs. Theo conflict sadly. I guess
that's what happens when you have strongly held principles and are
unwilling to compromise even a little. OpenBSD might have done for
qmail what they did for SSH.
That being said, I would consider migrating to smtpd where possible,
but its refusal to allow the '-' hack (because hyphens are legal in
usernames) would cause me some real problems.
> OpenBSD, qmail, rocks, literally.
Indeed.
--
Barry