On Mon, 01 May 2000 17:17:11 -0400, Mike Flynn wrote:
[ blah blah blah ]
>Q01. Is it true that I can get an enormous increase in the number
> of messages I could mail per hour using qmail?
I don't know, can you? Can is a question of ability, and it has been my experience
that automailers (which I unfortunatly have
to drop you into) have various optimization issues of their own right.
If your program is broken, qmail MIGHT NOT be (much) faster...
For example:
Mailing list injection can truly be done one of three (major) ways:
1. a manual injector; /usr/lib/sendmail -t or
/var/qmail/bin/qmail-inject -- it's all the same
2. smtp connection with a LOT of RCPT TO:'s
3. autoinjecting (ezmlm or majordomo)
Now number '1' is certainly attractive; it allows you to easily switch mailers and
depending on the rest of the project, maybe
even platforms. '2' also would seem that way, however, mailers often make quite a
difference between the two. 300K
fork+exec's is a LOT of process wasting. add to that the fact that qmail then needs to
chill those in it's queue for a while, and
blast them out at a later time. SMTP relaying just passes the buck; but the mailer
/MAY/ be more adaquitely developed for
this task; it may not even fork at all! (yeah, think about that one :P)
The fact that we have ezmlm is what makes me love qmail. I let ezmlm manage the lists.
That way, I don't have to make any
special codes to allow the user to subscribe and unsubscribe. And it allows me to pass
the buck so that as qmail and ezmlm
mature, so does the versitility of my service. I just write a couple perl cgi's that
subscribe in a SAFE manner, and be done
with it.
So in general, is qmail going to be faster? hey, we're all fans here. And I doubt
you'll find anyone on this list to tell you that
qmail is "slower" than anything else out there. And there's numerous success stories
floating all over the place to commend
the awe that is qmail. So yes, it is /faster/.
But we also use qmail for another (IMHO, an even better) reason: simplicity. I feel
confident that when I create an alias, or a
list, it'll work as I expect it to. Because qmail is simple, I can actually understand
how it works (just by looking at the
source-- something you can't really get from sendmail). And that makes me feel that
it's safe for what I want to do with it.
Since I switched to qmail in 97, I haven't lost a single email. When I took over a Sr
position at another company, we were
losing 5-10 emails a month because of sendmails incompetence -- I switched them over
to qmail, and my success rating
continues to soar.
>Q02. Is qmail free? (I will be using it in a "commercial" product).
That depends on your definition of free. Is it free for me to use? Yes.
Is it free for me to change? Yes.
Is it free for me to redistribute? As near as I can tell -- yes, as long as I don't
distribute a modified qmail.
>Q03. Does my environment sound like a "simple" use of qmail or
> is there hidden aspects I'm not aware of?
>
>I do process returned mail today and separate it into different
>directories
>which I eventually use to clean up the email addresses in our database.
>
Welp. Your "environment" sounds a lot simpler than you make it out to be.
I always thought a good rule of thumb is that if you sell houses, what business do you
have making cars?
And if you sell newsletters, why would you build a mailer?
There's already fantastic (free) software that does exactly what you're trying to make
(so it sounds).
ezmlm (for example), automatically deals with bounces in a rather intellegent way. You
might be able to speed your project
around by continuing your searches.
>Q04. Can I keep the portion of the product that processes returned mail
> the same (i.e. using sendmail) and still use qmail to do the
>mailing?
Again, that depends. See my answer to Q1. Qmail provides a "sendmail emulation"
system. Take it, and the fastforward
package, and qmail can work as almost a drop-in replacement for sendmail. And with
some tweaks? A lot better than
sendmail.
However, if you're dead-set on splitting up the job of delivery, you CAN do it with
qmail. Qmail doesn't have anything about
it that *REQUIRES* that SMTP be running (or pop, or qmqp/qmtp for that matter). By
installing qmail, you can use it's fast
queuing and remote delivery system along side sendmail's broken local delivery.
But I wouldn't recommend it. Sendmail has many issues that should one day be dealt
with (read: dropped off a cliff), and I
hope everyone will realize that. But I also hope that people will realize that you can
have your cake and eat it too; qmail does
mail. it isn't sendmail (that's true), but sendmail has (unfortunatly) defined the way
a lot of programs think of mail.
There are SO MANY shell/perl scripts that have lines like:
open(P, "|/usr/lib/sendmail -t") or die ("$!");
...
and qmail will work FINE with them. It's not sendmail, but neither is
/usr/lib/sendmail. It's just a wrapper that calls the
appropriate qmail program. Likewise, there's an "addon" to qmail that emulates
/etc/aliases JUST LIKE sendmail.
Anyway, I'm drunk, and I hope this helps.
