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
