SMTP server

SMTP server

Introduction

SMTP protocol is the workhouse of the Internet E-mail otherwise known simply as mail. In today’s world E-mail has become so ubiquitous that you will hardly meet someone that can read and write without an e-mail ID.

And the smart phone adoption in third world countries and backward societies has made the e-mail address the fundamental prerequisite to install several communication tools using the smart phone.

However in 2022, most of the E-mail addresses you find are either managed by one of two big corporations in America, one is Microsoft, another is Google.

This fact is however not something that existed 20 years ago. Before the world of E-mail was consolidated between some major foreign players, things were different.

I even remember a time when a simple SMTP sequence could get your email delivered. But those days are long gone.

Nowadays E-mail servers are massive beasts in software terms and they have to have plugins and filters and APIs and what not.

And the world of standards for E-mail security and threat control, be it SPF or DKIM or DMARC and several such methods like ARC have all muddied the waters quite a bit.

We are discussing SPF and DKIM here. However what with slack and Whatsapp and Matrix and so on, E-mail is always going to be around. Even after 40 years.

It is one of those old things that refuse to die like the radio.Its form may change but it will never go away.

Background

In an effort that started in 1990, approximately a decade after RFC 821 was completed, the protocol was modified with a “service extensions” model that permits the client and server to agree to utilize shared functionality beyond the original SMTP requirements. The SMTP extension mechanism defines a means whereby an extended SMTP client and server may recognize each other, and the server can inform the client as to the service extensions that it supports.

Contemporary SMTP implementations MUST support the basic extension mechanisms. For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO. (However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.) Unless the different characteristics of HELO must be identified for interoperability purposes, this document discusses only EHLO.

SMTP is widely deployed and high-quality implementations have proven to be very robust. However, the Internet community now considers some services to be important that were not anticipated when the protocol was first designed. If support for those services is to be

added, it must be done in a way that permits older implementations to continue working acceptably. The extension framework consists of:

  • The SMTP command EHLO, superseding the earlier HELO,

  • a registry of SMTP service extensions,

  • additional parameters to the SMTP MAIL and RCPT commands, and

  • optional replacements for commands defined in this protocol, such as for DATA in non-ASCII transmissions (RFC 3030 [20]).

SMTP’s strength comes primarily from its simplicity. Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity.

Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs. In many cases, the cost of extending the SMTP service will likely outweigh the benefit.

Internals

The means by which an SMTP client, once it has determined a target domain, determines the identity of an SMTP server to which a copy of a message is to be transferred, and then performs that transfer, is covered by this document. To effect a mail transfer to an SMTP server, an SMTP client establishes a two-way transmission channel to that SMTP server. An SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name to either an intermediate MX or a final destination.

SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible.

An important feature of SMTP is its capability to transport mail across multiple networks, usually referred to as “SMTP mail relaying” . A network consists of the mutually-TCP-accessible hosts on the public Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN environment utilizing a non-TCP transport-level protocol. Using SMTP, a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks.

An SMTP server may be either the ultimate destination or an intermediate “relay” (that is, it may assume the role of an SMTP client after receiving the message) or “gateway” (that is, it may transport the message further using some protocol other than SMTP). SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP replies are sent from the SMTP server to the SMTP client in response to the commands.

In other words, message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems. In either case, once the server has issued a success response at the end of the mail data, a formal hand over of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so (see Sections 6.1, 6.2, and 7.8, below).

Once the transmission channel is established and initial handshaking is completed, the SMTP client normally initiates a mail transaction. Such a transaction consists of a series of commands to specify the originator and destination of the mail and transmission of the message content (including any lines in the header section or other structure) itself. When the same message is sent to multiple recipients, this protocol encourages the transmission of only one copy of the data for all recipients at the same destination (or intermediate relay) host.

Mail server Remarks
Postfix Very popular in Linux world
Qmail Quixotic still widely used
OpenSMTPD OpenBSD based mail server new
Microsoft Exchange OpenBSD based mail server new
Axigen Windows based
Communigate Pro Another Windows SMTP implementation

Postfix

Postfix MTA

Postfix is developed by Vietse Wenema, a Swiss researcher. It is quite popular and came as a fresh air when the world was getting bored and annoyed with the arcane old sendmail. It is widely used on the Internet and almost standard in all Debian Linux systems.

Postfix is a nice SMTP implementation and one of the best as it is well tested and the main.cf and master.cf config files are easy to edit and get going.

Postfix came across as being most mature and usable before the advent of OpenSMTPD.

The utility of Postfix is further enhanced by wide support in mailing lists and also its very excellent documentation.

Exim

Exim Internet Mailer

Exim is not very widely used but it is easy to setup. It supports some anti spam plugins, some commercial ones too.

It is from UK and not as widely used as Postfix.

OpenSMTPD

OpenSMTPD MTA

OpenSMTPD is from the OpenBSD project. It is developed mainly by Gilles Chehade and Eric Farout but many others from OpenBSD project pitch in and send patches.

It uses a filtering and config syntax very reminiscent of the clean OpenBSD world and this is by far the best SMTP implementation due to its power and elegance but it needs lot more field experience before the bugs are all ironed out and considered mature.

The documentation of OpenSMTPD is excellent and as and when commercial support is available the development also happens at a very rapid pace.

The widespread adoption is obvious when you google for a configuration problem.

Microsoft Exchange

Microsoft Exchange server

Microsoft Exchange is a popular mail server from Microsoft and the active directory integration and Microsoft Outlook protocol called MAPI made it popular in olden days. Today it is mostly used by the Offic365 suite.

Supposed to be stable and comes with the usual caveats of any Microsoft product.

Qmail

Qmail by Dan Bernstein

Qmail is written by Dan Julien Bernstien, a professor and is somewhat odd in that the mail server source code is not standard C style and is a bit awkward in the way it implements several things.

It is also popular though the community and code are both arcane. Not sure how many sites run qmail.

Haraka

Haraka transactional SMTP

Haraka is a transactional SMTP written in node.js. It is useful for various things as it has a very powerful plugin system. It is the new kid on the block of MTAs.

If I were to choose a mail server I would stay away from Haraka.

References

Mail servers RFC 5321 Back to homepage



Download 30 day trial of SpamCheetah