Hi Brett,
Thanks for the reply.
I am exploring ezmlm right now, so I believe I'd have to trouble the people
on the ezmlm mailing list for queries on that :-)
For tracking forwarded emails, I have a hidden IMG tag which then calls a
servlet. When the user opens the email for the first time, the "hit" is
registered and a cookie is written. Subsequent "email reads" by the same
user can now be tracked. When the servlet finds the cookie is not there,
either the cookies were deleted or the user forwarded the email. I don't
think I can make use of any combination of HTTP headers to establish
uniqueness of the recipient (or if there is, please let me know).
Once again, if this discussion offends anyone on the list, I apologize (and
would be glad to carry the same offlist).
Thanks,
Manav.
----- Original Message -----
From: "Brett Randall" <[EMAIL PROTECTED]>
To: "manav" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, June 23, 2001 6:36 AM
Subject: Re: Java and Qmail - building a large mailmerge server - plain text
version
> 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
