It ends with my friends receiving an email like this:

It begins with me connecting to my mail server with telnet or netcat. After connecting, I have an SMTP session with it like this:

susam@nifty:~$ telnet 25
Connected to
Escape character is '^]'. ESMTP Exim 4.69 #1 Mon, 15 Feb 2010 02:10:18
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
EHLO Hello  []
250-SIZE 52428800
250 HELP
AUTH PLAIN ××××××××××××
235 Authentication succeeded
MAIL FROM:<prun××××××>
250 OK
RCPT TO:<prun××××××>
250 Accepted
RCPT TO:<wes×××××××>
250 Accepted
RCPT TO:<sus××××××>
250 Accepted
250 Accepted
RCPT TO:<kart×××××××>
250 Accepted
354 Enter message, ending with "." on a line by itself
Date: Mon, 21 Dec 2012 10:28:00 +0530
From: "Prunthaban Kanthakumar" <prun××××××>
To: "Prunthaban Kanthakumar" <prun××××××>
Cc: "Susam Pal" <sus××××××>, "John Wesley"
 "Indhu Bharathi" <ind××××××××××>, "Karthik"
Subject: Experiment Successful

I was working today (21 Dec, 2012) on an experiment to send messages to
a space-time co-ordinate in the past. If this experiment is successful I
should receive this mail on 15 Feb, 2010, a date in the past.

It is quite funny that we can remember the past but not the future.  So,
when I receive this message on (15 Feb, 2010), I wouldn't remember that
this is the result of a successful revolutionary experiment to be
performed in future. I should have got this message time stamped by a
trusted time stamping authority in order to prove that this message is
indeed from the future but that has its own problems. Why would I, in
the past, believe that such a trusted time stamping authority would
exist in the future?  Moreover, I don't have time to get all this done
as the world is coming to an end today.
250 OK id=1NglGq-0008JC-RK
221 closing connection
Connection closed by foreign host.

An internet message or email consists of two sections: header and body. The header usually consists of fields like 'From', 'To', 'Cc', 'Subject', etc. which are usually displayed to the user. It may have more fields like 'Message-ID', 'Return-Path', 'Content-Type', etc. which are usually not displayed to the user. But many email programs provide some mechanism to view them as well. For instance, in GMail, one can click the little arrow near the 'Reply' button and select the 'Show original' option to view the message with all the message headers. In Microsoft Office Outlook, selecting 'Options' from the 'View' menu in the message window shows all the message headers.

These headers, which are usually not displayed by the email program, are used by the email client and the various programs running on various mail servers to deliver the email to the recipient's inbox. For example, if the delivery of the email fails for some reason, a message describing the failure would be sent to the email address found in the 'Return-Path' field. This is usually the email address of the sender. This field is automatically added by the mail server before sending the email.

The actual message meant to be read by the recipient is contained in the message body. The message body begins after the message headers. The message header and the message body are separated by an empty line. These things can be seen in the above example.

When we compose an email using web based emails like GMail, Hotmail, etc. or email clients such as Microsoft Outlook, Thunderbird, etc. the client automatically enters the sender's email address in the 'From' field before sending the email. Similarly, it automatically uses the email addresses mentioned in the 'To' and 'Cc' fields as recipients of the email. The email client connects to the SMTP server and executes the necessary commands to send the email.

However, when we have a session with the SMTP server, we need to execute those commands ourselves. For example, each recipient is specified with the RCPT TO command. The actual email message that is displayed to the user by the various email clients begins after the DATA command. The message headers such as 'From', 'Date', etc. have to be composed manually.

This gives us more freedom while composing the message. We can specify a future date in the 'Date' field. We can specify a false email address in the 'From' field. There need not be any relation between the recipients specified with the RCPT TO command and the email addresses specified in 'To' and 'Cc' fields. So, it is possible to send an email to one person with the 'To' or 'Cc' field displaying the email address of another person. Similarly, the 'From' field need not contain the email address of the actual sender. SMTP is not concerned with the correctness of these fields.

In the above example, I have composed an email with the email address of a friend in the 'From' as well as 'To' headers. Similarly, I have specified a future date in the 'Date' field. I have specified a false email address in the MAIL FROM command as well because the email address specified there appears in the 'Return-Path' field in the message header.

In the examples above, I have smudged or hidden parts of the authentication response and the email addresses with crosses for privacy reasons. The authentication response contains the credentials I use to log into my email server. For more on how to form an authentication response, see: AUTH CRAM-MD5.

Here are a couple of hyperlinks for further reading.

  1. RFC 5321 : Simpe Mail Transfer Protocol
  2. RFC 5322 : Internet Message Format


జేబి - JB said:

Nice one, Susam.

Though I could not understand the technical details of how it was made, I could understand the prank.

Veetrag said:

Good job Susam! Who all fell for the prank?

Susam Pal said:

Veetrag, some people were scared that someone else has gained access to their email accounts. One friend asked me whether I know the password of her email account. Others guessed that I must have done something and asked me how I did it.

Gaurav Mogre said:

XD.. Got to love the simplicity of SMTP. Though a bit surprised that the gmail smtp server accepted the request. One would think that after gmail's smtp server has AUTH, it would check for false addresses like this.

Ofcourse, the icing on the cake was the email content.

Susam Pal said:


The AUTH command is used by the client to authenticate itself to the SMTP server before he can send emails. In this example, I have authenticated myself to my email server.

Normally, an email server is meant to receive all emails meant for it. Yes, it might want to classify an email as spam after email authentication. Note that the AUTH command is meant for client authentication while email authentication is done to detect spam by considering the information in the message header, message body, sender's IP address, sender's domain name, etc.

A false email address is not a good reason to classify an email as spam. The possibility of specifying false email addresses in the 'From' and 'Return-Path' fields offers the flexibility of using one of multiple email addresses as the 'From' address while sending an email as well as controlling where one would want to receive notifications if the email delivery fails. For example, I have configured my GMail account such that I can send emails with my 'From' email address ending with either '' or ''.

yuvipanda said:

Interesting that GMail doesn't check for wrong timestamps. Perhaps they let it pass - servers with wrong time perhaps do exist. I don't see why it shouldn't be rejected though - maybe they will, eventually?

Neat hack though :)

Susam Pal said:


If you see the SMTP session in this blog post, you'll find that the 'Date' belongs to the data to be transferred by the SMTP server.

The job of an SMTP server is to transfer the data section to the intended recipients irrespective of what the data contains.

Post a comment