Have you ever wondered what happens when you hit the Send button in your email program? Probably not, I guess, as long as it works. This is exactly why you should be asking. In case something doesn’t work, it’s good to know what doesn’t work. Normally, that’s half the solution.
When you send email, SMTP comes into play. SMTP is short for Simple Mail Transfer Protocol as defined in RFC 5321: Simple Mail Transfer Protocol. Your mail client communicates with the SMTP server using this clean and simple procedure to send email from one place to another.
Your email program becomes an SMTP client, connects to port 25 of your mail server (usually the SMTP port) and – says EHLO . Computers, in the end, are only human and what counts is that they want to be educated. Not really trying to be polite, but using later additions to SMTP that have produced two flavors of the latest HELO command (the SMTP command usually consists of four characters).
Two flavors of HELO
EHLO, being the latest, makes the server advertise any additional features (such as delivery status notification or the ability to transport messages containing non-safe ASCII characters) that it supports.
Not all servers allow this greeting, but it is necessary to accept a simple HELO which naturally assumes no additional features. Both hello commands require the client to specify its domain after **LO, however. In practice, this looks something like this:
220 mail.domain.net ESMTP server
501 HELO requires domain address
>. HELO localhost
250 mail.domain.net Hello localhost[127.0.0.0.1], nice to meet you
(My input is in italics , server output is black; lines starting with 5 indicate an error.)
The rest of the protocol really deserves the simple attribute. If you want to send an email, start with the keywords MAIL FROM: . After this comes the sender’s email address, as suggested by the sender. However, don’t forget to put square brackets around the address (such as ). Continuing with our example, we have done:
250 [email protected]… Correct sender
After the server has accepted the sender’s address, the client can give the recipient’s address. The command for this action, RCPT TO: again is quite suggestive. I want to send mail to myself:
Queuing the server means just that: it will save mail locally and send it along with other queued mail at intervals (for example, every 30 minutes). This behavior depends on the configuration and the server can also deliver the mail instantly.
We’re almost done. What is still missing, however, is the important part: the actual message.
Now that the “envelope” is finished, the data of the email message as it is can continue. This “data” consists of the body of the email as well as the header fields.
The command to start the state that causes the server to accept the message is DATA . Below are all the email header fields and the email body, which is just one big block of text (or data). To tell the server that the input is finished, use a dot on a line by itself (rr). So I send my message:
354 Enter email, end with “. Message-ID:
Date: Sun, 17 Aug 1997 18:48:15 +0200
From: Heinz Tschabitscher To: Heinz Tschabitscher ([email protected]) Subject: For the Sumarize-Proust Contest
Off to Swan’s World!
250 SAA19153 Message accepted for delivery
Yes, this means that you can enter a completely different name than what appears in the To: field. For example, you can use “Recipient List Suppressed” .
You can now send as many emails as you like by repeating the steps from MAIL FROM: to . . If you’re done with that, you can quit the server with the QUIT command and that’s what we do:
How can I do this?
The non-trivial solution is to telnet to your outgoing mail server (you can find its address in your email client’s account settings) on port 25.
- Open a command line.
- Type “telnet 25”.
- Talk to the server using SMTP.
The easiest way is to use this Java applet, which tries to mimic the SMTP protocol and guides you through the dialog.