[Bug 6439] Extend the meaning of "textual parts" like MUAs handle it

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=3D6439

--- Comment #30 from Kent Oyer <[email protected]> ---
Created attachment 6069
  --> https://bz.apache.org/SpamAssassin/attachment.cgi?id=3D6069&action=3D=
edit
Add scan_text_attachments config option

This bug is still bugging me.=20

SA unconditionally drops text/* parts with "Content-Disposition: attachment"
from the text body rules run against, with no override. Phishers exploit th=
is
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 attachment=
s or
attachments without an extension.=20

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 befo=
re
where invisible text from attachments was always included, and visible text=
 was
always excluded.=20

I'm not sure the reason for this inconsistency but I assume it has to do wi=
th
Bayes. However, IMHO this can (should) be controlled with the existing conf=
ig
option 'bayes_token_sources'.=20

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.=20

Soliciting feedback before I commit.

--=20
You are receiving this mail because:
You are the assignee for the bug.=