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.
firstname.lastname@example.org may be handled by
email@example.com 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
firstname.lastname@example.org 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?