Email bounce backs

[VK]

Hello:

Since our application uses ASP, I am posting this in this group. Pardon
if wrong group.

Our product/application replies a lot on bounced back emails, that way
we correct this and let the client know. Off late we are receiving very,
very few of these emails. It turns out, with amount of spamming going on
most of the companies have set up filters. As a result, most of emails,
even though incorrect don't get bounced back.

Is there another way to track bounced back emails?

Thanks.
Vani

 

[Aaron Bertrand - MVP]

Is there another way to track bounced back emails?

ASP in and of itself can't track anything like this. And sorry, if the
remote mail servers are just swallowing up your messages and stuffing them
into dev/null, there is no way for any other system to track them either.
They're just gone.

If you have a lot of messages like this that are being rejected because the
recipient is invalid, then it might be telling you something (e.g. get a
more reliable, read: OPT IN list!).

If your content is of any value, you should be able to track *successful*
e-mails (because they will go to your site with a referral link, etc). The
delta represents unsuccessful (regardless of the reason). You can also set
CDO to demand return receipts so, even if the e-mails are not "successful"
per se, and are merely deleted by the recipient, you can at least know they
were delivered successfully. See http://www.aspfaq.com/2252 for details.

 

[VK]

To elaborate a little more, emailing part is controlled by users. Each
user nominates (via entering their email address) their "raters"(about
10 to 15 of them) and each group has about 40-50 such users. This would
be for one project and we have more than one, online.

This volume is high to monitor read receipts.

thanks.

 

[Aaron Bertrand - MVP]

This volume is high to monitor read receipts.

HUH? Originally, you said:

So, can you describe the difference between receipts and bounces? If you
send out 5000 e-mails, and half or failures, you are either going to have to
process 2500 rejects or 2500 successes. I'm not sure how volume impacts
choosing one way over another; though what I previously said still stands:
you can't rely on failed deliveries to be reported.

 

[VK]

Bounced backs emails are those that are undeliverables - they return to
our inbox stating as undeliverables. that way we know that this email is
incorrect and hence we were able to track emails that were faulty.

 

[Aaron Bertrand - MVP]

Look, I was only suggesting an alternative. If it's "too much," then don't
use it. Simple, huh?

 

[Ray at]

You won't find your easiest solution using ASP. Export the bounce back
messages to a some sort of a datasource and then compare it against your
database of e-mail addresses to filter out the bounce backs.

Ray at work

 

[Aaron Bertrand [MVP]]

You won't find your easiest solution using ASP. Export the bounce back

messages to a some sort of a datasource and then compare it against your
database of e-mail addresses to filter out the bounce backs.

Not to belabor the point, but VK expects to somehow track the messages that
are sent to invalid addresses but are *NOT* bounced, but rather merely
swallowed by the remote mail server (/dev/null, bit bucket, recycle bin,
circular file, what have you).

So my suggestion was to track the *successful* IMHO, if he's getting enough
bounces that it's an issue, volume either way shouldn't be an inhibitor.