if i wanted to send an email to, say, 1000 people, which would be
faster - sending a single email with a really large bcc field or
sending out one email for each person? one advantage of sending an
email to each person, personally, is that it'd be easier to detect
bounced emails and delete them from the database via variable return
envelope paths.
also, what other considerations, aside from speed, are there?
"yawnmoth"
news:1108758609.480742.199490@o13g2000cwo.googlegroups.com
> if i wanted to send an email to, say, 1000 people, which would be
> faster - sending a single email with a really large bcc field or
> sending out one email for each person? one advantage of sending an
> email to each person, personally, is that it'd be easier to detect
> bounced emails and delete them from the database via variable return
> envelope paths.
>
> also, what other considerations, aside from speed, are there?
Whether the recipients even want the bulk email is the biggest concern;
nobody likes spam.
On 18 Feb 2005 12:30:09 -0800, "yawnmoth"
>if i wanted to send an email to, say, 1000 people, which would be
>faster - sending a single email with a really large bcc field or
>sending out one email for each person? one advantage of sending an
>email to each person, personally, is that it'd be easier to detect
>bounced emails and delete them from the database via variable return
>envelope paths.
>
>also, what other considerations, aside from speed, are there?
Apart from what the other poster said, and asuming that all those
recipients are clear opt-in's of YOU and where you have proof of this,
the bcc variant is faster. This of course is only true if the mail
server you use to send the mails out is not crap. They usually sort
the recipients by domain. Then per domain they connect to the
apropriate mailservers, name all recipients there and transmit the
mail message body only once.
If your outgoing mailserver is not crap, it will generate a single
bounce to you with all recipients where there were problems. Ok, if
there are mailservers on the path which do not have a list of valid
recipients or if they simply accept every recipient first hand you
will get individual bounces in these cases. Still they will tell you
which e-mail addresses are invalid. Again, don't do this if you don't
have a list of clear opt-in recipients and if this bounce thing is
only to get outdated mail addresses cleaned out.
Markus
ynotssor wrote:
> "yawnmoth"
> news:1108758609.480742.199490@o13g2000cwo.googlegroups.com
>
>
>
> Whether the recipients even want the bulk email is the biggest
concern;
> nobody likes spam.
It's for a MODification I'd like to make of phpBB. If someone doesn't
want email from the board, they shouldn't sign up, or they should
select the appropriate option, IMHO.
In article <1108763262.911271.24780@g14g2000cwa.googlegroups.com>, yawnmoth
says...
> It's for a MODification I'd like to make of phpBB. If someone doesn't
> want email from the board, they shouldn't sign up, or they should
> select the appropriate option, IMHO.
You do have a mechanism in place to ensure that somebody can't forge-
subscribe somebody else?
--
Norman
~Win dain a lotica, En vai tu ri, Si lo ta
~Fin dein a loluca, En dragu a sei lain
~Vi fa-ru les shutai am, En riga-lint
NormanM wrote:
> In article <1108763262.911271.24780@g14g2000cwa.googlegroups.com>,
yawnmoth
> says...
>
>
>
> You do have a mechanism in place to ensure that somebody can't forge-
> subscribe somebody else?
if someone is forge-subscribed, an email confirming the subscription
will be sent to them, along with login info which they can use to
uncheck the appropriate options, to ask an admin to delete them, or
whatever.
it might not be the ideal solution, but to be honest, i'm not really
sure what an ideal solution would be like.
In article <1108872192.243691.205660@o13g2000cwo.googlegroups.com>, yawnmoth
says...
> NormanM wrote:
> > In article <1108763262.911271.24780@g14g2000cwa.googlegroups.com>,
> yawnmoth
> > says...
> >
> > You do have a mechanism in place to ensure that somebody can't forge-
> > subscribe somebody else?
> if someone is forge-subscribed, an email confirming the subscription
> will be sent to them, along with login info which they can use to
> uncheck the appropriate options, to ask an admin to delete them, or
> whatever.
Rather than confirming the action of subscribing, and telling the recipient
to unsubscribe, request that the recipient pro actively act to complete the
subscription; if the recipient was forge-subscribed they should not have to
do any more than ignore the confirmation request to avoid being added to the
list.
> it might not be the ideal solution, but to be honest, i'm not really
> sure what an ideal solution would be like.
The ideal solution is a confirmation step for the would-be subscriber to
confirm the subscription request, with a hard-to-forge token included. The
recipient pro actively acts to confirm the subscription within a period of
twenty-four hours, or the email address is not added to the subscription
list.
--
Norman
~Win dain a lotica, En vai tu ri, Si lo ta
~Fin dein a loluca, En dragu a sei lain
~Vi fa-ru les shutai am, En riga-lint