EFF's Survelliance Self-Defense (SSD) project has an illustration of how email over SMTP goes through intermediate mail exchange servers:

intermediary mail servers

AFAIK each intermediate servers is expected to add its own Received: header to the email so at least the transit is traceable. I'm not sure how easy is to circumvent this. There seems to be plenty related terminology for Message transfer agents, like mail relay, mail server, mail exchanger, and MX host or MTA.

Observing the lack of somehow wide-spread adoption of email privacy measures like GNU Privacy Guard (GPG) with Pretty Good Privacy (PGP) despite available tutorials, it seems safe to assume that there is a significant amount of users who would be concerned about this but are simply unaware of the issue, unsuspecting any "proxy" servers.

A layman's idea of the process of sending emails could compared to that of with the web:

  • the domain name for the recipient's mail server's host should be resolved to an IP via DNS
  • a secure connection with TLS (or SSL) should be set up to that IP
  • the email should be sent to a server on the host on that IP

Now one may be aware that e-mail aliases or identities could be set up, for example where there are multiple domains with email addresses but only a single handler host. [email protected] may be handled by [email protected] if eg. an organization has multiple domains.

But this doesn't seem to justify transmission of the email body to every single intermediate node. It is not hard to imagine, figuratively speaking, a system where such aliases are resolved before sending the actual body. The mail server on bar.org could tell [email protected] that the actual host is on foo.org, before any email body is sent.

edit From a security standpoint this current system seems to be unfortunate. Albeit alternatives like BitMessage seems to exist, this question aims to find out what stands in the way securing the current email infrastructure, and to understand what lead to this system in the first place.

What is the technical or historical rationale that justifies the continuing existence of intermediary mail servers?

  • Is there a security question here? It seems like an email infrastructure question.
    – schroeder
    Jul 3, 2014 at 17:23
  • @schroeder good point but the intended security aspect is whether a system could be set up so no unexpected intermediary servers take place in the exchange. for that one should know the rationale. Aiming for a better question I added that.
    – n611x007
    Jul 3, 2014 at 17:24

3 Answers 3


SMTP is a very, very old protocol, dating from the early days of the Internet when connections weren't reliable and security wasn't a major issue. Many of the issues with SMTP (open relays, unauthenticated senders, etc.) are the result of trying to provide reliable delivery on an unreliable network where everyone knew everyone else (or at least everyone else's sysadmin).

The original rationale for intermediate servers was that if your server couldn't contact the destination server, it might be able to contact a third server who could relay the email to the destination.


Intermediate email servers aren't generally required, but they allow for scale out, and allow for specialized email services to handle particular requirements such as:

  • AV/AS scanning
  • Content Filtering for information controls
  • 3rd party auditing via BCCing (for SEC registered reps, schools, etc)
  • Specialized routing (P1/P2 routing, sender routing)

Intermediate email servers are often required for the following scenarios

  • Mailing lists
  • Email forwarding / rewriting of the headers (P1/P2)
  • School alumni forwarding of email

In practice, most companies (J&J, Schwab, BoA) are setting up a static TLS between MTAs and have a dedicated route for those destination domains. This is ultimately the best middle ground between compatibility and security.

From the MTA that receives the static TLS entry, the company is then free to use as many intermediate MTAs to handle internal delivery needs.


Many organizations have a central email server that's the only one to be exposed to the outside and which forwards emails to some satellite node (one per geographical site or per organizational department) which isn't visible to the outside network.

Furthermore email can be forwarded from server to server. Since forwarding can be based on the content of the mail, you can't replace that by having the forwarding server say “contact this other guy instead” before it's seen the content of the email.

In any case, TLS on SMTP and GPG solve different problems. GPG provides end-to-end confidentiality and authenticity. TLS on SMTP doesn't protect against a malicious email server which surreptitiously logs emails in transit. In fact, TLS on SMTP between servers is of limited practical usefulness as an adversary who can eavesdrop at that point is often in a position to control one of the email servers on the path. GPG only requires the minimum: that the source and target machines aren't compromised.

What GPG doesn't provide but TLS on SMTP provides to some extent is privacy. If an adversary can see network traffic locally, but who doesn't control any of the SMTP servers on the email's path and doesn't see network traffic at both ends (which would allow correlations), then the adversary can't know who's emailing who.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .