External body parts—particularly when cached on local systems—have the advantage that if there are many recipients, less network bandwidth and disk storage may be consumed than when the complete image or audio contents are included in every copy of the message.
However, there are some potential pitfalls to using external body parts:
The first limitation can be overcome when files available via anonymous FTP are also available via a mail server. A mail server is a program that accepts an e-mail message containing a request for something and returns the requested item to the originator of the request via e-mail. Mail servers are especially useful under circumstances where Internet FTP doesn't work, such as over dial-up UUCP links.
To permit access to a file either via anonymous FTP or via a mail server, enclose two external file references inside a #begin alternative directive, as in this example:
#begin alternative #@image/gif [via FTP: surface & radar analysis] \ access-type=anon-ftp; \ name="SA022509.GIF"; \ directory="wx"; \ site="vmd.cso.uiuc.edu"; \ expiration="26 Feb 93 09:00:00 GMT"; \ size=50000 #@image/gif [via mail: surface & radar analysis] \ access-type=mail-server; \ expiration="26 Feb 93 09:00:00 GMT"; \ size=50000; \ server="wx-server@vmd.cso.uiuc.edu"; \ body="send wx:SA022509.GIF" #end
A message containing these directives has this structure, as shown by mhn -list:
msg part type/subtype size description 1 multipart/alternative 697 1 message/external-body 110 image/gif via mail: surface & radar analysis 2 message/external-body 87 image/gif via FTP: surface & radar analysis
Note that the order of alternatives listed is the reverse of that in which the directives occurred in the original draft.
The message, when viewed by the MH command show, results in a session like this one:
Retrieve content 1 by asking mailbox wx-server@vmd.cso.uiuc.edu send wx:SA022509.GIF ? y mhn: request sent
The retrieval message sent by mhn looks like this:
To: wx-server@vmd.cso.uiuc.edu Subject: cache content as /r/mhn-cache/<24586.731500909.2@fester.irvine.com> send wx:SA022509.GIF
When the mail server on the remote host receives this message, it takes action based on the command specified in the body. The body may specify any command that the mail server understands. Note that unlike FTP, there is no standardization among different mail servers. The send command shown in the example above might need to be a get command, or something completely non-intuitive, for a mail server at another site.
(By the way, this particular example, although semantically correct, won't really work, because the site vmd.cso.uiuc.edu doesn't offer files via a mail server—not to mention that the particular file named has long since been deleted from the system. FTP is really the only retrieval method that applies for the weather maps.)
If the answer to the question above had been ``n'' then the usual FTP retrieval question would have been asked:
Retrieve SA022509.GIF (content 2) using anonymous FTP from site vmd.cso.uiuc.edu (50000 octets)?
In general, alternatives permit users to have different ways to look at a message. For those recipients without the necessary resources to view a particular message part, it helps to offer a ``plain'' alternative—even if it's just to say ``sorry, but you're missing something neat...''
RFC 1341 (the MIME specification) recommends that the ``plainest'' alternative be placed first in the list, and that the ``fanciest'' alternative be placed last. The MH show command offers the last alternative first. In our example above, the access-type=mail-server alternative should have gone second, since it doesn't offer gratification as immediate as the access-type=anon-ftp alternative does.
Here is a list of the mhn directive forms most likely to be used for inserting external body parts:
To refer to an external file available via anonymous FTP:
#@type/subtype [description]\
access-type=anon-ftp;\
name="remote-filename";\
directory="remote-directory";\
site="remote-ftp-host"To refer to an external file available via mail server:
#@type/subtype [description]\
access-type=mail-server;\
server="mailbox-address";\
body="retrieval-command";\
To refer to a locally available file:
#@type/subtype [description]\
access-type=local-file;\
name="local-path"
There are other kinds of access-type attributes that may be used for alternative file access methods. Refer to the mhn(1) manual page and to RFC 1341 for information about these other access types.
Also, you don't have to use mhn's built-in FTP retrieval mechanism. Mhn will use an FTP program that you designate in this profile entry: