Joey J wrote:
Thanks Everyone.
Within all of the responses, I will try to reply here.
1. The legit sender will talk about big numbers because of the real
things he is involved with so big numbers is still a valid method to
score, just not in this case.
2. The SPF record is set to fail on no match, however this does not
automatically say, ok it's the approved source everything is ok, let
them spam out, SA will still score content, and simply not score for bad
SPF.
3. The goal is to say for user j...@company.com <mailto:j...@company.com>,
if we can confirm the source is their mail server IP, the lets add some
negative value, lets say -2, to allow message that might be scored such
as the above #1 because they are legit.
Unless there is something I'm missing, I'm not sure how to better
explain it.
Yes, I can provide the full headers, but I thought the spam info was
enough to provide the SA aspect of the scoring.
This is why I thought of the extra rule based on email address and IP
combo, almost confirming its legit, to add ot the negative score.
If you really want to go down this road, and assign small or
individualized scores for senders like this instead of just using
welcomelist_from_(rcvd|dkim|spf) or welcomelist_auth, use something like
this:
header __FROM_GOODGUY From:addr =~ /^joe\@company\.com$/
header __RCVD_GOODGUY X-Spam-Relays-External =~ /^\[ ip=1\.2\.3\.4 /
meta NOTSPAM_GOODGUY __FROM_GOODGUY && __RCVD_GOODGUY
describe NOTSPAM_GOODGUY Score nudge for j...@company.com
score NOTSPAM_GOODGUY -2
Have a long read through "man Mail::SpamAssassin::Conf" to deconstruct
those.
But that doesn't scale well to very many senders, where welcomelist_*
seem to scale pretty well to at least low thousands of entries. _spf
and _dkim in particular also rely on other information published by the
sender, so *you* don't have to keep manually updating your rules if
their mail sending infrastructure changes.
I'd be more inclined to to some per-user score setting on the
*recipient* account - ie, whoever is receiving these can have a line
added to ~/.spamassassin/user_prefs (or whereever you're storing SA
userprefs) saying "score BIGNUM_EMAILS_MANY (-1)".
I'd also see if you can narrow down exactly what
Phishing.Email.SpoofedDomain is hitting on, IME it's all too likely to
fire on a certain class of legitimate mail and what you've described
sounds like a prime place for FPs. Calling ClamAV like this either
requires a plugin or relies on ClamAV being called earlier, and leaving
a header for SA to check. You'll have to do a bit more digging to find
out how it's configured.
Locally I started with the plugin on the wiki
(https://cwiki.apache.org/confluence/display/SPAMASSASSIN/ClamAVPlugin)
and extended it quite a bit. I've just posted the current production
version at http://deepnet.cx/~kdeugau/spamtools/clamav.pm. I have that
particular Clam hit scored at 1.5 due to the FP potential.
-kgd
