https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6439
--- Comment #30 from Kent Oyer <[email protected]> --- Created attachment 6069 --> https://bz.apache.org/SpamAssassin/attachment.cgi?id=6069&action=edit Add scan_text_attachments config option This bug is still bugging me. SA unconditionally drops text/* parts with "Content-Disposition: attachment" from the text body rules run against, with no override. Phishers exploit this by delivering the payload as an attached text or html file, bypassing every body rule. I have been working around it by using ExtractText like so: extracttext_external cat /usr/bin/cat {} extracttext_use cat .txt But this only works if the Content-Type is 'application/octet-stream' or anything other than 'text/plain'. It also doesn't help with html attachments or attachments without an extension. The attached patch does two things: 1. Adds a new configuration option 'scan_text_attachments' which defaults to false, but when enabled causes SA to include text/plain and text/html attachments for rendering and makes their contents available to body rules. 2. Removes the condition ($method_name ne 'invisible_rendered') so that text from attachments is included or excluded consistently across all three views (rendered, visible_rendered, and invisible_rendered) I believe this is a better paradigm, but it's a slight regression from before where invisible text from attachments was always included, and visible text was always excluded. I'm not sure the reason for this inconsistency but I assume it has to do with Bayes. However, IMHO this can (should) be controlled with the existing config option 'bayes_token_sources'. In other words, bayes_token_sources already controls whether to include invisible text, and the new scan_text_attachments should control whether to include attached text. They are orthogonal properties. Soliciting feedback before I commit. -- You are receiving this mail because: You are the assignee for the bug.
