Bulkmail question

[Neil Gould]

I'm preparing an ASP script to send email to club members via the club's
website. In getting familiar with CDOSYS, I noticed that the recommended
method of sending the same content to multiple recipients is to loop
through the list of recipients. I had intended to BCC the message. Is
there some reason to prefer looping through recipients?

The next task is to distribute the club's newsletter via one of the above
approaches. Does this make one approach more desirable, and if so, why?

Thanks,

Neil

 

[Bob Milutinovic]

I'm preparing an ASP script to send email to club members via the club's
website. In getting familiar with CDOSYS, I noticed that the recommended
method of sending the same content to multiple recipients is to loop
through the list of recipients. I had intended to BCC the message. Is
there some reason to prefer looping through recipients?

The next task is to distribute the club's newsletter via one of the above
approaches. Does this make one approach more desirable, and if so, why?

Looping through the recipients;
- generates one message per recipient
- allows customisation of messages (e.g., personalised greetings)
- places the processing burden on the web server

BCCing en mass;
- generates one message for all recipients
- doesn't allow any individualised customisation
- places the processing burden on the mail server


- Bob.

 

[Neil Gould]

Hi Bob,

Thanks for your response. I'm particularly interested in two of the
aspects that you've pointed out.

recipients?

The next task is to distribute the club's newsletter via one of the
above approaches. Does this make one approach more desirable, and if
so, why?

Looping through the recipients; [...]
- places the processing burden on the web server

BCCing en mass; [...]
- places the processing burden on the mail server

I don't know how CDOSYS processes mail or what number of BCC recipients
may choke the process (we have approximately 300 club members). Are the
web and mail servers really separate resource caches at the ISP? If so, in
the case of the newsletter being sent, wouldn't looping through the
recipients require more mail server resources than BCCing, since 300
copies of the newsletter needs to be stored and processed?

Would creating such a message queue by looping prolong the processing time
for the ASP function? Creating the BCC list is instantaneous, but are the
spam blockers at ISPs receiving this mail more tolerant of individual
messages or BCCs (I didn't think that this group would be the best place
to inquire about that aspect, although someone here may know the answer)?

Best,

Neil

 

[Daniel Crichton]

Neil wrote on Thu, 15 May 2008 07:50:35 -0500:

Hi Bob,

Thanks for your response. I'm particularly interested in two of the
aspects that you've pointed out.

Recently, Bob Milutinovic <[email protected]> posted:

Looping through the recipients; [...]
- places the processing burden on the web server
BCCing en mass; [...]
- places the processing burden on the mail server

I don't know how CDOSYS processes mail or what number of BCC recipients
may choke the process (we have approximately 300 club members). Are the
web and mail servers really separate resource caches at the ISP? If so,
in the case of the newsletter being sent, wouldn't looping through the
recipients require more mail server resources than BCCing, since 300
copies of the newsletter needs to be stored and processed?

Would creating such a message queue by looping prolong the processing
time for the ASP function? Creating the BCC list is instantaneous, but
are the spam blockers at ISPs receiving this mail more tolerant of
individual messages or BCCs (I didn't think that this group would be
the best place to inquire about that aspect, although someone here may
know the answer)?

Neil

One thing you'll need to take into account is recipient limits on
destination servers. For instance, what happens if you use BCC and have 300
addresses being sent to, of which 100 are on the same domain, but the
recipient server has a limit of 50 addresses? The entire message may well be
rejected and so nobody at that domain receives it. This is where there is a
benefit to looping through the list and producing one message per address.
At our company we send to our own customer mailing list one message per
recipient because we customise each message, and we don't use ASP to send
the messages - we have an application that loops through the selections from
the database and generates the messages instead.

 

[Neil Gould]

Hi Daniel,

Neil wrote on Thu, 15 May 2008 07:50:35 -0500:


One thing you'll need to take into account is recipient limits on
destination servers. For instance, what happens if you use BCC and
have 300 addresses being sent to, of which 100 are on the same
domain, but the recipient server has a limit of 50 addresses? The
entire message may well be rejected and so nobody at that domain
receives it. This is where there is a benefit to looping through the
list and producing one message per address.

Even if 100 BCC recipients are on the same ISP, they receive individual
copies of the message addressed to each recipient. It would seem that
their server could recognize the messages as being identical in either
case, so what would be the basis for rejecting the messages (I suspect
they may be marked as spam, and I wish to avoid that outcome as well)? In
other words, is BCC handled internally by CDOSYS on the sender's mail
processor, or is it a method "visible" to the recipient's ISP?

At our company we send to
our own customer mailing list one message per recipient because we
customise each message, and we don't use ASP to send the messages -
we have an application that loops through the selections from the
database and generates the messages instead.

Is there a significant difference between an application that loops
through the database selections and an ASP function that does the same and
calls CDOSYS to process the message(s)?

Best,

Neil

 

[Daniel Crichton]

Neil wrote on Thu, 15 May 2008 14:31:15 -0500:

Hi Daniel,

Recently, Daniel Crichton <[email protected]> posted:

Even if 100 BCC recipients are on the same ISP, they receive individual
copies of the message addressed to each recipient. It would seem that
their server could recognize the messages as being identical in either
case, so what would be the basis for rejecting the messages (I suspect
they may be marked as spam, and I wish to avoid that outcome as well)?
In other words, is BCC handled internally by CDOSYS on the sender's
mail processor, or is it a method "visible" to the recipient's ISP?

BCC isn't handled by CDOSYS at all - it's all done by the servers.
Effectively the To:, CC: and BCC: are used to create the RCPT TO part of the
SMTP conversation (it's not quite that simple as the headers in the message
don't have to match the RCPT TO command, but it's easier to take the simple
case as an example). So the server you pass the message to splits that out,
normally by domain, and then feeds to the destination server. If that RCPT
TO has 1000 addresses, of which 100 are for DomainX.com, and the receiving
server at DomainX.com has a limitation of 10 addresses in the RCPT TO
command, then it'll reject the message - and none of the 100 recipients will
get it. It's the final receiving server that does all the work of splitting
the message out into each individual mailbox - but if your message gets
rejected before it gets that far, then it won't get delivered at all.

I've got my work mail server set only 10 recipients per message - so if you
were to BCC to more than 10 addresses here on a single message it would be
rejected.

Is there a significant difference between an application that loops
through the database selections and an ASP function that does the same
and calls CDOSYS to process the message(s)?

Not really, but if it takes 10 hours for my app to loop all the addresses,
that's fine - try doing that with ASP On occassions our system might be
sending well over 200,000 emails all customised to the recipient.

I actually use ASPEmail rather than CDOSYS simply because it's proven itself
to be reliable and it's very easy to use.

 

[Neil Gould]

Hi Daniel,

Neil wrote on Thu, 15 May 2008 14:31:15 -0500:

BCC isn't handled by CDOSYS at all - it's all done by the servers.
Effectively the To:, CC: and BCC: are used to create the RCPT TO part
of the SMTP conversation (it's not quite that simple as the headers
in the message don't have to match the RCPT TO command, but it's
easier to take the simple case as an example). So the server you pass
the message to splits that out, normally by domain, and then feeds to
the destination server. If that RCPT TO has 1000 addresses, of which
100 are for DomainX.com, and the receiving server at DomainX.com has
a limitation of 10 addresses in the RCPT TO command, then it'll
reject the message - and none of the 100 recipients will get it. It's
the final receiving server that does all the work of splitting the
message out into each individual mailbox - but if your message gets
rejected before it gets that far, then it won't get delivered at all.

Thanks for this explanation. It has a lot of implications, especially for
mail with attachments such as the newsletter. I'll write the code to loop
through the recipients.

Not really, but if it takes 10 hours for my app to loop all the
addresses, that's fine - try doing that with ASP On occassions
our system might be sending well over 200,000 emails all customised
to the recipient.

I actually use ASPEmail rather than CDOSYS simply because it's proven
itself to be reliable and it's very easy to use.

I've worked with ASPEmail before, but it may be overkill for the club's
needs. Yes, it is easy to work with once installed, but it is bulky. OTHO,
the ASP code is comparatively compact. I'll look to that app if the ASP
falls short for some reason.

Best,

Neil

 

[Adrienne Boswell]

Thanks for this explanation. It has a lot of implications, especially for
mail with attachments such as the newsletter. I'll write the code to loop
through the recipients.

If you are sending an HTML message, you might want to consider sending
multi-part, send plain text with HTML. In the text part, give a link to
the newsletter in HTML format, a link to the attachment, etc. Some email
clients automatically reject HTML mail, and some servers put it in a Spam
folder.

 

[Neil Gould]

Hi Adrienne,

If you are sending an HTML message, you might want to consider sending
multi-part, send plain text with HTML. In the text part, give a link
to the newsletter in HTML format, a link to the attachment, etc.
Some email clients automatically reject HTML mail, and some servers
put it in a Spam folder.

Thanks for the thoughts. At this point, the newsletter is a PDF file that
some members receive via email, although most download it from the club's
site. But, who knows what the future will bring?

Best,

Neil

 

[Adrienne Boswell]

Hi Adrienne,


Thanks for the thoughts. At this point, the newsletter is a PDF file that
some members receive via email, although most download it from the club's
site. But, who knows what the future will bring?

Best,

Neil

Then I would definately at least include a link to the relavent PDF file
in a plain text message.