You have new mail

Because I often get this alert when launching a new Terminal session on my Mac and because I always forget the command to supress it, I’ve written you (myself) a little reminder.

When You have new mail is displayed, hit :

mail

You’ll get the number of mail in your queue list :

"/var/mail/alex": 11 messages 11 new

Regarding this number, hit the following number :

delete 1-* (Replace the * by the number)

And quit by hitting :

q

Result:

No mail for alex

You’re welcome ;)

Why you need transactional email services for your web application

Let’s meet

Lessons learned from sending emails, that’s for sure ! This article will explain what transactional-email services are and give you the reasons web application needs such email services.

I’ve based this article on the many situations we’ve dealt with about sending emails from web applications.

Ready ?

Definitions

For clarification, I’ll give a short definition of what a transactional email is : it’s an email sent to a user email address after having done a specific action on a website. Compared to newsletter, they are never sent in a bulk.

Common transactional email scenarios are :

• The registration confirmation email you receive.
• The recover your password email you’ve asked.
• The someone replied to your comment email you receive.

Or even simpler :

• The contact form you’ve just filled in needs to reach its recipient.

I simply mail()

mail() (PHP 4, PHP 5) — Send mail
Eg : mail(‘caffeinated@example.com’, ‘My Subject’, $message);

I known what you’ll say : Why should I bother using a third-party system when basic programming languages provide me functions to send emails ? And even more, you’ll say : Using the those basic functions in my development is super-simple.

All of that is true, until it broke.

Why you need a transactional email service ?

1. Transactional email works

   Because it’s sent after a user action, the transactional email is personal, suitable and requested by the end-user. According to the CAN-SPAM - The 2003 US Act fixing national standards for sending commercial emails - transactional emails have an open-rate of 47% and a CTR (Click-trough-rate) of 20%. This is huge compared to the average 30% open-rate and 6% CTR that you’ll have with any commercial emails/newsletter.

2. Sent, or not : that’s the question

   For now, how could you be sure the email which was supposed to be sent was actually received ? Seen from a business perceptive, this question could be critical : you’ve launched a brand new commercial website and customers can request a quote by filling a form in. Months later your launch, no quotes has arrived. How would you know if forms were actually filled in ? Was the email’s recipient correct ? Was the email sent but lost after it ? Did it bounced ?

   So many question will stay unanswered. And your business would have lost money.

3. Sending email relies entirely on the server

   That’s the real problem ! The mail() function depends on your hosting server configuration. And believe me, that’s a full-time job.

   Do the test, right now :

   • Do you know what’s the php.ini file for ?
   • Does your server use Postfix or Sendmail ?
   • If so, is the php.ini properly configured ?
   • Is your server IP whitelist-ed ? Does it have sending limit ?
   • How do you check you email queue ?
   • Do you know what are DKIM or SPF ?

   If you can’t answer one of the following question, you should not trust your server to send your emails. It would be the same as giving your mail to a guy in the street saying : « I’ve a vague idea where the post office is »

4. Sending limit

   Chances are good that you’re hosting your website on a shared hosting provider. They are good and not expensive, totally suitable for your needs. But many of them have a daily sending limit.

   What will happen to your user requesting a ‘forgotten password email’ when your quota will be exceeded ?

5. SPAM

   World is beaten by SPAM.

   The California legislature found that spam cost United States organizations alone more than $13 billion in 2007, including lost productivity and the additional equipment, software, and manpower needed to combat the problem.
   [http://en.wikipedia.org/wiki/Spam_(electronic)#cite_note-32]

   Because of that, many methods and technics have been set up in order to prevent SPAM from being sent. Two of the most famous are the DKIM and SPF records. Without being technical, both of them are « authorization code » placed on your server giving email providers (such as Outlook or Gmail) the proof that the email is not spam.

   With those record, you’ll have the most chance to see your email going into your recipient inbox. Without, as it’s the case on most shared hosting, you don’t.

   The worst-case scenario for you it to start thinking : « Was the email sent to the SPAM folder of your customer ? If so, why is it considered as SPAM ? »

6. Report as SPAM

   You surely have seen this button on your email inbox before, the famous report as spam button. But did you know that if your Internet Service Provider supports a system called feedback loop, this report is logged as an abuse complain. When too many abuse complain are filled, it may lead to the ban of your server IP address.

7. It’s cheap

   Transactional email services are cheap : simply because sending an email costs nearly nothing.
   On average, you’ll pay $1 for 1.000 sent emails. I’m not the best at maths but it’s simple to understand that it is better to pay $1 per 1000 emails than taking the risk to lose a single sales-related email.

8. It’s not your job to send emails

   Either your are a business owner or a PHP developer, focus on your real job. Do not try to configure the server yourself. It’s a lost of time. Professional transactional email services are in the business for ages. They know how to handle technical topics such DNS, whitelisting, ISP throttling, content scanning, SPAM reporting and monitoring. Their servers are configured and run only for this purpose, not to handle Apache, Mysql, Rails, Stats and Mail requests at the same time.

9. It’s scalable

   I wish your web application success.

   But let’s imagine the day your web application will do the newspaper front page or will be featured on an article on NetTuts+, your server may get thousand of registration emails to send and deal with. If your server is not cloud-based and scalable within minutes, it will crash for sure. If you have luck, Apache (the service displaying the webpage to end-user) will take all the ressources and nothing will be left for sending those welcome emails.

   Transactional emails services completely set the email process out of your server equation.

10. It’s customizable

    Often, transactional email services allows you to modify the template or text of your email without any coding skills. There is no need to call your developer or open your coding editor and FTP program in order to modify your email.

11. Two-Way & Inbound messages

    If you are developing a support platform by example, you’ll want to provide your user the possibility to directly answer the message from their email software. Those answers can be automatically processed by the transactional service and sent back to your application. Once more, you are complexity removing the email managing questions out of the equation and simply have to focus on grabbing the received information.

12. Statistics

    How many transactional email your application sends per month ? Have they been read or even opened ? That’s a strategic and important marketing question that needs to be answered. Good transactional email services provide you those statistics and help you controlling the ROI (return on investment) of your web application.

13. There is simple integration

    Many transactional service comes with fully documented API and examples for PHP, Ruby on Rails, Python or Objective-C. They even sometimes offers you free Wordpress, Joomla plugins. Their integration becomes very easy and should not take you more than a few minutes.

Epilogue

I’ve no partnership with any transactional email services and I should I did. Simply because I believe so much in their success and have learned how much help they provide to your application. Without them, you’re in the dark regarding your emails. The relation you have with your users is so important you can’t take the risk to lose communication with them.

I hope you’ve enjoyed this article. I’ll be happy get your reviews and continue the discussion under the form of comments.

This tweet of Simon Allardice - this guy writes code and creates courses for the awesome lynda.com -  remembered me the Mat Honan Epic Hacking Story (if you’ve missed that one, go read it now). 

And what about you ? How is your backup doing today ?

@alexisserneels luckily, my own paranoia means my backup story is pretty tight. Even a HD crash shouldn’t be more than an inconvenience.

— Simon Allardice (@allardice) Août 31, 2012

Dear you

You’ve ended up on this website and there could be hundred of reasons to this. You could,

• Be using the CMS we’ve developped for you at Doodle Web Agency.
• Be listening to my french voice on a radio station.
• Be matsering your radio shows with Freqq, the smart player for radio stations.
• Be thinking about purchasing my CodeCanyon script.
• Have heard of me around the amazing CodeIgniter community.
• Be trying to connect yourself on the Knowledge Management platform for the Federation of Scouts and Guides of Belgium.
• Also have a MASTER in Public Relation from IHECS University.
• Be reading my Twitter or Facebook profile.

Wathever is your path, you should know I used to write a lot on my personal websites. I don’t anymore. Pitty time. Sorry.

Anyway, here is the crème de la crème for you. And to get the full and protocol version of my life, please have a look at this page.