Hi Manav. For most of this, one word: ezmlm (www.ezmlm.org). For the
rest...
>>>>> "manav" == manav <[EMAIL PROTECTED]> writes:
> 1.2 For each blast we want to handle the bounced emails individually (we
> would need to update the appropriate table). What do we do for that? We
> cannot just "set" environment variables since there will be multiple
> mail-merges and blasts happening simultaneously.
Mailing list is the word I think you are after. See above...
> 1.3 Usually after about 5,000 deliveries, the messages would be stuck in
> the queue. We then added the CNAME lookup patch, and this increased to about
> 10,000. Currently, we "prune" the lists uploaded by the users and send
> messages in chunks of 2000, with less than 30 concurrent messages. Any
> suggestions what could be the culprit? What can we do to circumvent this
> problem?
The only reason I can see why you would want to do this would be if
you are customising the message for each individual user. If you
are... you will probably want a bit more processing power (ie: more
servers) than this. It is well known that qmail doesn't really enjoy
having 10,000+ e-mails in the queue...
> 1.4 What would be the best possible way to handle unsubscribe requests.
> Currently we invoke a java program from the .qmail file that updates the
> database. Any suggestions how this can be improved upon?
Ezmlm
> 2. We then decided to switch over to using qmail-remote, to circumvent the
> queue and the logging problem. This effectively means we will have to do our
> own logging. Is there anyway to hand over different messages to qmail-remote
> rather than invoking it for each message? We have now decided to change the
> implementation so that at any point of time, there will be as many threads
> sending messages as the qmail concurrency (say around 100), and the messages
> themselves will be broken into chunks of 300 to 500 each. How can we improve
> this?
Ezmlm looks after all of this for you. It is probably easier to hack
up ezmlm-idx to customise messages, than to make your own do
everything that ezmlm does.
> 3. Currently, we have our own implementation for checking bad e-mail
> addresses, list management, handling bounces and mail-merge. Are
> there any guidelines/sample code available (any language), that we
> can look at?
Ezmlm...
> 4 . What other things should we keep in mind to provide stability to
> the system? What patches to qmail are advisable to be installed?
> What should be the typical server configuration for such a system?
If you are customising messages, you definitely need parallel
processing or clustering. Also, that 128kb line is a MAJOR
bottleneck...
Oh, and RedHat 6.2 is not the best server distribution. I use it on a
number of my servers, but am moving them to Mandrake (for now) until I
find the time to investigate other alternatives such as Turbo Linux
and Debian. Mandrake can be made to work a lot better for you than
RedHat, and so far 8.0 has MUCH less bugs in the components than most
RedHat versions...
> 5. On a parallel note, what would be the best algorithm to track
> forwarded messages? We make use of cookies right now (but that
> provides 50% accuracy).
We use a blank 1x1pixel gif in our e-mails that is like:
<a href="http://my.server.com/cgi-bin/emailcount.pl?2001-06-22-Email-1"; width=1
height=1>
That perl script then does whatever it has to (it logs the relevant
data to a file, and increases the count in another file) and then
returns a 1x1 pixel GIF, using the GD library, from
memory... Obviously this requires an HTML e-mail to be going out, but
if you're using cookies then you are obviously already there!
By the way, the parameter on the perl script (?2001-06-blah) is so
that we can use the same script for each e-mail that goes out, and
just change the parameter so that we can count for different
mailouts. On that note, Hotmail doesn't allow the forwarding of HTML
e-mail. I don't know about the other major free e-mail providers.
HTH
Brett.
--
Smash forehead on keyboard to continue
