How do you deal with the uncertainty of email?

Question

I'm working on several processes which could potentially run into problems that must be solved by people. Currently it logs these errors and sends an email to relevant individuals.

But email seems to be the weak link here. Problems I run into: email server is down, the email gets caught in a spam filter, email "never arrived."

Do I need to build in some kind of intra-mail and require users to check yet another inbox, or are there any things I can do to feel more comfortable with my email notifications? Can I require open-receipts or anything like that, and if it's not opened then email again? Other ideas?

Answer 1

Hi, I also use e-mail notifications but I also have all these messages in a database table with a flag if it's related to data import, wrong password etc.

Users, when notified or not, can see this log (or timeline) in a way how Trac (bug tracking software) or Facebook displays news. It's a feed which you can filter by various criteria.

Some people might be interested in data import related messages or errors, other ones in authentication problems etc.

Other thing is - you can send these notifications via e-mail or make more "broadcasters" like Jabber/XMPP messages, twitter posts, what your users like.

Answer 2

You could have the user click a link included in the email to acknowledge receipt of the email. Emails not acknowledged after a certain period of time can be sent again or escalated.

Answer 3

You should code for "server is down". If the emails can't be sent, you need to queue them to be sent as soon as possible.

You should explicitly tell users it's up to them to put your messages on the "not spam" list. You shouldn't be worrying about the spam filter.

Email "never arrived" isn't very common at all in practice, as long as you've written code for when the server is down.

Finally, you can put a click-to-acknowledge link into emails, and resend an email hourly until a notification is sent back.

Answer 4

I would probably build in some sort of status page, where all (or some; it depends) of your users could see all outstanding errors. That way if an email never arrives, there's still some record of the task the user needs to complete. (from a usability standpoint; its easier for me to check a webpage than another email account).

I might also build in some sort of task that will go through all your outstanding errors, and maybe email the user again after X amount of days. (granted, this solution requires some way to mark the errors off as resolved; maybe set up a mailbox that the user can reply to when they've acknowledged/fixed the problem; and have something monitor that and update your log table)

Answer 5

I know most email clients support the option to notify the sender when the email is read which sounds exactly like what you're looking for. Unfortunately most clients also give the user the option not to alert the sender.

Answer 6

These days, email tends to be a lot more reliable than the people who work with it. Something you should consider is that in a lot of cases people just come up with excuses for not receiving an email.

Short of having a Skynet-like setup where the main computer can dispatch killer robots to your targets, you are essentially bound to delivery via the Internet. You've identified a lot of the potential weaknesses; there are workarounds for most, which I will try to enumerate.

• First, your app. I'll assume it's sufficiently redundant that it's never going to be too down to report. At the very least, you have redundant, reliable watchdog services.

• One mail server could go down. OK, so get a second one!

• Your network could go down. Bafflingly, this does happen in the big company I work in. So important stuff is rigged to run over two independent internal networks.

• If you only have one Internet line to the outside world, there's a chance your connection will be gone when you most need it. A sensible plan calls for redundant Internet connections. For emergency purposes, your backup connection could be wireless - UMTS or GSM or whatever they may call it in your country.

• You have a choice of running your own in-house mail server, distributing directly to the Internet, or using a commercial email service. If there's nothing confidential in your mails, I'd consider Google Mail for one of the outgoing paths. It has pretty solid up times and is well maintained. Your other outgoing mail server should probably be within your company.

• The weakest link is your recipients. You need to be sure they get their mails. To nab the "spam filter" excuse and others, have your server mail all the respondents once a week and have them reply, including the randomly generated subject. This will confirm to you that, at least within the previous week, your recipient was getting his mail. If not, investigate.

• Email to your recipients' mail box is not the only alternative. Once you get out to the Internet, there are alternatives like SMS and paging services. These get you as far as the recipient's phone. Once contacted, they can phone in or check their company email.

If you're running NORAD, you may need even better foolproofing on your messaging. Otherwise, attention to the above points will make your operation as bulletproof as it's likely to get.

Answer 7

To avoid having your mail dumped into the spam folder, you can read this great resource

Answer 8

You could use an RSS feed rather than email.