SMTP and Implicit TLS from a C# .NET application
By: Adrian Nasui
Tags: Internet, Smtp, Coding, Aspnetcore, Email

Recently I had to do the most basic task of sending email messages from a very simple Net Core web application inside an Azure App Service. I had done this countless times in the past, but this time it was not as simple. The calls from my app to the SMTP server were failing due to a timeout error. Finding a solution required some reading and a trial-and-error approach, and in this process I discovered my lack of solid understanding of the SMTP protocol, its history, and the variety in standards being applied by SMTP servers worldwide.

This article serves to help out developers that run into the same problem, and is the first in a series that will document my solution in greater detail.

SMTP (Simple Mail Transfer Protocol) — a very simplified history

The SMTP protocol defines the way an email client sends messages to an email server.

The Simple Mail Transfer Protocol (SMTP) is a communication protocol for electronic mail transmission. As an Internet standard, SMTP was first defined in 1982 by RFC 821, and updated in 2008 by RFC 5321 to Extended SMTP additions, which is the protocol variety in widespread use today.[…] User-level email clients typically use SMTP only for sending messages to a mail server for relaying, typically submit outgoing email to the mail server on port 587 or 465 as per RFC 8314.

The SMTP protocol is an internet standard and was created by the Internet Engineering Task Force (see IETF wikipedia). Its specification is vast, defined incrementally inside more than one RFC documents published by IETF.

How Email infrastructure works

Your message leaves your email client and is sent to the SMTP server, called Mail Submission Agent (or Message Submission Agent, see rfc6409). (Side-note, this is the step I was having problems with, namely connecting my SMTP client to the SMTP server )

After this, the message is transported via one or more Mail Transfer Agents until it reaches its destination server. From there it is read by the Mail User Agent (a POP or IMAP client) and displayed to the recipient.

Email journey from sender to receiver is complicated

Implicit TLS

There are three methods that can be used by an SMTP client to submit an email to an SMTP server.

Cleartext — this method sends the data in clear text, unencrypted. Because it is insecure, this method is obsolete and should not be used.

StartTLS (or explicit TLS)— this method of communication starts the connection as cleartext, but a secure channel is negotiated and the actual mail submission is done via this secure channel. Usually the communication is done on port 587.

Implicit TLS — this will directly assume that the SMTP server is secured and will implicitly start the communication via SSL. As of 2018 this is the recommended method for submitting messages to a SMTP server (see RFC8314). Communication is usually done on port 465. While Implicit TLS is the method recommended by IETF , not all email servers implement it yet, so in the real world you will encounter all three variants.

In brief, this memo now recommends that[…] Connections to Mail Submission Servers and Mail Access Servers be made using “Implicit TLS” (as defined below), in preference to connecting to the “cleartext” port and negotiating TLS using the STARTTLS command or a similar command. [RFC 8314 https://tools.ietf.org/html/rfc8314]

ASP NET Core SMTPClient

Now we are getting to the core of the problem: for some reason, the built-in ASP NET Core Microsoft.Net.Mail class does not implement Implicit TLS. If you are in the unlucky situation of having to send emails to a server that only supports Implicit TLS (port 465 can usually be a hint that we are in this scenario), the standard SMTPClient delivered with any version of NET Framework (incl. NET Core) will be of no help. Timeout errors with very little info will be the only result you get.

Solution — a 3rd party library (Aegit Implicit Mail)

Digging around the symptoms I was seeing, I found this email sending component for NET Framework called Aegis Implicit Mail. A very obscure open source component on Source forge, it promised to solve this exact scenario of implicit TLS:

Sadly, Microsoft.Net.Mail Ssl Mails does not support Implicit Ssl Mail and it is still used by many servers, including port 465 of Gmail here AIM comes to make a readable and fast alternative to send your smtp mails.

A quick trial proved to be successful. My hours of frustrating attempts were bringing me closer to a working solution.

. //Generate Message . var mailMessage = new MimeMailMessage(); . mailMessage.From = new MimeMailAddress(mailAddress); . mailMessage.To.Add(userTo); . mailMessage.Subject = subject; . mailMessage.Body = message; . //Create Smtp Client . var mailer = new MimeMailer(host, 465); . mailer.User = userName; . mailer.Password = password; . mailer.SslType = SslMode.Ssl; . mailer.AuthenticationMode = AuthenticationType.Base64; . //Set a delegate function for call back . mailer.SendCompleted += compEvent; . mailer.SendMailAsync(mailMessage);

Finally my emails were being sent. The only problem now was the fact that Aegis Implicit Mail was an old component, it was build for NET Framework, and due to some very small limitations, I was unable to use it from my NET Core app (one reason I remember was the library was using a class named ServerException that was not carried over from the old NET to the new and supple NET Core).

In Part two of this post I will tell you the story of how I forked the open source repository, ported the library to NET Core and how I added async/await semantics.

Stay tuned!

Later edit Feb 2020: Seems that the original creators of the library did a port to .NET Standard and using that would ensure usage from NET Core apps. https://github.com/nilnull/AIM