Awhile ago I promised to drop a few lines about the migration and a new domain name chosen. To cut the long story short here’s a couple of Command prompt abstracts that are supposed to give a clue to those who know this stuff a little bit.
As I’m working with mail protocols and other related things I’d like to bring in more clarity on this.
EHLO is a sort of servers’ handshake, the first thing they start with in getting to know each other. Yep, EHLO is kinda ‘modern handshake’ – back into days they used to issue HELO and some servers currently in production tend to use the older command despite the fact it provides less features.
Driven by the wish to start a new project almost from the scratch I picked this name EHLO.ME – partially because of the fact it sounds cool (domain zone .ME was just opened for registration!) and describes the core ideas I planned to focus on. The short name had also contributed to the final decision. The attention I paid to the blog was not enough and even now I’m still unsure if I’d ever be able to manage it the way I did it before. Anyway, I set up a task to write a few posts a month at least.
Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\my_computer>telnet smtp.gmail.com 25 |
Have you ever wondered what happens when you press the Send button in your email program? Probably not, I guess — as long as it works. This is exactly the reason why you should wonder, though. In case something doesn’t work it’s good to know what does not work. Usually, 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 2821: Simple Mail Transfer Protocol. Your mail client talks to the SMTP server using this clean and simple procedure to get email from one place to another.
220 mx.google.com ESMTP d4sm5659138fga.5 ehlo 250-mx.google.com at your service, [78.37.209.105] 250-SIZE 35651584 250-8BITMIME 250-STARTTLS 250 ENHANCEDSTATUSCODES starttls 220 2.0.0 Ready to start TLS |
The Flirt
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 it wants to be polite. Actually, it does not attempt to be polite but to use later additions to SMTP that have brought about two flavors of the later HELO command (SMTP command generally consist of four characters).
Two Flavors of HELO
EHLO, being the more recent one makes the server advertise all the additional features (such as delivery status notification or the ability to transport messages that contain other than the safe ASCII characters) it supports.
Not every server will allow this greeting, but it is required to accept a plain HELO which naturally assumes that no additional features are present. Both hello commands do require the client to specify its domain after the **LO, however.
The very basic session with HELO may look like this -
220 mx.google.com ESMTP 4si5701651fge.8 HELO gmail-smtp-in.l.google.com 250 mx.google.com at your service MAIL FROM: <alexanderragel@gmail.com> 250 2.1.0 OK 4si5701651fge.8 RCPT TO: <as@ehlo.me> 250 2.1.5 OK 4si5701651fge.8 DATA 354 Go ahead 4si5701651fge.8 Hello, This is a test. . 250 2.0.0 OK 1227454966 4si5701651fge.8 |
So the message is submitted for delivery. To check if it was delivered I navigate to my mailbox -
As it is clearly displayed the test was successful.
The Sender
The remainder of the protocol really deserves the attribute simple. If you want to send an email, you start with the keywords MAIL FROM:. Following this comes the email address of the sender, as suggested by the from. Don’t forget to put brackets around the address, though (like <sender@example.com>). Continuing our example, we have:
MAIL FROM: <sender@example.com>
250 sender@example.com… Sender ok
The recipient
After the server has accepted the sender’s address, the client can give the address of the recipient. The command for this action, RCPT TO: again is rather suggestive. I want to send mail to myself:
RCPT TO: recipient@example.com
250 support@about.com… Recipient ok (will queue)
That the server will queue means just that: it will save the mail locally and send it together with all the other queued mail in intervals (for example, every 30 minutes). This behavior depends on the configuration and the server may also deliver the mail instantly.
We’re almost done. What’s still missing, though, is the important part: the actual message.
The Message
Now that the “envelope” is finished, the data of the email message just as it is can follow. This “data” consists of the email’s body as well as the header fields.
The command to initiate the state that makes the server accept the message is DATA. Following this are all the header fields of the email message and then the body, both making up for just one big block of text (or data). To tell the server that the input is finished a dot on a line by itself is used (\r\n.\r\n). So I send my message:
DATA
354 Enter mail, end with “.” on a line by itself
Yes, this means that you can state a name completely different from the one the email goes to in the To: field. For example, you can use “Recipient list suppressed” nobody@nowhere.no.
The End
You can now send as many emails as you wish repeating the steps from MAIL FROM: to .. If you’re done with that, you may quit the server with the QUIT command and that’s just what we do:
QUIT
221 Goodbye
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 prompt.
* Type “telnet <mail server> 25″.
* Talk to the server using SMTP.
The detailed guide on telnet session is based on
