> As a reminder: it's about consolidating the
>
> textfile1 -> textfile0
>
> slip ...
Now I finally read the MIME RFC 2046, and found the reason
that is actually causing the problem with multipart messages:
"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."
Now, that extra unused space is where that infamous
"This is a multipart message in MIME format."
is put as a courtesy of some UAs to help MIME-unaware
tools.
But ripMIME (as well being a MIME-aware tool) should
*not* extract that, as it is not a valid message part
(it's more like a graffity :) ), and then all would
work well.
Thanks for your kind attention and patience!
Cheers,
Sab
>
> textfile1 -> textfile0
>
> slip ...
Now I finally read the MIME RFC 2046, and found the reason
that is actually causing the problem with multipart messages:
"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."
Now, that extra unused space is where that infamous
"This is a multipart message in MIME format."
is put as a courtesy of some UAs to help MIME-unaware
tools.
But ripMIME (as well being a MIME-aware tool) should
*not* extract that, as it is not a valid message part
(it's more like a graffity :) ), and then all would
work well.
Thanks for your kind attention and patience!
Cheers,
Sab