Learn to speak SMTP and POP3.
Contrary to popular belief, you don't have to go to the trouble of configuring an email client just because you want to check your email or send off a quick email message.
Normally when you use the telnet application, you use a Telnet client to attach to a Telnet server listening on port 23. Once you're connected, you can log in and do anything on that device as if you were physically there, typing at its keyboard.
The Telnet client has even more powerful capabilities than this. If you specify a port number with the telnet command, you will attach directly to the TCP server listening on that port. If you know which commands that server can respond to, and if the service understands plain text commands, you can talk directly to that server. This essentially means that you no longer require a client application specific to that server.
5.8.1 Sending Email with telnet
Whenever you send an email, you connect to an SMTP server listening on port 25. Let's use telnet to see what really happens in the background and which commands the client and the SMTP server exchange. Note that in the following examples, the names and addresses have been changed to protect the innocent.
% telnet smtp.mycompany.com 25 Trying 220.127.116.11... Connected to smtp.mycompany.com. Escape character is '^]'. 220 smtp.mycompany.com ESMTP server (InterMail version x) ready Sun, 2 Nov 2003 09:54:18 -0500 mail from:<email@example.com> 250 Sender <firstname.lastname@example.org> Ok rcpt to:<email@example.com> 250 Recipient <firstname.lastname@example.org> Ok data 354 Ok Send data ending with <CRLF>.<CRLF> This is a test message. Not very interesting, really. . 250 Message received: 20031102145448.QON15340.email@example.com quit
Let's pick apart that output. Note the 25 at the end of the telnet command. If you forget the port number, your prompt will probably hang. This is because instead of trying to connect to the SMTP service, you're trying to receive a login prompt from your ISP's mail server. If you actually do receive a login prompt, it is time to switch ISPs, as security is obviously not one of their concerns!
Next, the output indicates when you successfully connect to the SMTP service. Notice that there are very few secrets in TCP/IP-land. The SMTP server readily shows its banner, which indicates the type of SMTP application running on that server, its version and patch level, as well as the time and date you connected. We'll talk more about banners later.
After connecting to the server, I issued two SMTP commands: MAIL FROM and RCPT TO. Some SMTP servers are pickier than others and won't recognize these commands unless you say hello first. If your SMTP server complains about your lack of politeness, try typing HELO or EHLO. I know that this SMTP server accepted my commands because the responses start with 2xx and end with Ok. Responses that begin with 5xx indicate errors you either made a typo or used the wrong command. Most SMTP servers try to be helpful by giving the syntax of the command they expect to receive.
After providing the sender and recipient email addresses, I issued the DATA command and pressed Enter. The SMTP server then asked me to type my message. To indicate I was finished, I put a dot (.) on a line by itself. The server responded with a message number, and I ended the session by typing QUIT.
Some interesting things happen if I play a bit with the SMTP commands. For example, the MAIL FROM command does not verify that the given email address is valid. This has some interesting ramifications, as I could pretend to be firstname.lastname@example.org, email@example.com, or any other address my imagination could dream up. Remember this quirk when you read your email. There is no guarantee that any given email was actually sent from the email address it purports to be from.
Additionally, I'll have mixed results if I start playing with the RCPT TO address. I might start receiving error messages like this:
550 relaying mail to nowhere.com is not allowed
This is actually a good error message to receive, as SMTP relaying is considered to be a bad thing. In this particular instance, I've asked the SMTP server of mycompany.com to send my message to a recipient at nowhere.com. The server rightfully complained, as it should only be responsible for the recipients at mycompany.com. If I want to send a message to a recipient at nowhere.com, I should instead attach to nowhere.com's SMTP server.
5.8.2 Testing for Relaying
As mentioned before, relaying is considered harmful because it allows spammers to use another company's SMTP server to relay spam. If you're responsible for an SMTP server, be sure to read your SMTP documentation to see whether relaying is off by default and how to turn it off if it isn't. You can then initiate a quick telnet session to port 25 to ensure your SMTP server does indeed refuse to relay email. For example, I don't want the mycompany.com SMTP server to respond like this:
rcpt to:<firstname.lastname@example.org> 250 Recipient <email@example.com> Ok
If it does, it is willing to relay to the unix.ca SMTP server.
What else should you look for when you telnet to your own SMTP server? Take a careful look at your banner. Does it freely advertise that you're one or two patch levels behind? Do you really want to tell anyone who knows enough to ask which particular SMTP product you're using? If they know enough to use telnet, they probably know how to use Google to look for known vulnerabilities in that product. It's always good to know exactly what the world sees. You can then determine if you prefer to change the banner to something a little less chatty. Read the documentation for your particular product to see how to do so.
5.8.3 Testing SMTP Server Availability
Finally, telnet is an invaluable troubleshooting tool. For example, if users complain that they can no longer access the mail server, your first step is to check connectivity by pinging the mail server. If the mail server responds, you can telnet to its SMTP port to verify that the SMTP service is still running.
5.8.4 Reading Email with telnet
Let's move on to POP3, so we can pick up our email messages. Here I'll pick up that message I sent previously:
% telnet pop.mycompany.com 110 Trying 18.104.22.168... Connected to pop.mycompany.com. Escape character is '^]'. +OK InterMail POP3 server ready. user you +OK please send PASS command pass thecleartextpassword +OK you is welcome here list +OK 1 messages 1 544 . retr 1 +OK 544 octets Return-Path: <firstname.lastname@example.org> Received: from [22.214.171.124] by smtp.mycompany.com (InterMail version x) with SMTP id: <20031102145448.QON15340.email@example.com> for <firstname.lastname@example.org>; Sun, 2 Nov 2003 09:54:18 -0500 Message-Id: <20031102145448.QON15340.email@example.com> Date: Sun, 2 Nov 2003 09:57:34 -0500 From: <firstname.lastname@example.org> This is a test message. Not very interesting, really. . quit +OK you InterMail POP3 server signing off. Connection closed by foreign host.
Notice that you use port 110 to connect to a POP3 server. Also, the commands used by POP3 are very different than those understood by SMTP. In this session, I used the USER command to indicate my username and the PASS command for my password. Unlike SMTP, you do have to authenticate to use POP3.
Once I successfully authenticated, I used the LIST command to see how many email messages were waiting for me. I had one message, which was 544 bytes long. I then used the RETR command to display that message, including the headers as well as its contents, and typed the QUIT command to end the POP3 session.
There are several things you should be aware of regarding the POP3 protocol. The first is that every single packet including those containing your username, password, and the contents of each email message are sent in clear text. That means that a packet sniffer running on your network would have full access to that information.
Second, anyone who knows your email password could conceivably connect to your POP3 server and read your email. Worse, they could use the DELE command to delete your email before you had a chance to receive it.
5.8.5 Security Considerations
That doesn't sound very good, does it? There are several things you can do as an end-user to protect your email. One is to use a third-party email encryption product, which will protect the contents of your email (but not your username and password) from packet sniffers. The other is to use different passwords for different functions. For example, don't use the same password to pick up email, do online banking, log into your office network, etc. And always pick a password that your friends and family won't be able to guess.
As an email administrator, you can also create a safer environment for your users. Create a different username for each user, something other than the names contained within their email addresses. For example: email@example.com usually indicates a username of moi. That means I could connect to the POP3 server at mycompany.com and try to guess the password for the user moi. However, if the administrator had given that user a username such as l2tn4g and instructed that user never to give out his username, it would be much more difficult for someone else to access his email.
5.8.6 See Also