Mon 98-01-12 Vikas Agnihotri <VikasA(_at_)att(_dot_)com> list.procmail
Hi Vikas,
| > Works fine for MS Explorer, MS Express, Netscape, Lotus notes
| > attachements and for any other you may receive.
|
| I agree, Jari, If you recall, I was in touch with you a littlw while back
| and you modified your PM code to include my Lotus notes attachment killing.
| It is working fine and I can see how it is extensible to handle any type of
| attachments. Thanks.
|
| The reason for my asking was that Era seemed to hint that these awk/sed
| methods of killing attachments (like yours is) are not 100% bulletproof and
| in some cases might mangle some MIME attachments.
Yes, it may be possible that any procmail script fails to understand
MIME in full. The specialized tools that are designed for mime are
the right ones when 100% accuracy is expected.
| Frankly, MIME is a pretty simple format and I would want Era to explain
| exactly in which cases Jari's pm-jamimekill.rc might not produce expected
| results.
I think era just meant that using munpack would be another alternative.
| The only thing I can think of is that the boundary string might exist in
| the actual attachment and mess up things, but then even the Perl module or
| compiled C program is not immune to that, right?
At least that's impossible. The boundady string mentioned in Header section, is
guarranteed to be "one time string". So even if you
include many mime messages inside each other, the top level will always have
unique boundary string.
The only vulnerable part in the script is the additional line killing hint:
JA_MIME_KILL_RE = ${JA_MIME_KILL_RE:-"name=.*(pcx|PCX)|charset=|This is.*MIME"}
To be safe, you could set it to "#_#" (or anything that is guarranteed not to
match , to be sure that nothing vulnerable won't be killed. Eg if you
receive perl script that happend to have
next if /This is MIME multipart/;
That line would be wiped away. Hmm, I have to write note on this
to the documentation. Thanks.
jari