On the qmail list [EMAIL PROTECTED] wrote:
>At 01:38 PM Sunday 4/11/99, Lorens Kockum wrote:
>>
>>qmail-inject does not look at headers, does it
>
>Incorrect. qmail-inject is *the* program that does look at headers. How did
>you deduce the above after reading the man page for qmail-inject?
Obviously, my reading of that particular man page was lost in
the mists of time :-( Fortunately, when you put recipients on
the command line, the recipients in the headersare not taken
into account, otherwise I would have sent quite q few unwanted
mails...
>>>Since the invocation happens just the once for the all recipients, there is
>>>no advantage to using qmail-queue (and some disadvantages if you ask me).
>>
>>40000 e-mail addresses would make for some small problems ...
>>have to split it up somewhat, I'd say.
>
>Incorrect. This is precisely how a "serious mailing-list" does it. Namely
>ezmlm. Admittedly via qmail-queue, but the queue insertion costs and
>sequences are the same.
I didn't go to the bottom of recipient parsing in qmail-inject,
but putting 40000 e-mail addresses on the command line is
obviously not possible. Making a file representing a message
with 40000 recipients in Bcc for the sole purpose of catting it
to qmail-inject seems unreasonable. Using qmail-queue seems more
reasonable.
>You miss the point entirely. A spammer can get better "performance"
>precisely because they don't need to worry about such things. A real list
>cannot - as you re-state.
So why did I miss the point, then? Spammers get better
performance by implementing the shortcuts discussed, a serious
mailing-list can't use all of them, but can use some, which I
note.
My point was that a single low-cost machine dedicated to
sending out one e-mail an hour to 200K recipients can afford
to disregard the possibility of their machine failing ; one
probably wouldn't care a jot about the risk of losing "mail",
since nothing important would be lost; therefore the queue could
very well be in RAM. Such a system would want to take into
account errors during normal operation, but the risk for a hard
crash would be small enough to probably warrant not recovering
at all. "Sorry, you didn't get last hour's update because power
went off for five consecutive hours and our UPS only managed 4
1/2 hours"...
>>>FWIW. The best I've seen out of a single box Pentium with one or two high
>>>speed spindles is around 100K per hour. The systems tend to run out of queue
>>>disk I/O. (This of course is gross generalization as most people will
>>>realise, but it gives a ballpark expectation for an unmodified qmail system).
>>
>>Therefore memory-based fs, yes.
>
>Nope. Memory-base fs don't tend to have high speed spindles I don't reckon.
Neither do I. One or two high speed spindles => 100K an hour
bottlenecked by disk I/O, but he wants better than 100K
mess/hour, so get better disk I/O, right? Or was I also wrong
in supposing a memory-based fs has better I/O performance than
"one or two high speed spindles"?
--
#include <std_disclaim.h> Lorens Kockum
