MCS-377 Lab 1: Application Layer (Fall 2006)
Due: October 6, 2006
Objective
You (and a partner, if you wish) will write a program that can be used to send a file
as an email attachment without using any existing mail client program.
That is, your program will directly connect to an SMTP server and,
using the correct SMTP commands, transmit an email message that uses
the right MIME conventions to contain the file as an attachment. You
are welcome to write your program in any language. Most of you will
find Java easiest, because our textbook has information about writing
TCP clients in Java. Other likely contenders would be Python, C++, or Scheme.
If you write your program in Java, you might use it like
java Send max@gustavus.edu somefile
to send me, as an email attachment, the file "somefile." You can
assume that the program will be run at Gustavus, so that it can
connect to smtp.gustavus.edu and use a From address that
ends in @gustavus.edu.
Warm-up
Send yourself some mail using telnet to smtp.gac.edu's port 25. That is,
type the relevant SMTP protocol commands by hand, and format your
email in accordance with RFC 822, with From, To, and Date headers.
(Exception: RFC 822 calls for dates with two-digit years. This was
updated by RFC 1123 to say that you should use a four-digit year
instead. Follow that more recent guidance.) You can include a
Subject header as well if you feel like it. Check that the email
works. Include a line in the body of your email that starts with two
periods, to see that the first one is getting stripped off.
Now send yourself a second email, again by telnet to port 25, but this
time add the MIME-version header, specified in RFC 2045. You could
also add the headers for Content-Type and Content-Transfer-Encoding, but the
default values of text/plain and 7bit, respectively, are probably
appropriate, so these headers aren't really needed. If you view this
new mail using most mail client programs, it probably won't look any
different from your first mail. This is because most
mail client programs choose to display text/plain mail as "inline"
content rather than as an attachment, by default. (Some fancier
content types are displayed as attachments by default.)
To overcome this, send yourself a third mail, just like the second,
except that you add the Content-Disposition header field, which was
added to MIME in RFC 2183. You should specify that the
content-disposition is attachment, and give a filename parameter.
Now when you read this email, depending on the program you use, you
may still see the text displayed inline, but you should also see (or
perhaps only see) an attachment, which when you open it is the plain
text file you sent.
Basic programming
Now write a program that sends a specified file to a specified email
address, by doing what you did by hand. You should follow the lead of
your third manual email, so that the file is an attachment. You can
use the filename parameter of the Content-Disposition header to pass
along the file's original filename. Remember to double periods that
appear at the beginning of lines. Assume that the file is 7-bit plain
text. You may find useful an example
program that illustrates how to read from a file in Java.
Initially you can just assume that all responses that come back from
the SMTP server indicate that all is well, and plunge blindly ahead
with the next step of the protocol. Once the program seems to be
basically working, you can make it actually check the responses, and
if there is a problem reported (like an illegal destination address),
report it back to the user and bail out. You may not be able to
thoroughly test this feature, since you may not be able to provoke
the SMTP server to produce all possible errors. Test what you
reasonably can and cross your fingers on the rest.
It will make your program easier to debug if you print out on the
terminal each line that is being sent to the server, prefixed by "C:"
and also print out each line received from the server, prefixed by
"S:". This feature should be controlled by some boolean that can be
turned on or off, so that when not debugging the program, you can
squelch it.
More advanced programming
The program described above should work fine for sending plain text
files, but not things like JPEG images. (Just this weekend, a
department colleague asked me if I knew of a program he could use to
send image files from the command line, rather than having to drag and
drop them, as he had a lot to mail.) If and when you have the basics
working, if you are looking for more challenge, you can fix this
shortcoming. You could send all files with the content type
application/octet-stream, which indicates that the real type is
unknown, and so the attachment should just be saved out as a file
without any attempt at interpretation. However, since the files may
not be 7-bit, you will need to perform a content-transfer-encoding,
such as base64. For yet more fun, you can send a more specific
content-type (such as image/jpeg) when guessable from the filename or
other information, and resort to application/octet-stream only when
you can't guess.
Report
You may assume your reader has reasonable background knowledge of
networking, and should refer to external sources of information (such
as RFCs) where appropriate. Be sure to not only present your code,
but also some indication of how you tested it. Including some of the
debugging output lines (those with "C:" and "S:") may prove helpful in
explaining what your program does. You need not report on the
warmups.
Course web site: http://www.gac.edu/~max/courses/F2006/MCS-377/
Instructor: Max Hailperin <max@gac.edu>