So far, we have sent test emails using the command line.

However, there is no real feedback from these clients as to how our mail server responded - did it respond with the correct details? Note that it is possible to send/receive mail with details that are not 100% correct - leading to issues down the line.

Let's look at telnet to check the server responses to mail requests.

Telnet basics

Telnet can act as the most basic mail client. It can do the same thing as the bigger clients you use on your workstation (such as Thunderbird, Outlook, Mail, etc) - it sends mail.

However, instead of being wrapped in a nice GUI it is a command line tool that can be used to diagnose our postfix installation (and to send mail!).

This is a primer for telnet. I won't be going into great detail of the why's and the how's of every aspect of telnet and the responses we (should) receive.

Setting up mail servers can be a complicated issue and there are some incredible large and detailed tomes and manuals available for those who need to get into the minute detail.

However, following the articles will allow you to understand the basics and know what to look for should you want more detail.

Email details

When you send an email you can use the analogy of physically posting a letter:

You greet the postman. You hand over the envelope which should have the address (recipient) and the sender's address - inside the envelope will be the actual letter, or the data.

Going with that analogy, we need a way of authenticating or confirming all those details.

Greeting

We'll start of the sequence by connecting to the mail server and greeting the postman.

On the Cloud Server enter:

telnet mail.democloud.com 25

This starts the telnet session on port 25.

You should receive a 220 response:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.democloud.com ESMTP Postfix (Ubuntu)

Good. (Note: If you cannot telnet to port 25, try modifying your master.cf postfix file to allow port 587 communication, as well as opening 587 in iptables. Some internet providers block users from accessing port 25.)

Next we can greet the postman:

HELO test.democloud.com

Note the test subdomain doesn't exist - it is simply a way of greeting the mail server.

The mail server should respond with a confirmation of who it is:

250 mail.democloud.com

Envelope

Now we have greeted the postman and got the correct responses we can start to fill out the envelope for our letter.

We start by letting the server know who the sender is:

MAIL FROM:<jpierce@democloud.com>

If the mail server accepts the sender address, you will get another '250' output:

250 2.1.0 Ok

Good.

Now we can sort out to whom we are sending the letter:

RCPT TO:<demo@democloud.com>

We are hoping for a 250 response:

250 2.1.5 Ok

Again, good news.

You can add more recipients - unlike a physical letter, the same email can be sent to multiple recipients.

Data

Now we come to the 'meat' of the letter: the data.

To start the main body of the message:

DATA

The response is fairly sparse:

354 End data with <CR><LF>.<CR><LF>

Now you need to enter the subject and the body.

Note you need to physically type the word 'Subject:'

Subject: test message

Press enter/return and then you can type the body of the message:

This is the body of the message!

As when we used the 'mail' command in a previous article, we need to enter a single period (.) to indicate we have finished the body of the message.

As before, we are rather hoping for a 250 response:

.
250 2.0.0 Ok: queued as 9620FF0087

Nice.

Quit

Well, we're done with telnet for the moment so we can quit:

QUIT

This will dump you back at the bash prompt:

221 2.0.0 Bye
Connection closed by foreign host.
You have new mail in /var/mail/demo

Ooh!

I have new mail in /var/mail/demo.

Check test message

Let's use the 'tail' command to read the end of the mail file:

tail -n 15 /var/mail/demo

That particular command parses the last 15 lines of the /var/mail/demo file (which is where our mail is kept).

If you don't see all of the mail as shown below, you can adjust the number of lines to, say, 20.

In my case, the output was as follows:

From paul@democloud.com  Wed Aug  6 10:33:20 2008
Return-Path: <paul@democloud.com>
X-Original-To: demo@democloud.com
Delivered-To: demo@democloud.com
Received: from test.democloud.com (localhost [127.0.0.1])
        by mail.democloud.com (Postfix) with SMTP id 9620FF0087
        for <demo@democloud.com>; Wed,  6 Aug 2008 10:28:43 +0000 (UTC)
Subject: test message
Message-Id: <20080806103059.9620FF0087@mail.democloud.com>
Date: Wed,  6 Aug 2008 10:28:43 +0000 (UTC)
From: paul@democloud.com
To: undisclosed-recipients:;
 
This is the body of the message!

Well that's pretty cool.

Summary

It goes without saying (even though I am going to say it) that there is far, far more to it than the basics shown above.

It is simply impossible to go into all the details of what is possible with email headers and messages, encodings and the details of telnet.

However, this introduction should show how mail works and what steps are taken when mail is sent and received.

Perhaps you can begin to see why some legitimate mail may be seen as spam email - if any of the steps above failed or gave the wrong response then warning flags are raised.

A wrong hostname will mean mail sent from the Cloud Server does not identify itself properly. Improperly formatted addresses or message bodies can raise eyebrows and flags.

Now that we've tested that mail is working properly, let's make sure that we're not an open relay.

Previous Article
Next Article
Table of Contents