Hello, On 01/23/2003 02:40 AM, Jonathan Chum wrote:
I always advise people to not bother personalizing messages for silly purposes like starting messages like this:Anyway, the problem of personalizing messages is that makes your mailings take much longer to generate and queue because you need to create separate message for each recipient.I'm weighing down personalization and enveloping for this project, and probably going for the personalization of each email. This rules out BCC and enveloping with SMTP.
Dear <SPAM-VICTIM-NAME-HERE>,
The problem is that this is now a pattern of spam that people are so much used to it that they no longer can be fooled into believing that the messages was really written by a human being to them and not some spam script.
It was told that spam detection programs like SpamAssassin give extra spam points to messages that have phrases like that.
OTOH, there are more reasonable motives to personalize messages like the silly decision of Hotmail to have default spam filter rule to reject messages that do not have a visible To: or Cc: header with the recipient address of the Hotmail account.
The decision is silly because it makes it consider most real opt-in mailing lists like this one, php-general, as spam, which is obviously a big mistake.
Anyway, since most Hotmail users with that filtering rule on are not aware, it makes sense to personalize just the To: header with each recipient address. You do not have to personalize the body though. So, I have just added an option to cache the message body between deliveries of the same message to different recipies using this MIME message composing and sending class. See the personalized bulk mail example for more details:
http://www.phpclassses.org/mimemessage
No, qmail only attempts to send upto a limited number of messages simultaneously which defaults to 20, but if you have good link you can raise it upto 120. Raising it further will not work unless you apply a patch to qmail.and run it every hour.With qmail you do not have to run the queue like sendmail. You just inject the messages and it will deliver them when possible.If it delivers when possible, won't the server flake if it get's 100,000 emails inject into Qmail? If I was to use your class and loop through 100,000 emails into Qmail, will Qmail attempt all at once?
Anyway, the down side of injecting that many messages in qmail queue, either separately or a single message with Bcc:, is that it will choke the incoming message reception because the SMTP server delivers the messages to the local queue too.
There are 2 solutions for this: if you have a spare server machine, use it as relay and configure qmail control value smtproutes pointing to the spare server that will do the actual delivery. If you do not have a spare server, you need to just inject a few messages at a time and rest for a period of time that is enough to let the messages already inthe queue be flushed. Even with a spare server, it is a good idea to rest after delivering a few hundred messages.
If you really want personalization, QMQP is not really useful because it is meant to shift queues of single messages to many recipients. Personalization turns it into many messages to distinct recipients.In that case, you may consider QMQP relay which is a protocol that lets you rely entire mail queues from a server to another. This is recommended when you have many busy mailing lists served from one machine and you can use more servers do the actual delivery. I think only qmail and ezmlm support QMQP.Thanks, I'll check QMQP as well.
That is not a good idea either because you are delisting people that are temporarily bouncing as if their addresses are permanently invalid which is not the case.The greatest problem that made me learn some hard lessons is that it is very problematic if you start with subscribers list that are not clean up of no longer valid users. Once you start delivering messages to those addresses, you get a flood of bounces that pratically stop your server queue. The MTV newsletter was weekly, but that affected the newsletters of other sites that were stopped during the MTV newsletter bounces. Since ezmlm does not unsubscribe bouncing addresses right away, the solution was to remove bouncing subscribers using an external validation procedure. I used this other class for the cleanup. After that it was a breeze. We had peaks of 10,000 messages sent per minute. http://www.phpclasses.org/emailvalidationWe had a 72K list with about 6K bad emails that Mailman didn't unsubscribe until we used MojoMail which unsubscribes them from the database instantly as well as perform validations. Now, blasts are handled alot quicker.
Queueing is fast because you are just calling a local program. Unless you are using a spare server for relay, the greatest problem are those addresses that while they are not invalid nor reject messages, they are hard to deliver like those on servers with slow links or those that intentionally put delays that take many tens of seconds to accept the message to make it harder for spammers.So far, you have given me a good case to use Qmail and using your PHP class as a foundation for this application. . . I'll have to check the other software recommendations you made and see how'd I incorporate this into the application. BTW, isn't there any overhead associating with opening/closing a connection to inject each email into Qmail? Or it's very minimal overhead to even worry about? If 100,000 was looped and injected into Qmail, is Qmail fast enough that 100,000 emails are not just sitting on the server filling up disk space?
--
Regards,
Manuel Lemos
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
