My Favourite Email Prank

The Prank

My favourite email prank ends with my friends receiving an email like this:

SMTP Session

The prank begins with a connection to my email server with telnet or netcat and holding an SMTP session like this:

$ telnet mail.susam.in 25
Trying 67.43.13.244...
Connected to susam.in.
Escape character is '^]'.
220-orion.susam.in ESMTP Exim 4.69 #1 Mon, 15 Feb 2010 02:10:18
+0530
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
EHLO
250-orion.susam.in Hello  [122.167.69.67]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
AUTH PLAIN ****
235 Authentication succeeded
MAIL FROM:<p****@gmail.com>
250 OK
RCPT TO:<p****@gmail.com>
250 Accepted
RCPT TO:<w****@gmail.com>
250 Accepted
RCPT TO:<s****@gmail.com>
250 Accepted
RCPT
TO:<i****@gmail.com>
250 Accepted
RCPT TO:<k****@gmail.com>
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
Date: Mon, 21 Dec 2012 10:28:00 +0530
From: "Prunthaban Kanthakumar" <p****@gmail.com>
To: "Prunthaban Kanthakumar" <p****@gmail.com>
Cc: "Susam Pal" <s****@gmail.com>, "John Wesley" <w****@gmail.com>
Cc: "Indhu Bharathi" <i****@gmail.com>, "Karthik" <k****@gmail.com>
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
QUIT
221 orion.susam.in closing connection
Connection closed by foreign host.

Note: In the above examples, sensitive details such as email addresses and the AUTH PLAIN response have been replaced with **** for privacy and security reasons. See my blog post titled AUTH CRAM-MD5 for more details on how to craft an AUTH PLAIN response.

Message Format

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 example, in GMail, we 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, we can go to the View menu and select Options to see all the message headers.

These headers are used by the email client and the various programs running on various email 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 is sent to the email address found in the Return-Path header. This is usually the email address of the sender. For example, the email address specified in the MAIL FROM command appears in the Return-Path header in the email received by the recipient.

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.

When we compose an email using web-based email applications like GMail, Hotmail, etc. or desktop email clients such as Microsoft Outlook, Mozilla Thunderbird, etc., the email application or client automatically enters the sender's email address in the From header field while 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 to all the recipients mentioned in the To and Cc fields.

In the above SMTP session example, since we are manually interacting the email server, we enter all the necessary commands ourselves. For example, each recipient is specified with the RCPT TO command. The actual email message that is displayed to the recipient by their various email clients begins after the DATA command. The message headers such as From, Date, etc. are also composed manually.

Since we enter every SMTP command manually instead of an email application entering it for us, we have more freedom while entering the header values and make this prank possible. For example, we specify a future date as the value of the Date header field. We also specify a false email address as the value of the From header 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. It is possible to send an email to one person with the To or Cc header field containing the email address of another person. Similarly, the From header field need not contain the email address of the actual sender. SMTP is not concerned with the correctness of these fields.

Further Reading

Here are a couple of hyperlinks for further reading:

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

© 2006–2020 Susam Pal