Due: March 11, 2002

Objective

You and a partner will write a program that can be used to send a file
as an email attachment (without using any existing mail user agent).
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 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."

Warm-up

Send yourself some mail using telnet to solen'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-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 Netscape Messenger, it probably won't look any
different from your first mail. This is because Netscape, like many
mail user agents, chooses 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 in Netscape, you should see an email with
nothing in it but 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.

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
solen's 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. 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-encoding, such as
base64. For yet more fun, you can send a more specific content-type
(such as image/jpeg) when guessable, and resort to
application/octet-stream only when you can't guess.

Report

Be sure that your report does not assume the reader already knows what
you did. You may assume 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.