MCS-377 Lab 1: Application Layer (Fall 2008)

Due: September 26, 2008

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 do not need to write a report, given how soon this lab is due. Instead, just send your program to me as an email attachment.


Course web site: http://gustavus.edu/+max/courses/F2008/MCS-377/
Instructor: Max Hailperin <max@gustavus.edu>