BUG: filter_begin always gets a multipart MIME::Entity

I recently tried to revive an old idea that I had never previously 
implemented fully (much less tested) to catch an idiosyncratic spam 
pattern: messages labeled as multipart/mixed at the top level which in 
fact only contain a single text/plain part. Imagine my surprise on 
seeing that whenever a text/plain message hits filter_begin, EVEN ONE 
WITH NO MIME HEADER, the return of both MIME::Entity->mime_type() and 
MIME::Entity->effective_type() from the Entity passed in is 
'multipart/mixed' and MIME::Entity->parts() is 1. This is apparently a 
manifestation of documented behavior in an undocumented circumstance: 
mimedefang-filter (5) says an existing message that is not already 
multipart/mixed will be wrapped in a multipart/mixed container if you 
call action_add_part(). I don't. Anywhere. Ever.

Having figured this out (and being currently not otherwise occupied...) 
I think I understand how to work around it by examining the HEADERS file 
directly. This isn't ideal. Since the whole point of looking for 
multipart/* messages with a single text/plain part is identifying 
members of a family of spam early with minimal effort, parsing a text 
file to do it right is not a win.

_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang