On Tue, 17 Jun 2003, Paul Chvostek wrote:
:0 E
* PARTS ?? ^^1^^
* ^Content-Type: text/html
{ W="multipart header but single html part body" }
That should be ":0 EB", no? (Or B?? on the second condition.)
I don't think I've ever seen a Content-Type: multipart header with a
single part that was not spam.
Some MUAs do that if you attach (say) an image and then send the message
without typing anything into the editor. That is, they won't promote a
single "attachment" to a top-level content-type: image/*. If the sender
happened to attach an empty file ...
You also apparently don't care whether there's a multipart inside a
multipart with an empty part in the inner multipart?
Ooh, hadn't thought of that. I guess you could just handle that with:
* ! B ?? Content-Type: multipart
Depends on what "handle that" means, I suppose.
So this might be more like it:
WSPC=" "
NL="($)"
Why put it in brackets? Does it change the variable interpretation in
the recipe, or is it to avoid the possibility of erroneous variable
expansion as you set $NL?
The latter. Usually I wouldn't do that except in a context like this:
* $ B ?? ^$\MATCH($)Content-
where I don't want "$Content" to be taken as a variable name. That
mistake would bother me more than Ruud's giggling does.
:0
* $ ^Content-Type:[$WSPC]*multipart/.*boundary="\/[^"]+
* $ B ^--$\MATCH$NL(\
Hmm, I left out the ?? after B there.
(.+$NL)*\
Content-Type:[$WSPC]+text/plain.*$NL\
(.+$NL)*\
)?$NL\
([$WSPC]*$NL)*\
^--$\MATCH(--)?$NL
{ W="empty text/plain block" }
That's great. The last thing I'd suggest would be to make the final
WSPC atom 1-or-more rather than 0-or-more, since lack of a blank line
would cause the next boundary (and its block) to be tacked on to the
bottom of the previous block. I think. ;)
If I understand correctly, you're worried about this sort of thing:
--theboundarystring
Content-Type: text/plain
--theboundarystring
Content-Type: text/html
<p>
--theboundarystring--
Yes, you're right, that would fail to match the test above (in several
ways) because it's such badly-formatted MIME. The change you suggest
wouldn't be enough to fix it; I think I'd just test for that kind of
syntax problem separately, rather than treat it as an "empty part".
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail