Mass E-mail Options
5 answers - 1055 bytes -

Again, I know this is not necessarily a MySQL specific question, and sorry
for getting off target, but this is a pretty smart and experienced bunch,
and I'm sure that someone out there will be able to help me.
We have a web application in which we have a mass e-mail function. It
allows the user to compose a simple text-only e-mail and send to everyone in
our database (MySQL). Problem is that our e-mail server seems to be getting
overloaded, and it just shuts down, causing an error. We're using ArgoSoft
Mail server, which works very well for our normal needs. We do not want to
change to Microsoft's Exchange Server. I hear it's expensive, and difficult
to set up and get working properly.
I was wondering if anyone knows of any alternative mass e-mail options. I
don't want to use servers that spammers use, because first, and foremost,
this is NT spam, and second, some recipients may have these servers black
listed. What other alternatives are there?
Thanks,
Jesse
No.1 | | 1031 bytes |
| 
Again, I know this is not necessarily a MySQL specific question, and sorry
for getting off target, but this is a pretty smart and experienced bunch, and
I'm sure that someone out there will be able to help me.
We have a web application in which we have a mass e-mail function. It allows
the user to compose a simple text-only e-mail and send to everyone in our
database (MySQL). Problem is that our e-mail server seems to be getting
overloaded, and it just shuts down, causing an error. We're using ArgoSoft
Mail server, which works very well for our normal needs. We do not want to
change to Microsoft's Exchange Server. I hear it's expensive, and difficult
to set up and get working properly.
I was wondering if anyone knows of any alternative mass e-mail options. I
don't want to use servers that spammers use, because first, and foremost,
this is NT spam, and second, some recipients may have these servers black
listed. What other alternatives are there?
No.2 | | 2244 bytes |
| 
At 18:32 2006-08-30 -0700, Scott Haneda wrote:
>I would also try to unorder the email addresses, so that large groups of
>yahoo and aol etc emails do not hit the outbound queue at the same time.
>They tend to look down on that activity, and throttle you back, making it
>take even longer to get your messages out.
You might put special-case conditons on specific domains, but actually,
you're much better off ordering by domain because your server will end up
sending NE_ message addressed to whatever number of recipients at that
domain. If your list is truely massive, your MTA may be incapable of
sorting the recipients itself: a good MTA will batch by recipient domain.
An equal probability is that you're actually generating INDIVIDUAL messages
(one per recipient), rather than messages with a BCC: recipient list, in
which case, my advise would be to switch to BCC: addressing, but if that
isn't an option, look at a cascaded MTA queue (messages which don't deliver
on the first try get sent to a secondary queue which won't retry right away
- and those which fail to deliver from that queue get moved to one that
takes even LNGER) - a fairly typical (read: default Sendmail setup) queue
retry is every 15 minutes, 24/7 if you've got a few hoser domains in
there, they can stuff you up quick.
Check your server logs to see if the domains you're emailing to are trying
to perform callbacks (GTE and it's affiliated telco domains are/were doing
this for some time - this is the same bunch of idiots who've blocked many
european IP ranges from sending mail to them, and such sites have to relay
through other hosts in order to deliver to GTE customers). Any domain that
does this might be a candidate for being added to a special case handler to
be shuttled to a low priority queue right off the bat.
Might I suggest you set up a database for the special conditions and the
queues you'd place them in? <g>
Please D NT carbon me on list replies. I'll get my copy from the list.
Founding member of the campaign against email bloat.
No.3 | | 717 bytes |
| 
>I would also try to unorder the email addresses, so that large groups of
>yahoo and aol etc emails do not hit the outbound queue at the same time.
>They tend to look down on that activity, and throttle you back, making it
>take even longer to get your messages out.
>
You might put special-case conditons on specific domains, but actually,
you're much better off ordering by domain because your server will end up
sending NE_ message addressed to whatever number of recipients at that
domain.
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
No.4 | | 3018 bytes |
| 
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.
IW, 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 P 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. , 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 NCE per recipient host, then pouring a pile of "RCPT
user@domain" commands at the host, followed by NE 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 AL 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 AL, 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 D NT carbon me on list replies. I'll get my copy from the list.
Founding member of the campaign against email bloat.
No.5 | | 1877 bytes |
| 
An equal probability is that you're actually generating INDIVIDUAL
messages (one per recipient), rather than messages with a BCC: recipient
list, in which case, my advise would be to switch to BCC: addressing, but
if that isn't an option, look at a cascaded MTA queue (messages which
don't deliver on the first try get sent to a secondary queue which won't
retry right away - and those which fail to deliver from that queue get
moved to one that takes even LNGER) - a fairly typical (read: default
Sendmail setup) queue retry is every 15 minutes, 24/7 if you've got a
few hoser domains in there, they can stuff you up quick.
I hadn't considered the BCC option. That would definitely speed the process
up as well. However, we're dealing with potentially 5,000 emails at one
time. That is a lot of addresses to put in the BCC field. Can it hold that?
Also, I'm passing this as a variable to an e-mail function that I have. I'm
not sure what the capacity of a variable is in ASP. It may not be able to
handle a variable that large.
Check your server logs to see if the domains you're emailing to are trying
to perform callbacks (GTE and it's affiliated telco domains are/were doing
this for some time - this is the same bunch of idiots who've blocked many
european IP ranges from sending mail to them, and such sites have to relay
through other hosts in order to deliver to GTE customers). Any domain
that does this might be a candidate for being added to a special case
handler to be shuttled to a low priority queue right off the bat.
Might I suggest you set up a database for the special conditions and the
queues you'd place them in? <g>
Wow, this is getting complicated! All I want to do is send e-mails
Jesse