tags:

views:

264

answers:

6

Our clients sometimes don't get the emails that we send out. It's a BIG loss. How do I assure that they receive the emails so that if it's not received in the other end, the program can resend it or do something about it.

+2  A: 

There's not really a good way to determine if the email actually arrives in their inbox, you can only confirm that you sent it. Attach a receipt that lets you know when they open it perhaps?

Chris Ballance
A: 

Microsoft Outlook provides similar functionality, however it is based on the email client. I'm not sure if other clients, like Thunderbird, support this.

However, there is nothing in the protocols that specify receipts.

One option that may work: send a link to a generate web page and monitor that page for hits. This provides its own issues however: confidentiality, etc.

cbrulak
-1 for receipts - Thunderbird and most non-outlook clients either refuse to send receipts or give the user the option to send it.+1 for links in the email that allow the server to verify an inbound link from an email.
scunliffe
+3  A: 

There is no standard way to know whether the email reached the destination. Many email clients support different types of receipts though. You can use any of those if you want.

There are some ways to know when the user actually read the email.

There are many techniques like adding an image to your email that is to be fetched from your web server. When the user reads the email, the request for the image comes to your server and you can capture the event.

The problem is that there is no way to know that the mail did not reach the destination.

Niyaz
+4  A: 

One thing that you can do is set up a bounceback address that receives any mail that is undeliverable. Use the bounceback address as the From address -- you may want a different one for Reply-To so that replies get directed properly.

Check the bounceback mailbox daily and contact customers to get updated email addresses for the ones that fail. You may be able to automate a couple of retries to failed addresses before resorting to the manual contact in case the failure is only intermittent.

This would take some code outside your application that scans the mailbox and keeps some state information about the number of contacts, etc. and attempts the resend.

Depending on how you generate the mails, you might be able to make this process easier: generate a unique bounce address for every single email you send out. You could use [email protected], for example.

Many SMTP servers will allow you to use the part after the + as a parameter to an external script, etc.

The problem is that many (broken) SMTP servers don't return enough info with a bounce to identify the original message -- sometimes, when there are forwardings involved, you don't even get back the original addressee...

With the above trick you can reliably correlate outgoing messages with incoming bounces.

tvanfosson
this method is about as thorough as it can get -- smtp does fundamentally not guarantee _anything_. be aware thought, that a relatively high percentage of all mail will bounce -> plenty work for the poor sob with the bounceback mailbox (aka. me)
hop
tvanfosson, i hope you don't mind this edit!
hop
And hope your bounceback address never gets used for a joe job.
David Thornley
@hop -- not a problem.
tvanfosson
@david: in case of a joe job you are waaaay better off with this method than with a simple static addresse: you just block (or remove from the inbox) all mail that is addressed to the bounce+id@ the spammer used. everything else is uninterrupted.
hop
+8  A: 

None of the suggestions above will work 100% of the time. Many email clients will (rightly so) refuse to load foreign images, negating the usefulness of "web bugs". They will also refuse (or be unable to) return Outlook-style "receipts". And many mail servers either deliberately (to curb spam) or mistakenly (due to misconfiguration) won't return bounce messages. Or possibly an over-aggressive spam filter ate your message, so it arrived but was never seen by the end user. Plus there is the little matter of mail taking hours or days to reach the end user or bounce, and how do you correlate these late notifications or bounces with the mail you sent 4 days ago?

So basically, you can catch some but not all, no matter what you do. I'd say that any design that relies on being able to know with certainty whether the end user got your mail is fatally flawed.

Paul Tomblin
+1: "any design that relies on being able to know with certainty whether the end user got your mail is fatally flawed"
Adam Davis
+1  A: 

I worked on a bulk email system in a previous life. Deliverability was one of our major issues. The most common cause of undelivered emails is a spam filter.

Here are the steps we took to ensure the highest delivery rates:

  • We used Return Path to test emails for that spam-like smell.
  • If you send a lot of emails, you need to make sure your SMTP server is not blacklisted.
  • Remind your users to add your FROM address to their "safe senders" list.
  • Use a system that collects bouncebacks and use them to scrub your mailing list. This will also help keep you off the blacklists.
  • If the emails are critical, consider sending them return-receipt-requested. This will not really guarantee anything, but it might give you some metrics on actual deliverability.
Dave Swersky