Hi All,
(Developers in particular ;-)
I don't know if other people are finding this a big issue, but in the last
couple of months or so I'm having a real problem with "bounce" messages of
spam getting through.
Directly sent spam is not a problem, I have things tuned pretty well, and
apart from the odd message that slips through, SA has been *very* effective.
But what I'm seeing now, which could be a deliberate spammer tactic, is
bounce returns of spam which have a complete copy of the spam contained
within it, as a standard bounce message attachment. Many/Most email clients
extract and display this attachment as if it was part of the message, so
the end result is that the user see's the spam.
Currently there is no good way to catch this, as the attached message does
not get any header tests run on it, and matches few body tests either. I
can't really do much about blocking bounces, or legitimate bounces might
get blocked.
As far as I can see, the only people that should genuinely get bounces
which contain spam, are spammers themselves, and since they aren't using
their real addresses or running SA on their incomming mail, thats not a
problem ;-)
Legitimate people using SpamAssasin aren't going to be sending their own
spam, so we can safely assume that any bounces containing spam didn't
originate from them.
I can only see this problem getting worse in the future as more spammers
cotton on to this, so what I suggest (for 2.7 ?) is this:
An option to extract RFC bounce messages, and then run header and body
tests on the contained message *as well as* the actual message itself.
After the two scores are computed, the highest one of the two is used.
One other issue would be what to do in the case of autolearning. Obviously
you wouldn't want the original bounce message being learnt if it was the
attached message which was really the spam, so in that case, the extracted
message should be learnt.
Yes it does mean double processing of *some* messages, but I don't see any
alternative, if the practice is going to become more common. The only
external way of doing it would be to use some external program to look for
and extract bounce message attachments, and run a second copy of SA to
analyze them - messy, and far more overhead than integrating it into the
basic spamassassin architecture.
Comments anyone ?
Regards,
Simon
(Developers in particular ;-)
I don't know if other people are finding this a big issue, but in the last
couple of months or so I'm having a real problem with "bounce" messages of
spam getting through.
Directly sent spam is not a problem, I have things tuned pretty well, and
apart from the odd message that slips through, SA has been *very* effective.
But what I'm seeing now, which could be a deliberate spammer tactic, is
bounce returns of spam which have a complete copy of the spam contained
within it, as a standard bounce message attachment. Many/Most email clients
extract and display this attachment as if it was part of the message, so
the end result is that the user see's the spam.
Currently there is no good way to catch this, as the attached message does
not get any header tests run on it, and matches few body tests either. I
can't really do much about blocking bounces, or legitimate bounces might
get blocked.
As far as I can see, the only people that should genuinely get bounces
which contain spam, are spammers themselves, and since they aren't using
their real addresses or running SA on their incomming mail, thats not a
problem ;-)
Legitimate people using SpamAssasin aren't going to be sending their own
spam, so we can safely assume that any bounces containing spam didn't
originate from them.
I can only see this problem getting worse in the future as more spammers
cotton on to this, so what I suggest (for 2.7 ?) is this:
An option to extract RFC bounce messages, and then run header and body
tests on the contained message *as well as* the actual message itself.
After the two scores are computed, the highest one of the two is used.
One other issue would be what to do in the case of autolearning. Obviously
you wouldn't want the original bounce message being learnt if it was the
attached message which was really the spam, so in that case, the extracted
message should be learnt.
Yes it does mean double processing of *some* messages, but I don't see any
alternative, if the practice is going to become more common. The only
external way of doing it would be to use some external program to look for
and extract bounce message attachments, and run a second copy of SA to
analyze them - messy, and far more overhead than integrating it into the
basic spamassassin architecture.
Comments anyone ?
Regards,
Simon