Howto: SaaS email integrationSoftware as a Service or SaaS solutions are everywhere these days, from CRM through purchase to pay and on to a wide variety of applications both bespoke and off the shelf.
One thing they almost all have in common is that they need, occasionally, to fire off an email to a user of the system or a third party. Sometimes these are for information and sometimes for action, but they are all email and they have those two most basic characteristics of an email, namely a sender and a recipient.
Blindingly obvious so far, right? Where's he going with this?
Suppose you have two users of the Acme CRMaaS system, let's call them Janet and John or, to give them their full names, janet@example.com and john@example.com.
Janet takes a telephone call from one of John's customers and logs it in Acme CRMaaS. John has configured Acme CRMaaS to prompt him with an email when there is any activity on his customer accounts involving other users, so AcmeCRM sends an email to john@example.com. The email comes from janet@example.com, although Janet has sent no email, but this is not a problem. Should John have a query about the matter, he can just hit reply and Janet will receive his email in reply to her earlier interaction with John's customer.
That's all working very smoothly. What could go wrong?
Well, like any open loop system, this does not fail safe. There are plenty of scenarios that could cause problems, but here are just a couple.
- John is a new user to the CRMaaS system. The administrator has misspelled his name. He is really Jon and his email address is jon@example.com. Now what happens to Janet's email?
It bounces.
Where to?
Well, Janet of course.
Never mind. Janet can just resend the email to Jon, can't she?
- Well, she could, but she just left on vacation for two weeks. Of course her email program (Lotus Notes) is far too clever to do anything really dumb like send an Out of Office notification to postmaster in response to the bounce, but now Jon has no idea that his customer is ready to close the deal today and cannot wait until tomorrow before going with the competitor's offering.
The fundamental mistake being made here by the developer of the Acme CRMaaS system is that he has chosen to ignore the difference between RFC2821 and RFC2822. Specifically, he has chosen to put the same content into both the RFC2821 sender envelope and the RFC2822 from header, that is <janet@example.com>
Now of course it is useful for Jon to see an email from Janet when she has recorded activity in the Acme CRMaaS system. This is the RFC2822 from header and it is perfectly appropriate for that to contain <janet@example.com>
But what purpose is served by also using that as the sender envelope while the message is being transported? Message transport is usually fairly robust but it can break and, when it does, the message return path (which is typically the sender envelope unless overridden by headers) actually does have a use.
Suppose that, instead of <janet@example.com> as the RFC2821 sender envelope, the Acme CRMaaS system were to use something like <transaction_unique_id@acmecrmaas>.
Provided that <janet@example.com> still exists as the from field in the message headers then Jon can still respond to Janet after the email is delivered just by hitting reply but, if the message fails in transit, then the AcmeCRMaaS system itself now knows about the failure because it receives a uniquely identified bounce message which unambiguously tells it exactly which system generated message failed. This leaves further options open to the developer of Acme CRMaaS to handle an error which would otherwise simply have been assumed not to have happened.
The developer could, for example, choose to fall back to some backup messaging medium like SMS. He could pop a window onto Janet's screen (she hasn't left on vacation yet) warning her that Jon doesn't know about this latest customer information. He could log the error, report it to an administrator, anything he likes because he now knows about it where previously he didn't.
Which of these failure modes is the more resilient and the more flexible? The one that assumes nothing bad ever happens and drops badly formed errors into unsuspecting users' laps, or the one that intercepts the error and passes it back so that it can be systematically handled and disposed of?
One other thing.
Many email shops have policies in place that refuse email with sender envelopes in their own domains. The use of victims' domains in sender envelopes is a very common spam tactic. The spammer can have two bites of the cherry if his message is from user1@example.com and to user2@example.com because, if mail to user 2 is rejected, the bounce will go to user 1.
Companies which have implemented systems like the Acme CRMaaS system have had no choice but to disable the policy of rejecting as spam email purporting to be from their own domains because this also defeats Acme CRMaaS messages.
So, not only do we have here an open loop or unchecked failure mode which is present in every SaaS system I have yet seen but, adding insult to injury, we also have to disable an important anti-spam feature to make up for the developers' incompetence.
I do hope some of them read this and get a clue.
Category: Software
Technorati: email SaaS
Unable to post a comment? Please read this for a possible explanation...
- 
