On 11 November 1998, Bart Schaefer <schaefer(_at_)zanshin(_dot_)com> wrote:
On Wed, 11 Nov 1998, Liviu Daia wrote:
On 11 November 1998, Doug Monroe <monroe(_at_)lucent(_dot_)com> wrote:
[...]
echo "";\
echo "This is a multi-part message in MIME format.";\
Nah, that's a Pine-ism
Actually, it's something recommended by several revisions of the MIME
standards. The stuff before the first boundary string is a "preamble"
intended for display by old mailers that don't understand MIME. Any
decent MIME mailer will hide it.
Actually, this practice seems to be discouraged by RFC 2046:
: There appears to be room for additional information prior to the
: first boundary delimiter line and following the final boundary
: delimiter line. These areas should generally be left blank, and
: implementations must ignore anything that appears before the first
: boundary delimiter line or after the last one.
However, the named RFC admits this is current practice:
: NOTE: These "preamble" and "epilogue" areas are generally not used
: because of the lack of proper typing of these parts and the lack of
: clear semantics for handling these areas at gateways, particularly
: X.400 gateways. However, rather than leaving the preamble area
: blank, many MIME implementations have found this to be a convenient
: place to insert an explanatory note for recipients who read the
: message with pre-MIME software, since such notes will be ignored by
: MIME-compliant software.
Oh, and if your mailer doesn't understand MIME, that note is just
more garbage before the real message. :-)
Content-Transfer-Encoding: 7bit"; \
echo "";\
echo "heres some plain text message";\
echo "followed by the 'attached' file (inserted by 'cat filename')";\
Another newline here.
Actually not required. If no newline is present, MIME says to
interpret the preceding part as if it did not end with a newline.
That may or may not be what was meant (probably not).
True.
echo "--------------C1BC5999FB7A73F0B7EF99B8";\
echo "Content-Type: application/msword";\
echo " name=\"foo.doc\"";\
Don't write the name twice, forget about "name=..." and just use
"Content-Disposition:".
He really is better off doing both -- some mailers that don't
know about the content-disposition header will recognize the name
parameter.
No. The "name=..." parameter to "Content-Type:" is non-standard,
despite the fact that programs like Pine are still happily using it.
The "filename=..." parameter to "Content-Disposition:" is documented in
RFC 2183. Any reasonably recent MIME-aware mailer will accept filenames
in both forms when reading messages, but IMO the "name=..." form should
be discouraged when sending. If an old mailer doesn't understand the
new "Content-Disposition:" header, this would be just a minor annoyance
(if you're still using such a mailer these days you're likely to have
more serious problems anyway :-)). OTOH, preaching the use of obsolete
forms for the sake of backward compatibility can be pretty harmful.
Think f.i. of the Intel's x86 processors: today, in 1998, the latest
Pentium II's still have a "real mode" (in which they have 64k segments
and can't access logical addresses over 1Mb), just for compatibility
with the good old 8086.
cat /path/to/foo.doc;\ # HERES WHERE THE FILE GETS INSERTED
Replace that by
mmencode </path/to/foo.doc;\
echo ;\
Shouldn't that be "mmencode -b"?
My understanding is "Base64" is the default encoding. From the
manual:
: By default, mimencode reads standard input, and sends a
: "base64" encoded version of the input to standard output.
:
: The (really not necessary) "-b" option tells mimencode to
: use the "base64" encoding.
Regards,
Liviu Daia
--
Dr. Liviu Daia e-mail: daia(_at_)stoilow(_dot_)imar(_dot_)ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: http://www.imar.ro/~daia/daia.asc