Sending Emails through Web Applications

By Tomer S.

Jul 20, 2016

At the start of the first lecture at the university, the Professor introduced himself, then turned to the students and said: “In case anyone was confused and did not understand until now, this course deals with Calculus.”

Ten students found out they came to the wrong class. I felt the same unpleasant feeling these students felt when I discovered a few weeks ago that e-mails sent through the app got into Spam instead of the “Inbox.”

To find out the problem, I used an excellent site called “Mail-Tester.” Mail-tester is a convenient platform for testing whether an e-mail sent through our app reaches its destination or not. The site rates the chances of success in sending emails to the Inbox, using an open source anti-spam platform that classifies emails and block spam called Spam Essien.   

By using Spam Essien, the site rates the chances of this happening from a grade of 1 to 10. A grade over 9 ensures that almost 100% of the time the the e-mail arrives in the inbox. In addition, the website allows us to discover not only the final grade but for also what lowered it via a comfortable interface that describes all the reasons causing the decrease. This helps improve the sending of e-mails by changing the code in the mail template, so it boosts your rankings and brings the e-mails to the promised land.

Message only has text / html MIME parts 

When I checked my e-mail grade using the “Mail-Tester” I discovered that what decreased significantly the rating and caused it to be sent to Spam was: “Message only has text / html MIME parts.” (MIME – Multipurpose Internet Mail Extensions)

This description indicates the e-mail lacks the plain-text part. Plain-text is not just a “pure sequence of character codes” as it is declared according to The Unicode Standard, but it is also a great indicator for classifying emails and blocking spam. Sending Emails through web applications can be in HTML template or in plain-text. However, if you ask Will Smith, he will tell you: “There’s no reason to have a plan B because it distracts from plan A.” So, why not send just text? 

Plain text Vs. HTML 

I will describe in brief the fundamental differences between the types of emails:   

Reliability – As I wrote, plain-text is much more reliable, unlike HTML, in when you are coding wrong it might send the e-mail to Spam and not just infect the content. 

Marketing – Research has shown that image-based emails have less readers in large percentages, and therefore plain-text will cause not only the arrival of the e-mail, but also its opening. 

UX –  This characteristic represents one of the essential differences between the types, when HTML e-mails can attract the client and produce a significantly better user experience by clickable text links,  images, colors and allows for the break up of content into digestible bits. 

Security – The reason my e-mail arrived in Spam and the danger that exists in HTML e-mails is that they may contain malware. Although it is possible to track the opening of HTML e-mails, e-mails that contain only text reduces the possibility of malware and therefore are safer.  

In my opinion, this discussion is related to your web application goals. Each Email type has its advantages, the goals reflect the significant benefits for each case. For example, if your application is all about security you probably prefer plain-text emails, but if the primary considerations are the UX  and the data you put in your emails, you probably will prefer image-based emails, and will use an HTML template.    

These considerations are hiding among them the pros and cons of the types of e-mails, but as cleaning products advertisements often say: “We prefer two for the price of one.”

What next? 

So after we discussed the importance of plain-text and the differences between the e-mail types, it seems like in every good code the secret rule is “look before you leap.” Because we had five email templates on the application, we prepared five plain-text files. If the amount is greater you should consider sending the plain-text in the same basic pattern such as the HTML.  
 
In conclusion, the concept of this article is the difference between the two code statements listed below, that ensures the arrival of my email to the right place: 

Before:

    //erb file 
    mail(from: @sender_email, to: @recipient_email, subject: @email_subject) do |format| 
      format.html { render email_template.name } 
    end
      
     
After: 

    //erb file 
    mail(from: @sender_email, to: @recipient_email, subject: @email_subject) do |format| 
      format.html { render email_template.name } 
      format.text { render email_template.name } 
    end 

Leave a Reply