Solution to Homework #4 EE407/507 CS 455/555

Section 2.3

1. Best filter is “tcp.flags.syn == 1 & tcp.flags.ack == 0”. This requires some knowledge of TCP syn
flag though. This filter will display 10 packets – SYN and SYN/ACK for each connection plus the 2
retransmissions of the SYN packet for the control channel.

You could also isolate each stream one at a time using its port numbers (e.g. tcp.dstport == 1932)
and record the first packet. This would take 4 filters instead of one however.

Either way is fine.

Port on local Port on server Packet Number

machine machine of 1st packet
192.168.0.1 128.9.176.20 (SYN packet)
Control channel 1931 21 1,2,3
Data channel 1 1932 34178 20
Directory listing for /
Data channel 2 1933 34188 43
Directory listing for in-notes
Data channel 3 1934 34247 345
Retrieve file

2. Here it is probably best to isolate each stream one at a time using its port numbers (e.g. tcp.dstport == 1931) and record the
time of the first and last packet.

Port on local Port on server Packet Number/ Packet number/

machine machine Time 1st packet Time of Last
192.168.0.1 128.9.176.20 (SYN packet) packet
Control channel 1931 21 1,2,3 / 0.0 s 516 / 90.229977 s
Data channel 1 1932 34178 20 / 9.721687 s 34 / 10.269422 s
Directory listing for /
Data channel 2 1933 34188 43 / 28.329842 s 340/ 30.3001824 s
Directory listing for in-notes
Data channel 3 1934 34247 345 / 88.915909 s 517 / 90.276222 s
Retrieve file

Unfiled Notes Page 1

3. Size of file is 147316 bytes. Can tell by response to the RETR command and also based on the Follow TCP Stream for the third
data channel. Entire session is 90.276 long so transfer rate is .147 MB//90.276 sec = .0016 MB./sec

Data connection is 90.120 – 89.091 seconds so transfer rate = 0.147316/(90.120 – 89.091) = 0.147316/1.029 = 0.143164 MB/s

Use "Follow Entire TCP stream"

Or

4. On the control chanel 1891 bytes are sent from server to client and 114 bytes are send from client to server.

5. For all data channels 0 bytes are sent from client to server. In data channel 1, server sends 4319 bytes. In data 2, server sends
256639 bytes and in data 3 the server sends 147316 bytes. Interestingly the directory listing is larger than the RFC.

6. The server reports “230 – You are user #28 of 550 simultaneous users allowed.”

7. Response is “227 Entering Passive Mode (128, 9, 176, 20, 133, 140). The first four numbers indicate the IP address
128.9.176.20.
The last two numbers 133 and 140 represent the port 34188.
133 = 10000101; 130 = 10001100 and 1000010110001100 = 34188

or 10000101 x 28 + 10001100
= 1000010100000000 + 10001100
= 133x256 + 140 = 34,188
Section 2.4

1. Password is “madeyoulook” It is sent in plain text in both pop3 traces.

2. Headers that follow the DATA command in the trace plain.smtp.cap, those are the headers added by the sending machine. All the others
that appear when the message is retrieved were added at the mail server.

Added by sending machine:

Subject: The network racks need to be organized
From: Network Watcher <[email protected]>
To: [email protected]
Content-Type: text/plain
Message-Id: <1074667493.2117.0.camel@localhost>

Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3
Date: 21 Jan 2004 01:44:54 -0500
Content-Transfer-Encoding: 7bit
Added by MAIL SERVER machine:
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 24897 invoked from network); 21 Jan 2004
06:40:40 -0000
Received: from laptop.testingsmtp.org (192.168.32.208)
by mail.testingsmtp.org with SMTP; 21 Jan 2004 06:40:40 -0000

3. Let's look at the email header:

Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 24897 invoked from network); 21 Jan 2004 06:40:40 -0000
Received: from laptop.testingsmtp.org (192.168.32.208)

Unfiled Notes Page 2

 Received: (qmail 24897 invoked from network); 21 Jan 2004 06:40:40 -0000
Received: from laptop.testingsmtp.org (192.168.32.208)
by mail.testingsmtp.org with SMTP; 21 Jan 2004 06:40:40 -0000
Subject: The network racks need to be organized
From: Network Watcher <[email protected]>
To: [email protected]
Content-Type: text/plain
Message-Id: <1074667493.2117.0.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3
Date: 21 Jan 2004 01:44:54 -0500
Content-Transfer-Encoding: 7bit

Date: 21 Jan 2004 01:44:54 -0500 => Date: 21 Jan 2004 06:44:54 -0000

The email travelled backward in time! This must be an artifact of the experiments done on the "server-client" setup.
Proof:Just compare the ethereal trace (plain.smtp.cap) on the sending end with the mail header from pop3.initial.cap file. Clearly there
are some discrepancies in the headers received on the receiving and sending ends. Perhaps the same experiment was done at different times
and the capture files do not represent the same email being POP-ed that receiving end.

Subject: The network racks need to be organized

From: Network Watcher <[email protected]>
To: [email protected]
Content-Type: text/plain
Message-Id: <1074576586.30148.9.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3
Date: 20 Jan 2004 00:29:46 -0500
Content-Transfer-Encoding: 7bit

4. The plain text email header:

Received: from laptop.testingsmtp.org (192.168.32.208)

by mail.testingsmtp.org with SMTP; 21 Jan 2004 06:40:40 –0000

The header for the second email that contains the picture:

Received: from laptop.testingsmtp.org (192.168.32.208)

by mail.testingsmtp.org with SMTP; 21 Jan 2004 06:41:18 –0000

Time difference: 38 seconds.

5. For this question, let's look at the client side of the SMTPconnection in plain_smtp.cap. It will be basically the same but with
a different DATA section. In the Data section, add the headers from the e-mail message that are show in pop3.initial.cap but do
not include the headers that would be added by the mail server itself.

EHLO laptop.testingsmtp.org
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: Messy Rack!
From: Network Watcher <[email protected]>
To: [email protected]
Content-Type: multipart/mixed; boundary="=-
wxX8AgJUfvZdVWKypDE8"
25
Message-Id: <1074667532.2120.2.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.3
Date: 21 Jan 2004 01:45:32 –0500
.
RSET
QUIT

The answer should not include these headers:

Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 24902 invoked from network); 21 Jan 2004 06:41:18
-0000
Received: from laptop.testingsmtp.org (192.168.32.208)
by mail.testingsmtp.org with SMTP; 21 Jan 2004 06:41:18 -0000

6. In general it is accurate, but it is not really trustworthy. For example, the clocks on the sending computer may be inaccurate.
The entire Date header can even be forged. It may be reasonable to trust the time stamp placed on the message by your incoming
mail server if you believe the machine is administered well (clocks set accurately etc.)

Unfiled Notes Page 3

 The entire Date header can even be forged. It may be reasonable to trust the time stamp placed on the message by your incoming
mail server if you believe the machine is administered well (clocks set accurately etc.)

7. No, from the perspective of SMTP there is no distinction between addresses entered on the To line or the CC line. They are bo th
translated in RCPT TO commands in SMTP. The To and CC lines are simply data from the perspective of SMTP. Similarly, Bcc
(Blind Carbon copy) lines also result in a RCPT TO line just like addresses on the To or CC lines. However, with a BCC addres s
there would be no indication in the data section that this recipient received a copy.

8. The email client may use the following rule:

(1) Retrieve the full messages and examine the received headers.
(2) If the received headers indicate, they have been on the server for more than 1 week then issue the DELE command. Otherwise leave
them on the server.

No. this would not risk deleting mail that was never retrieved because it must be retrieved in order to examine the received headers.
The pop server itself could examine its message queues and delete old messages but this would not be an implementation by the e-mail
client.

Unfiled Notes Page 4