Testing email by hand, again

There have been a number of articles written about testing email by hand. The problem is that I always have to look for them, and very few actually present the full fields required if you are testing against a vicious spam server that is turning away anything that does not comply with most RFCs. So here is a short article on testing out your spam server when it is rejecting your by hand methods.

After setting up a mail server you will probably want to test it by hand to really see what is going on. This is best accomplished with a telnet session to the box in question on port 25. Most M$ (microsoft) distributions have telnet built in, but it is kindof quirky and does not have in line scroolback last time I checked. Most linux distros (all of them I think) have telnet, or bsd-telnet available either built in or in the packages. Check with your favourite distribution.

If you are connecting to a MTA (Mail Transoport Agent) that follows the RFCs, you will not be able to use the M$ method of testing, and most methods of testing that are shown on the internet, as they leave out all of the actual data that is supposed to follow after the data command.

To summarize that gibberish:

If you are connecting to a M$ mailer (or a misconfigurd *NIX mail system), you can really just follow the M$ FAQ on mail testing with telnet. It is shorter than what is presented here, but they do not follow the RFC.

If you are connecting to a strict mail system (postfix + header checks, sendmail + header checks, qmail) you will need to follow this article for testing.


Ok, so hopefully you are on some kind of unix terminal. Great. You will want to
telnet to the box in question (lets call it mailer.com with an IPv4 address of on port 25. Lets assume that you are going to call yourself example.com in this example. We shall also assume that you are sender@example.com and you are mailing to receiver@mailer.com.  Here is how we would do this:


telnet 25

You should see something like:

Connected to mailer

Escape character is ‘^]’.

220 mailer

OK, lets say “hello” and make sure it is responding by typing:


EHLO example.com

Just in case you were wondering, yes you can do HELO, but EHLO is “Extended Helllo” and you will have at your disposal extended commands (AUTH, STARTTLS, HELP, SIZE, etc) available to you during your session.

The server should return something along the lines of:



250-SIZE 10000000





Note that this server does not do TLS/etc.

So, here we would like to send a message to an existing user. If we want to do this the correct way with RFC headers we need to put in the To, From, Subject and Data in the “Data” section, like so:


mail from:<sender@example.com>

rcpt to:<receiver@mailer.com>


each one of those should give you some response, most likely a “250 OK”. If not, it should tell you the error code and reason (e.g. non existent user, does not allow relaying if you try to send to fred@google.com, etc). Now we need to send the data itself:

To: receiver@mailer.com

From: sender@example.com

Subject: This is a test message

Date: Thur, 08 Mar 2014 08:00:01 -0600

This is a test message. This is the text of the test message. Please do not respond to this message. Thank you.



Notes: The date is in military time and the time offset at the end is the offset from Greenwich Mean Time (or if you were in the military, Zulu time, or if you are in the military UTC). The period on the end is not an error, it tells the SMTP server that you are done with the mail message. Most mailers will then end the session, but some will require you to hit control-d.

That is about it. Note that the real difference here is that most people do not send any more information after the “data” command other than the body of the message. A good spam filter will reject such a message that does not have the To, From, Subject and Date fields.

This entry was posted in Servers, Software. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *