E-mail is unreliable
Having worked on various projects where e-mails were used I came to this exact conclusion. E-mail is unreliable, as a medium.
It is not obvious while coding it happily, but certainly gets painful after doing maintenance over an application for a prolonged period of time.
“I’ve sent an e-mail and now it’s not my problem” attitude, assumption that an external component always works, will bring trouble to the final product.
Let’s look at using e-mail in the app-wide, business-wide perspective.
You are blacklisted
The fact that the mail was sent only means it was actually sent, not delivered.
E-mail sender can be blacklisted, e-mail host can have DNS/RDNS problems, receiver’s filters can mark the message as a spam, or someone can delete an e-mail accidentally.
Many of these problems can be fought individually, like regularly checking the status on blacklists, or testing proper non-spam e-mail (experimenting with content, images, links and attachments). But not all problems can be solved.
We can ask our users or clients to add the address to their whitelists. Still, we have no control over it.
If we assume e-mail is unreliable, we can build a system around that.
E-mail or not
If this is really important, not using e-mails is always an option. Or using e-mails only as a support/reminder, and having a web app where any client can log in and check what he needs to check. If the e-mail is not delivered, that client can log in and e.g. download his invoice.
By they way, we can’t undo sent mail, and we certainly can change something in our system before the client sees it.
Similarly, if an e-mail is sent automatically when an unexpected error or “situation, that can’t happen” happens, the action can’t be only taken when an e-mails is sent.
Looking at logs should be done manually on a daily/weekly basis as well.
Another option to manage e-mail completely is using some commercial delivery system. For example Sendgrid, Postmark, Amazon SES, or others (in comparison).
Safekeepers
When using e-mail in a software, these tips should be useful:
- logging if an e-mail was sent or not,
- “send again” button (including all attachments),
- possibility to view the message and attachments from the UI
- proper code structure
This is one of the cases when bad architecture or incomplete requirements, can be as much problematic as bad code. Please do not tight-couple e-mails with other functionalities. Use single responsibility principle.
Think of e-mails like external components. Create libraries or services just for them.
E-mail is two-way, not one-way
The sender of an automatic e-mail is usually some kind of no-reply@mysite.com, which assumes recipient will not reply.
My experience and Murphy’s Law tell otherwise. People will respond because there is a technical possibility to do so.
A solution could be using current active e-mail e.g. sales@mysite.com. Have in mind that people might like to create rules in their e-mail software for incoming messages from no-reply@mysite.com to separate automatic notifications from conversations.
(Faking the “From” field to point to a non-existing e-mail, so the client will get delivery error, is not a solution.)
Simpler would be just redirecting received e-mails to someone responsible for support. Or making use of the “Reply-To” field.
Using automatic response “Please do not reply here” for no-reply@mysite.com will just cover some backs. It won’t guarantee catching one important e-mail from an important client.
Summary
Implementing e-mails to an application can’t be done in a “Just send those reports” style. Stable solution being under control needs an approach from a wider perspective.
In the end, if the client deletes his report accidentally, without any countermeasures taken, the development team will be at fault. “I never received any e-mail, your software doesn’t work”.
Leave a comment