manav writes:
> I really appreciate you took some time out to reply. Thanks.
And not flame you? :-) Not everybody on the list is a flamer, and
besides you supplied us with all the necessary information. You *did*
confuse us by mentioning 10 lakh recipients and 128kbps in the same
paragraph, but that's really no matter. The real problem is injecting
bulk email using separate messages.
> We are running the alpha phase right now (with whatever current
> implementations we have), and I have serious doubts about the stability and
> scalability of the system. The maximum load that I've put on my production
> boxes is 250,000 emails so far and I've had similar issues that I mentioned
> on my development boxes (the ones that are resemble a Beetle, to quote Mike
> :-) ).
The problem, simply enough, is that you should try very, very hard not
to have a separate copy of the email on the disk. If you're running
qmail-inject on each message, then yes, three machines aren't going to
be enough. On the other hand, three machines of the type you describe
below will be sufficient to deliver one million emails in about eight
hours, IF you're doing the mail merge function at delivery time.
You can do that using the qmail-verh patch, you could call
qmail-remote directly (in theory; I don't know that anyone is doing
that), or you could purchase my qmail-merge system. It lets you
substitute multiple fields into each message. So you could substitute
in a first name, a last name, a database ID number, or whatever else
you want. Handles bounces, and runs everything through the database.
Details upon request.
Dealing with bounces is a whole 'nother headache. You see, there are
three types of email bounces: 4XX bounces, which are known to be
temporary. A retry is definitely called for, and qmail will handle
that on its own. You also get a 5XX bounce, where the smtp server has
told your smtp client that the email will never be deliverable. These
get handled by parsing the QSBMF message. And you can also get a
delivered but returned message. VERP is your friend here, because
parsing bounce messages is a task only attempted by lunatics.
Even then, you can't treat a 5XX or returned message as a permanent
failure. You have to have a system for retries these messages at a
later time.
As someone else pointed out, ezmlm handles this nicely.
Unfortunately, ezmlm doesn't work well when you've got users
subscribed to more than one type of mailing, because it doesn't share
bounce information between lists.
--
-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
Crynwr sells support for free software | PGPok |
521 Pleasant Valley Rd. | +1 315 268 1925 voice | #exclude <windows.h>
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
