On 04/06/2011 01:00 PM, John Hardin wrote:
> Dang, I thought these were already in my sandbox:
>
> describe TO_TOO_MANY To: too many recipients
> header TO_TOO_MANY To =~ /(?:,[^,]{1,80}){30}/
>
> describe TO_WAY_TOO_MANY To: too many recipients
> header TO_WAY_TOO_MANY ToCc =~ /(?:,[^,]{1,80}){50}/
>
> describe CC_TOO_MANY Cc: too many recipients
> header CC_TOO_MANY Cc =~ /(?:,[^,]{1,80}){30}/
It's been in mine for ages:
header KHOP_BIG_TO_CC ToCc =~ /(?:[^,\@]{1,60}\@[^,]{4,25},){10}/
describe KHOP_BIG_TO_CC Sent to 10+ recipients instaed of Bcc or a list
I'm pretty sure I've had several other iterations of it as well, but
they've all been wiped because they perform miserably. This is a good
mark of a nontechnical user rather than spam. Most of its hits are ham.
http://ruleqa.spamassassin.org/20110319/%2FKHOP_BIG_TO_CC
MSECS SPAM% HAM% S/O RANK SCORE NAME
0 0.5786 0.6643 0.466 0.42 0.01 T_KHOP_BIG_TO_CC
Looking at the score map, most spam this hit is already easily marked as
such.
My recollection of earlier incarnations of these rules is that they were
reliably under the 0.400 S/O mark.
This is best implemented at the MTA. Reject too many recipients and
make sure that the sender knows what was wrong.
signature.asc
Description: OpenPGP digital signature
