As a bit of background for this proposal, I personally have no problem
trading a small overhead of some additional headers in a delivered email
if I can see the serviceability info I need directly in the email in 2
seconds vs scanning/filtering through massive logs (assuming the logs
were even set to 'debug' level when the mail came through). I realize
that other admins may or may not be willing to make this tradeoff. So
the new function in this proposal is completely optional to the admin.
Not enabling it will result in no changes for the user.
Problem: SpamAssassin is an incredible tool for controlling spam. But
the current version of the mailet hands an email to SA where it runs a
billion rules and comes back with "yup it's spam" or "nope it's
clean". That's perfectly acceptable for every single email received
where we agree with the SA result. The problem comes in when a client
complains about false positives or false negatives. Currently, the only
possible response we can give the client is "because SpamAssassin said
so" with no analysis data. When SA needs tuning, I need a fighting
chance at seeing how the (possibly incorrect) score was derived so I can
make adjustments to the SA rules as needed.
Solution Proposal Background: The current implementation of the
SpamAssassin mailet and SpamAssassinInvoker hardcodes the command to
spamd as "CHECK" which returns yes or no with a bit of threshold info.
Another valid command option to spamd is "REPORT". It gives back the
same info as "CHECK". But it also returns analysis data. Example:
SPAMD/1.1 0 EX_OK
Spam: False ; 3.9 / 5.0
Spam detection software, running on the system "p5353013",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
webmas...@jwmhosting.com for details.
Content preview: ======================================== View on Facebook
https://www.facebook.com/nd/?Fox32Chic...
[...]
Content analysis details: (3.9 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-2.5 RCVD_IN_HOSTKARMA_W RBL: Sender listed in HOSTKARMA-WHITE
[69.171.232.132 listed in
hostkarma.junkemailfilter.com]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[69.171.232.132 listed in wl.mailspike.net]
-0.1 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[69.171.232.132 listed in list.dnswl.org]
1.0 CK_HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname
(Split IP)
0.0 TVD_RCVD_IP Message was received from an IP address
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or
identical to background
0.0 HTML_MESSAGE BODY: HTML included in message
1.1 KAM_REALLYHUGEIMGSRC RAW: Spam with image tags with ridiculously
huge http urls
0.5 JAM_SMALL_FONT_SIZE RAW: Body of mail contains parts with very
small font
3.9 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP
addr 2)
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
Solution Proposal:
a) Add a new SpamAssassin mailet parameter (in addition to spamdPort,
spamdHost) in mailetContainer.xml named "spamdCommand". Absence of this
parameter will default to the current "CHECK" command. The two valid
options are CHECK and REPORT.
b) Pass the specified spamdCommand (or default) to spamd in Invoker.
c) If spamdCommand is REPORT, add the report data as headers to the
email using the following procedure: parse full response into a TreeMap
using "X-SpamAssassin_nnn" as keys. nnn is an incrementing number in
case the headers get jumbled and/or alphabetized downstream.
d) The input stream from SA must be reset after REPORT processing. So
add mark()/reset() to BufferedReader to rewind the reader so existing
downstream processing is not affected. A limit (currently 2500
characters) must be set on mark(..). Check to ensure that limit is not
exceeded during REPORT processing. If it gets close to the limit, stop
and add a "more..." header and exit.
e) Pass the reportData TreeMap to SpamAssassinResult on both empty(..)
and build(..) methods. SpamAssassinResult will walk the TreeMap data
and add to HeadersPerRecipient in the same way existing processing adds
the Spam flags. SpamAssassinResult will also log the TreeMap header
data. Why on 'empty()'? empty() is called if the parser can't find a
specific key in the string. There still may be some kind of error output
even if the key is missing that could be very useful in determining why
the expected key wasn't returned. So I recommend we dump what we got
back from SA no matter what.
f) The final step is to process the HeadersPerRecipient data into real
headers. It turns out this function is missing downstream and a defect
report has been opened by Tellier. So when the code is available that
processes HeadersPerRecipients into actual headers is available, no
additional work is required.
g) Currently if REPORT, the reportData automatically goes both to the
log and to headers. Not currently in my implementation, but we could
add one more mailet parm "reportAsHeaders= true/false" so they could
still get the report in the logs but not as headers.
Summary: Admin can change the mailet parameter command to REPORT. When
a user reports false positive or false negative on an email. Open the
email in Thunderbird, hit Ctrl-U to view raw source/headers, and
immediately see the scoring details from SpamAssassin. Obviously the
next step for the admin would be to do something in SA to alter the
scoring. But that's beyond the scope of this proposal.
I currently have this function coded and tested (currently with a hack
to get around the bug in (f) above. I have had an old implementation
running in v3b5 for several years. I can give personal testimony to the
hours it has saved me.
Comments/Suggestions welcome
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
