On Wed, 15 Oct 1997 15:11:47 -0500 (CDT), dattier(_at_)wwa(_dot_)com
(David W. Tamkin) wrote:
Dan Smith answered,
| I didn't look it up, but I think MIME requires this (the format was
| intended to be easy to parse). Also, for multipart/alternative and
Not quite that easy. There was an earlier RFC for forwarded messages
which said to precede any lines in the forward which start with a dash
with another dash-space sequence. The authors of the MIME spec don't
like this idea, because what happens when you have a forward inside a
forward inside a ...? One of the goals of MIME is to provide a
transparent way to keep all line lenghts under a certain threshold for
the time of transport; the "prepend a string" idea is
counter-productive from this perspective because it makes lines longer
when we would like very much to avoid that. (It is not impossible to
make this work but like you say, the format was meant to be easy to
parse.)
Glad to have helped. Perhaps we can extend it to accept lines consisting
of nothing but two hyphens or two hyphens and a space so that a .sig sepa-
rator isn't mistaken for a multipart boundary:
* $ ^--$boundary$\/(.?([^-].*|- ?)?$)+
So this will in fact match any boundary, not just the boundaries in
the message we are presently trying to parse, won't it? I would think
you'll have to grab the separator line from the message header's
Content-Type but when you have that, parsing should be fairly
straightforward and I don't think you'll need to change your recipes
much.
I believe I have a couple of rather complex MIME messages on store
somewhere; I could certainly generate a few if you want something to
test with :-)
/* era */
--
Paparazzi of the Net: No matter what you do to protect your privacy,
they'll hunt you down and spam you. <http://www.iki.fi/~era/spam/>