4

Summary:

We are looking to expand our use of email for notification purposes. We understand it will generate more inbox volume, but we are being selective about which events we fire notification on in order to keep the signal-to-noise ratio high.

The big question we are struggling with is designing a system that guarantees that the email was delivered. If an email isn't delivered, we will consider that an exception event that needs to be investigated. In reality, I say almost guarantees because there aren't any true guarantees with email. We're just looking for a practical solution to making sure the email got there and experiences others have had with the various approaches to guaranteeing delivery.

TL;DR - How do we go about designing a system to guarantee delivery of emails? What techniques should we consider so we know the emails were delivered?

Additional concerns:

Our biggest area of concern is what techniques to use so that we know when a message is sent out that it either lands in an inbox or it failed and we need to do something else.

Additional requirements:

  • We're not at the stage of including an escalation response, but we'll want that in the future or so we think.
  • Most notifications will be internal to our enterprise, but we will have some notifications being sent to external clients.
  • Some of our application is in a hosted environment. We haven't determined if those servers can access our corporate email servers for relaying or if they'll be acting as their own mail servers.

Base design / modules (at the moment):
A module to assign tracking identification
A module to send out emails
A module to receive delivery notification (perhaps this is the same as the email module)
A module that checks sent messages against delivery notification and alerts on undelivered email.

Some references:
Atwood: Send some email
Email Tracking

Approaches we've considered:

  • Request a response (aka read-receipt or Message Disposition Notification).
    Seems prone to failure since we have cross-compatibility issues due to differing mail servers and software.
  • Return receipt (aka Delivery Status Notification).
    Not sure if all mail servers honor this request or not
  • Require an action and therefore prove reply.
    Seems burdensome to force the recipients to perform an additional task not related to resolving the issue. And no, we haven't come up with a way of linking getting the issue fixed to whether or not the email was received.
  • Force a click-through / Other site sign-in.
    Similar to requiring some sort of action, this seems like an additional burden and will annoy the users. On the other hand, it seems the most likely to guarantee someone received the notification.
  • Hidden image tracking.
    Not all email providers automatically load the image, and how would we associate the image(s) with the email tracking ID?
  • Outsource delivery.
    This gets us out of the email business, but goes back to how to guarantee the out-sourcer's receipt and subsequent delivery to the end recipient.

As a related concern, there will be an n:n relationship between issue notification and recipients.
The 1 issue : n recipients subset isn't as much of a concern although if we had a delivery failure we would want to investigate and fix the core issue.
Of bigger concern is n issues : 1 recipient, and we're specifically concerned in making sure that all n issues were received by the recipient. How does forum software or issue tracking software handle this requirement? If a tracking identifier is used, Where is it placed in the email? In the Subject, or the Body?

Improve this question
12
  • 2
    I am confused as to what you are asking. Are you wanting us to define your requirements?
    – SoylentGray
    Jul 5, 2012 at 16:38
  • 1
    "but we are being selective about which events we fire notification on" Well, once it is up and running, some PHBs will know better than you. Guaranteed delivery doesn't mean guaranteed reading, of course. Above a given threshold, nobody will (or can) bother anymore, but at least it is good for archiving purposes. Though a simple log file would provide this, too.
    – Secure
    Jul 5, 2012 at 16:44
  • 4
    Within your own controlled environment you can track and even prove that an email has been delivered. Outside you your controlled environment you can't, that's why for critical notifications you rely on more then one communication technique. (Texting to mobile phones comes to mind.)
    – Pieter B
    Jul 5, 2012 at 16:58
  • 1
    @Pieter B is correct. Unless you can run a local client of some kind on the customer's computers you cannot devise an automatic system that will guarantee that the email was delivered to whatever arbitrary email system the customer uses. This falls in to the same PHB anti-pattern that asks developers to send web pages with invisible html or install non-copyable files.
    – Jim In Texas
    Jul 5, 2012 at 17:06
  • 3
    @GlenH7 Plan to fail and not be notified of the failure. As all the other comments mentioned, there's no guarantee that the message (email or sms) will arrive let alone be read. How you escalate this is probably more important than whether the original message(s) are delivered. At one place I was at, we used a callout list, email, sms, banner at the top of the "monitoring" web site, and a push/pull API. None of these actually guaranteed that someone would respond to or acknowledge the incident.
    – hafichuk
    Jul 5, 2012 at 17:23

2 Answers 2

Reset to default
9

Technically, you can't, since SMTP is designed in a way that you can't know for sure if the email was delivered.

If you're sending legitimate emails and their potential readers are willing to help you (for example some critical notifications sent to the employees of your company), then "Request a delivery receipt" option comes to mind.

Of course, if one of the employees don't want to send the receipts back, you'll never know if the emails were delivered or not. The same comes for people who explicitly set their email client to discard any delivery receipt requests.

If you want to be sure the messages are "technically delivered" to the users, then consider another way, like showing those messages on your corporate website and log the access of the users.

Last but not least, even if a message is displayed to a user, it doesn't mean the user read it.

Improve this answer
5
  • 1
    If you mangle the username part of the address the external email system may be programmed to not tell you. This is done to reduce spam. This can also be a problem if they leave the company.
    – mhoran_psprep
    Jul 5, 2012 at 17:28
  • 1
    Even if you do have delivery receipts you don't know if the email was spam foldered by the user or deleted without reading. Do you need guaranteed delivery or do you need it to be actually read?
    – Martin Beckett
    Jul 5, 2012 at 17:38
  • @MartinBeckett - I just need it to be received or notified as rejected by the target email system.
    – user53019
    Jul 5, 2012 at 17:58
  • @GlenH7 - So if all email sent by your system is flagged by Google as spam, and the user never reads the email, that would meet your requirements. Just saying that seems like it would not.
    – Ramhound
    Jul 5, 2012 at 19:07
  • @Ramhound - There are a couple of ways that could meet my requirements. A) if Google kicked it back with a notification of SPAM! (or whatever) then yes, that's acceptable. B) If google passes it through to their Spam folder, that's acceptable as well. What I don't want is the email to be shuffled into electron recycling without notification back.
    – user53019
    Jul 5, 2012 at 20:08
4

The only reliable way to guarantee an email was received/at least skimmed is including a verification link the receiver must click. If this is too inconvenient, which is likely, then you need to rethink your reliance on email for message delivery. Email was never intended to be used in this manner so it was never designed to make it easy to implement this behavior. Your workflow process needs to be revisited if dependency on email notifications is critical to system success.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.