On Wed, Jan 25, 2006 at 01:22:52AM +0200, Razvan Turtureanu wrote:
> I'm not new to qmail or qmail-ldap, but now my boss wants me to deploy a 
> very big e-mail sistem
> (200k users that receve mail on the saim domanin name) and I started to 
> to my homework and I found this link:
> 
> http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html
> 
> Is this true, or is the writer of this document a sendmail fan?
> 

It seems he does not like qmail and he does not like to do all of his
homework. Most of it is just plain FUD.

> How many known bugs are still there in qmail or qmail-ldap?
> 

There is no known number of open bugs (at least in qmail-ldap bugs are
fixed as they pop up. For qmail-1.03 it is a bit different but that's a
different story).

> Is it true that qmail-qmtp has a buffer overfolw?
> 

There was something that WAS not exploitable in a non scary install.
The mentionend qmail-qmtp buffer overflow needed a RELAYCLIENT variable
that was non empty but in 99.99999% of all installs RELAYCLIENT will
either be set to "" (the empty string) or not set at all. You can set
RELAYCLIENT to a domain name and that will be appended to the sender
address (and that's why it is not useful in most install).

> Please replay to me, and hopefully, tell me that the link above is wrong.
> Best o luck.
> 

Let's have a closer look (all statements will be for qmail-ldap):

1.1 Yes you can exhaust your qmail-smtpd memory. If you misconfigured your
server. It is no longer possible to exhaust it with the line lenght but if
you do not set the MAXRCPTCOUNT environment it would be possible to
exhaust it via many "rcpt to"'s. Btw. this will only exhaust the
qmail-smtpd that is serving you and not any other.

1.2 Boohoo, qmail does queue mail that will fail later.
qmail-ldap is capable to do recipient verification and some other sanity
checks but in the end it is still possible to queue mails that bounce in
the end. Every MTA with a mail queue has this issue (this includes postfix
and sendmail).

1.3 Already mentioned. Non default setup, fixed in qmail-ldap 2004-03-03
I think this is the same date that Georgi Guninski informed bugtrack.

1.4 Wow you can overflow qmail by allocating around 4.5GB of memory. Jeeze
if you did not add some limits because of 1.1 you probably should do it
because of this. Anyway which mail machine has so much free memor.
Fixed in qmail-ldap in the upcomming release.

2.1 FUD, use FFS and your safe. Use ext2 FS and you suffer. It's a
question about the file system you use and not about qmail. Btw. most MTA
have a small race condition where you may lose mail. I think not even
postfix is 100% crash proof.

2.2 FUD. Yes it is possible that you create a name collision on maildir
delivery but this is a temporary error and the delivery will be retried
later. I don't think that you can manage to hit that race for one week.

2.3 Linux bug. Linux user sorry but if it hurts you use a real OS or talk
to your kernel hacker. Did linux still fail to add sa_len?

3.1 Ja ja. I think qmail does it right and the RFC is totaly stupid.
a) most MUA do correct encoding of attachements
b) The two MTAs in the interner that are not 8 bit clean should be turned off
This is more a theoretical issue and I think that most other MTA violate
this or an other RFC in the same way.

3.2 Not an issue in qmail-ldap. Got fixed a long time ago.

3.3 Oh yes there is only one bonce message format in the internet and only
qmail is violating it. Btw in qmail-ldap it is possible to add a custom
bounce text the bounces.

3.4 Does not matter. Yes the mail size is to short because the \r that are
inserted on transfer are not accounted and now what's the problem again?

4.1 My workstation did 35 deliveries per second and the bottleneck was the
IDE drive I used. Yes qmail does many fsync() operations but the queue is
save because of this.

4.2 FUD. Bullshit. I run qmail on many many systems with softupdates
enabled. There is one minor race condition that you have to be aware of.
qmail moves the file after queuing from a temporary directory to the todo
directory. After doing that e.g. qmail-smtpd will report successful
queuing. If you now kill the box in that moment (after the success message
went out but before the link was finished) the mail will be lost.
We had some unexpected powerlosses on some of our busy mail systems and we
never lost a mail. (Btw. the problem is that the mail ends up in the wrong
directory after fsck).

4.3 SHOULD not MUST.

4.4 Yes we do not use PIPELINING because of 4.3 (qmail does only on
delivery per remote smtp connection).

4.5 See 1.2. Btw qmail-ldap is able to limit bounce messages.

4.6 Theoretical problem.

4.7 I think the guy is wrong here. Doing a getuid is as bad as sending as
"anonymous". I don't see a difference in mails comming from anonymous or
www both are wrong. Setup your scrips correct and all will be fine.

4.8 Jep. We wrote the external todo patch and this solves the problem. It
is included in qmail-ldap.

4.9 errno was not misused. It is more so that the pthreads and C99 changed
how errno was defined and so qmail failed to compile on these new systems.
The qmail source code is from 96 or something like this and nobody knew
that this will be an issue later. This is fixed in qmail-ldap since some
time.

4.10 see whatever again. Again this is fixed in qmail-ldap and it is
slowly getting silly.

4.11 this is part of qmail-ldap since a long time.

4.12 this is fixed in qmail-ldap.

4.13 there is only one way to insert bare \r into qmail and that is via
qmail-queue. If you do it like this it should be considered 8bit data and
not be modified. Unix is a \n land.

6.1 If you realy like to get all bounces use qmail-ldaps bigbrother
feature.

6.2 First he yells about RFC violations and than that. How two-faced.
Btw. fixcrio is porbably the right way to fix this issue if it is
absolutly necessary.

This took way to long to write. Most of this guys points are FUD or are
fixed in qmail-ldap. In the end if you like running big mail systems with
virtual (LDAP) users your well served with qmail-ldap. There are
installations that have more than 2Mio accounts without an issue.

-- 
:wq Claudio

Reply via email to