Dennis B. Hopp wrote:
On Wed, 2010-03-10 at 20:22 +0000, Martin Gregorie wrote:
On Wed, 2010-03-10 at 13:37 -0600, Dennis B. Hopp wrote:
Obviously we just have to tell the clients that they need to deal with
the various e-mail providers, but is there an effective way that I can
filter these messages out before my users see them without blacklisting
the address?
There's nothing in SA that can blacklist a sending MTA, so blacklisting
can't happen unless you've added something to your MTA set-up that does
auto-blacklisting.
I meant blacklisting the sender address, not the MTA.
Welcome to Whack-A-Spammer! Here's your pea-shooter; the targets are
behind 3 feet of concrete on the other side of this mile-wide canyon.
Sarcasm aside, there are two problems with blacklisting the sender to
block spam:
1) Spammers rotate sender addresses and hijacked account info more
often than most of us change our underwear. An account *may* get
reused; chances are it'll be months before it does, and the spammers
will have rotated through hundreds or thousands of others - both
phish-cracked and those set up just to send their junk. Blacklisting a
sender is reduced to blocking the persistent friend-of-a-friend who
refuses to remove you from the endless stream of chain-forwards, and
legitimate-but-totally-clueless mailing list operators who can't figure
out how to unsubscribe you from their list. :(
2) You noted originally that these appear to be fully legitimate
freemail accounts, legitimately used in the past to correspond with your
customers/clients, that have been compromised and then used to send
spam. How do you propose to still allow the legitimate account holders
to email your clients if you blacklist the sender?
The question then comes down to marking the message as spam and dealing
with it however you normally deal with spam. You'll probably need custom
rule(s) to handle that. You say the message bodies are quite variable,
but I notice that the Reply-to: header doesn't remotely match the From:
header. Is this a common factor?
The ones that I have seen the reply-to doesn't match the from and I
think the reply-to have all been something.jp
If it is, and the body texts have no common features that could also be
used, the only obvious approach would be a rule for each forged sending
domain that fires if the sending domain doesn't match the Reply-to
domain.
There isn't anything in common that I can see that wouldn't be
susceptible to false positives. One even left the clients signature
intact. I've written fairly simple custom rules before but I'm not sure
how to do conditional rules. I'll have to dig into the docs a little
more.
Martin's suggestion followup should point you in the right direction.
Sets of phrase rules (how similar are these messages? do you have ten
or fifteen you can compare sentence-by-sentence?) with low scores will
likely help some too. Meta rules that bump the score up depending on
how many phrases hit, or phrase+mismatched-sender/reply also work
tolerably well on this class of spam... if you can get enough samples to
build a complete enough set of phrase rules.
You'll have to decide how to balance aggressiveness on the content vs
still allowing legitimate messages through.
Feeding these to Bayes should also help some.
-kgd
