At 22:22 2006-08-30 -0500, Philip Hallstrom wrote:
But some providers will block based on number of recipients per message...
so don't go crazy sending one message to 50,000 aol addresses, etc...
Which is why you'd have conditions for special-case domains, which I *DID*
point out in my post, along with basic mail delivery logic (50K recipients
would be a bad design anyway). Any MTA worth its salt will have
configuration options to keep you from stepping on your d**k like
this. Sendmail for instance:
SMTP_MAILER_MAXRCPTS [undefined] If defined, the maximum number of
recipients to deliver in a single connection for the
smtp, smtp8, esmtp, or dsmtp mailers.
IOW, this would automatically "chunk" deliveries to a given mailhost to so
many recipients.
See also "queuegroup" in sendmail documentation, which allows you to take
mail destined for certain domains (or specific addresses) to go DIRECTLY to
a specific queue (thus allowing you to configure at the MTA level directly
for problematic domains).
Yes, I realize the OP indicated they're using some other MTA - that of
course is their problem, but what they might find in the sendmail docs
(with which I personally am reasonably familiar) might clue them into what
feature/keyword to investigate in the MTA they're saddled with. Or, opt to
switch MTAs... It isn't as if you couldn't run sendmail bound on a
particular IP address to run your webserver outbound mail queues separate
from whatever your usual MTA is.
I really suspect though if the chap's mail server is being dropped to its
knees, it may be (tens of) thousands of individual messages, rather than a
few messages with thousands of recipients.. When you're working with
individual messages, the MTA has to negotiate EACH connection -- when
you're working with multiple recipient BCC'd messages, the MTA is doing
SMTP negotiation ONCE per recipient host, then pouring a pile of "RCPT
[EMAIL PROTECTED]" commands at the host, followed by ONE copy of the message:
*WAY* more efficient, both in terms of host connection time, as well as
network bandwidth consumption.
This approach isn't suitable if the messages are custom tailored to each
recipient (ala "mail merge").
It isn't without irony that it is AOL whose postmaster guidelines give a
preference to mailmerge style messages (such as one-click delisting for
their users - something which requires a recipient-specific URL in the
message). A large automotive website I work for has pretty much given up
on dealing with AOL, who seems to randomly block senders because their
turd-for-brains users use "this is junk" to uns*bscribe from lists rather
than following directions.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Founding member of the campaign against email bloat.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
