Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

An SMTP server does not seem to be the natural way to send an email. It just relays the email to recipient. Why can't we do without SMTP servers? I have been puzzled for a few years by this.


migration rejected from Mar 10 '14 at 17:04

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by Jenny D, mdpc, Ward, Rex, Katherine Villyard Mar 10 '14 at 17:04

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must be relevant to professional system administration. Server Fault is dedicated to professional system and network administrators. End user and enthusiast questions are off-topic (contact your system administrator or hire a professional to help you out). Please see the Help Center for more information." – Jenny D, mdpc, Ward, Katherine Villyard
If this question can be reworded to fit the rules in the help center, please edit the question.

Not really a programming question, now, is it? – Oded Oct 16 '10 at 13:04
And to answer the question: How are you going to send email in real time to a computer that is off? – Oded Oct 16 '10 at 13:04
And what should your email client do if the recipient is not only? Or goes online with a different IP address each time? And it is indeed not a programming question – a_horse_with_no_name Oct 16 '10 at 13:05
For the same reason that you don't deliver letters by hand? – skaffman Oct 16 '10 at 13:07

The easiest way to answer this is. Email is very simular to sending a letter in the mail. You have a mailbox, and a number of postoffices. The SMTP servers act like post offices that handle the routing of the messages. When you put a letter in your mailbox the post office picks it up then routes it to the appropriate post office for delivery. Email is the same way. When you send an email to your SMTP server it is routed to the appropriate receiving Server for delivery.

IMO this is the best email analogy. You don't send snail mail to a person, you send it to an address - then it's up to that address to get the mail directly to the person. Many of the same reasons apply. – Kara Marfia Oct 16 '10 at 14:04

You could write an email client which implements SMTP. It's not that hard.

Email clients though use SMTP servers because they offer mechanisms that are only available if the sending host is always online like queueing, retries and handling of NDR (non delivery reports).

Also, there are lots of spam bots out there which use dynamically assigned IP addresses. These addresses are blocked by many anti-spam services. So, it's not a good idea sending directly from a host that was assigned a non-static IP address.


Sending an email fails a lot of the time, not just occasionally, With all grey-listing timeouts, server unreachable, mailbox full's (still) and other problems or safety guards. The standard way of coping with that is to put all emails in a queue and occasionally retry to send the email, until some configured maximum amount of time or tries are passed.

Most people have desktop computers they turn of after use. In this scenario, you could still run a local queue, but imagine you hitting 'send' on an email, and turning of your computer. The email will not be sent, it will only be retried after you start your own computer, or you have to keep it on constantly (effectively making it a server). The same naturally goes for receiving: email directly: you are guessing at an existing window both computers are on & online, which might not happen ever.

I guess sending emails from your email client to the SMTP server would also require many retries? Maybe less retries than sending the email directly to recipient because the routing distance is shorter? – Anonymous Oct 16 '10 at 13:16
No, emails send to the smtpo server are normally synchroneus. THe client waits until the server says he has it and has dialogs. THat works because it is only ONE end point on the other side. – TomTom Oct 16 '10 at 19:37

To understand why we have SMTP servers you may want to review documentation on MUAs (Mail User Agents), MTAs (Mail Transfer Agents), and MDAs (Message Delivery Agents). Once you understand their different roles, you shuld understand why we have SMTP servers.

As you stated, the client can just send the email to the remote server. (That is the way most Spam is sent.) It is the way most clients work when communicating with the local email server. When sending to servers over the Internet most servers require at least some compliance with the RFCs. Many (most) clients are not compliant with the requirements.

One of the key issues it trust. The RFCs specify the use of a static DNS address and reverse DNS lookup to verify the identy of the remote server. Border servers between domains almost always pass this test. (Unfortunately, many marketing list servers fail this test.) Additional trust rules are being added to DNS such as DKIM (Domian Keys Identified Mail) and SPF (Sender Policy Framework).

In some environments legal compliance is an issue, and all mail must pass through servers which maintain the appropriate data. Bypassing these servers bypasses clients. (Some servers such as the above notes marking list servers, may not have compliance issues if used correctly.)

Others have noted mail failure issues. For various reasons mail delivery may fail, or be delayed. (A number of sites use greylisting, which relies on proper retry mechanisms being in place.) Your local border server will handle these issues for you. The border server should also add any missing headers. They will also accept any bounce messages which are not generated immediately (not a issue for spam senders).


The problem is not so much the sending -- you can send an email message by using telnet and establishing a session with the destination mail server by way of MX record. But herein lies the problem: without an always on mail server, what would the MX record resolve to? The recipient's IP address? What about different localparts (joe@, bob@, etc.) on the same domain (, but all on different networks? Or what if you wanted to retrieve your mail when you're at a hotel?

This is why SMTP servers (and servers in general) act as a centralized facility to manage and provide email resources for the clients. Peer-to-peer just doesn't work in this case.