Sinatra Blog: Working with Emails.

Posted by Anthony Tilelli on April 24, 2020

The email has become one of the de facto ways a user is identified on a system (at least in the USA). This is due to their uniqueness, and popularity, and end-user simplicity. If a user needs to verify their email ownership or reset their password, simply send an email with a link for the user to for them to click on. However, while email is simple for the end-user, there are important considerations for application authors. Email is not secure and should not contain sensitive information. Anti-Spam and anti-virus efforts have made working with email more complex. Comprise of an email account can lead to compromise of your application’s account.

Classic email communication is similar to sending a postcard, any servers or machines that the email transits through can read its contents. There is some effort to secure email in transit or secure message body, however, adoption is limited for both. Adding message-level encryption confused most users and, at the moment, there is little value in adding a message encryption option to your application. You should not send sensitive information by email, such as personally identifiable information. Different applications will be affected by this, to some extent depending on the industry, it’s used in. Special care should be taken when dealing with financial or healthcare-related data as information leaks can lead to fines or worse for you or your organization.

Email technology was designed as a very simple and robust protocol it was once one of the preferred ways to alert and communicate. Many classic Unix tools, such as Cron, would email the root user when needed. However, due to email spam/spoofing, email usage has become significantly more restricted, and no longer could any application generate an email. Several anti-spam solutions were devised to filter spam and prevent spoofing, which is again at various levels of adoption. There are several hurdles and gatekeepers now preventing emails from being delivered. The first major hurdle is that you must be authorized to send an email for the desired domain via dns records. Even if you are authorized you will still not be able to send the email from many locations, most ISPs and major cloud providers block the port email is sent on and third party anti-spam companies will have an ever-rotating ip black list, which you will need to appeal. It is not unheard of for a service such as Gmail to occasionally get a few IP blacklisted. The final hurdle is the heuristic anti-spam solution is used by those receiving email. A popular solution is a tool called Spam Assasin, if you are getting several dropped/bounced emails, it can be helpful to evaluate sample email again Spam Assasin. Most bounces email will contain an error message.

As mentioned prior, email is like sending a postcard, and it acts as a central mechanism to identify users. Thus, if an adversary can intercept a user’s emails or take over the account a user can impersonate a user for other accounts. On many applications, users only need an email to sign up and they can reset their account passwords with an email reset link. This may be enough security for many applications, however, for more sensitive domains this can be inadequate. Sadly, there is no real consensus on how to best reset passwords more securely. However, making resetting passwords more secure, can lead to user frustration, so it is a balancing act. In all cases, email reset links and account registration links should expire within a reasonable time frame.

The current best solution to sending email from Sinatra (unless major or very large company) is to use an email service provider who will handle most of the obstacles for you. You will still need to authenticate the provider to send emails on your behalf. Flatiron currently makes use of SendGrid, however, many providers do exist. Most providers will allow you to send emails via an API and have prebuilt solutions for many email use cases. At a small scale/testing, it can be free to use, however at larger and production sale there is usually a cost per set amount of email. To control cost you can check it a domain supports email by checking the for the presence of an MX record or using a similar service/ strategy.