http://bugzilla.spamassassin.org/show_bug.cgi?id=4469
Summary: Add a process/option to efficiently deal with very long
mail messages
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P4
Component: spamc/spamd
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
There are starting to be occasional reports of very large spams that make it
past SA by virtue of the length cutoff limit.
Passing the entire message to SA would of course not be a Good Thing to do.
However, armchair reasoning suggests that the spaminess of the message can
probably be determined reasonably accurately from the headers and the first
2..10K or so of the message body in virtually all cases. In fact, this is
probably virtually always true, even with messages in the 20K..250K range.
Suggest two things here: an option to SA (perhaps a special line on the front
of the message stream itself) that tells it that this will be a partial
message, and secondly a change to spamd to pass partial messages, along with
this flag, when some size limit is exceeded.
Since only a partial message is being passed, obviously spamd can't just pipe
the entire message thru SA and out the other end. Instead, it will have to get
a declaration from SA of spaminess, and then do something itself with the
original message.
The purpose of the flag to SA for a partial message would be twofold: it would
disable some of the rules that expect correct mime-part terminations, and it
might change the output from SA to perhaps only be headers for the message,
plus a return value that somehow indicates spam. This return value might be in
the form of a real return value, or a first header line with special
formatting, or perhaps something else.
If SA operating in this mode returned modified headers only, it would be
trivial for the spamd child to remove the original message headers and replace
them with the SA-supplied headers, and pipe the rest of the message straight
through, thus avoiding the SA large-message overhead.
However this sort of option is implemented (if it is), it should be done in a
way that tools calling SA or the SA API directly can fairly easily implement
spam detection using this option.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
