You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Thomas Cameron <th...@camerontech.com> on 2013/04/08 05:12:08 UTC
Verifying .procmailrc settings to delete high scoring spam messages
All -
I have a pretty simple .procmailrc setup for my home mail server. Right
now it looks like:
:0fw: spamassassin.lock
* < 256000
| spamc
:0:
* ^X-Spam-Flag:.*YES
spam
That dumps everything that is flagged as spam into my spam folder.
I want to delete any spam that scores over 10, though. I believe that I
should insert a new rule between the first and second, and I want to use
the X-Spam-Level header. But since it uses asterisks, which are
interpreted as regex wildcards, I want to make sure I've got the right
syntax. I think I would need to escape out the asterisks, right?
Would it look like this?
:0:
* ^X-Spam-Level:.*\*\*\*\*\*\*\*\*\*\*
/dev/null
I believe that would match 10 asterisks or more, and redirect the e-mail
to /dev/null. Am I right?
Thanks!
Thomas
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Bowie Bailey <Bo...@BUC.com>.
On 4/8/2013 1:06 PM, Walter Hurry wrote:
> On Mon, 08 Apr 2013 10:52:11 +0200, Andrzej A. Filip wrote:
>
>> I would suggest redirecting such messages to another folder/maildir.
>> The folder should auto-purge old messages (e.g. older than 30 days).
>> Shit does happen. I remember at least one case in which mailing list
>> (ham) thread about spammer scored >10.
>>
>> Such very false positives are very unlikely/rare *but* nobody
>> responsible is going to guarantee it will not happen to you.
> I agree that dev-nulling is generally a bad idea, but there may be
> exceptions.
>
> For example, I dump everything from hinet.net straight onto the floor.
By default, I just tag and deliver everything. For some of the company
accounts that have spam problems and for the customers who have asked
for it, I will drop high-scoring spam.
--
Bowie
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings to delete high scoring spam messages]
Posted by Ian Turner <ve...@vectro.org>.
On Monday, April 08, 2013 05:06:57 PM Walter Hurry wrote:
> I agree that dev-nulling is generally a bad idea, but there may be
> exceptions.
>
> For example, I dump everything from hinet.net straight onto the floor.
FWIW, I get ham from hinet.net.
IMHO, it is not appropriate to drop mail no matter how likely it is to be
spam. If you are not going to deliver it, then it should be rejected at SMTP
time with a 550 response.
--Ian
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Walter Hurry <wa...@gmail.com>.
On Mon, 08 Apr 2013 10:52:11 +0200, Andrzej A. Filip wrote:
> I would suggest redirecting such messages to another folder/maildir.
> The folder should auto-purge old messages (e.g. older than 30 days).
> Shit does happen. I remember at least one case in which mailing list
> (ham) thread about spammer scored >10.
>
> Such very false positives are very unlikely/rare *but* nobody
> responsible is going to guarantee it will not happen to you.
I agree that dev-nulling is generally a bad idea, but there may be
exceptions.
For example, I dump everything from hinet.net straight onto the floor.
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by jdow <jd...@earthlink.net>.
On 2013/04/22 06:27, Thomas Cameron wrote:
> On 04/08/2013 03:52 AM, Andrzej A. Filip wrote:
>> On 04/08/2013 05:12 AM, Thomas Cameron wrote:
>>> [...]
>>> I want to delete any spam that scores over 10, though. I believe that I
>>> should insert a new rule between the first and second, and I want to use
>>> the X-Spam-Level header. But since it uses asterisks, which are
>>> interpreted as regex wildcards, I want to make sure I've got the right
>>> syntax. I think I would need to escape out the asterisks, right?
>>>
>>> Would it look like this?
>>>
>>> :0:
>>> * ^X-Spam-Level:.*\*\*\*\*\*\*\*\*\*\*
>>> /dev/null
>>>
>>> I believe that would match 10 asterisks or more, and redirect the e-mail
>>> to /dev/null. Am I right?
>>
>> I would suggest redirecting such messages to another folder/maildir.
>> The folder should auto-purge old messages (e.g. older than 30 days).
>> Shit does happen. I remember at least one case in which mailing list
>> (ham) thread about spammer scored >10.
>>
>> Such very false positives are very unlikely/rare *but* nobody
>> responsible is going to guarantee it will not happen to you.
>
> So, I've set up two IMAP folders, "spam" for messages which are in the 5-10
> range and "super-spam" which are over 10. I've been watching them since the 7th,
> when I updated SA and configured it based on Warren Togami's most excellent
> guide at http://www.spamtips.org/p/ultimate-setup-guide.html.
>
> So far the "super-spam" folder is getting messages at about 10:1 over "spam." I
> have not seen a single FP in "super-spam" in that time. In fact, I have not seen
> ANY FPs in either folder.
>
> At this point, I'm pretty comfortable just nuking that e-mail instead of wasting
> space with it.
>
> Currently I'm using procmail recipes for individual users, but I'm leaning
> heavily towards going back to spamass-milter, and rejecting everything that
> scores 10 or more.
>
> I'm definitely open to suggestions, though. The only argument I have seen so far
> is "you might get a FP." While that is absolutely valid, it has not happened so
> far. If I use spamass-milter, the sender will get a rejection notice, so
> important senders which trigger FPs will be able to call me and let me know.
> Otherwise, I don't think the message is that important. ;-)
>
> Thoughts?
>
> Thomas
>
Thomas, you are still better off using a spam folder or simply a
subject modification that allows easy spam ranking in a spam folder.
I setup a markup such that subjects look much like this:
Subject: *****SPAM***** 016.2 ** Do you have a mesh implant {removed]
That allows me to put anything marked *****SPAM***** at the start of
the subject as spam. And it allows me to sort the spam for how spammy
it is. I can then whiff through the spam in moments to find things
that were miscategorized as spam and salvage them. I (very rarely)
find ham in the spam with scores over 10 on some mailing lists. There
are some people who persist in using tools that invite spam scores
and include messages that look surprisingly spammy in their formatting.
(Source code can VERY often trigger some spam scores, for example.)
And as sure as Murphy's law seems to work with uncanny precision you
will find over the years at least one email among the spam that could
have cost you either a lot of money, a lot of time, critical information,
or lost opportunity.
I've nuked some jerks with /dev/null before it even hits spamassassin.
But I've never nuked merely on the basis of spam scores. That led me
to a job when a friend sent me a note about an opportunity he thought
I could do when he had his hands full. It was caught as spam. And I am
glad I checked and noticed his address. That pushed me to check the mail
(plain text) and discover it was legitimate despite containing a few
"spammy" words or phrases.
Use the mark up to make it easy for you to prioritize your spam scan. I
get 16 to 100 spams a day, depending on day of the week. A quick scan of
the spam folder costs almost no time, no frustration, and seems worth it
to me. Being able to tell T'bird to sort the mail by score REALLY makes
it go fast.
{^_^}
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 04/22/2013 09:29 AM, Andrzej A. Filip wrote:
>>Are you ready/willing to report spam you receive to spamcop.net, razor,
>>pyzor, ...?
On 22.04.13 15:01, Thomas Cameron wrote:
>That's an interesting question...
>
>Each user has their own spam folders, so I guess I should create a
>cron job per user to do so, maybe?
>
>Does anyone do that? Is it smart?
depends on how you train spamassassin. the "spamassassin -r" reports
automatically wherever possible. sa-learn only trains bayes.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines.
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Thomas Cameron <th...@camerontech.com>.
On 04/22/2013 09:29 AM, Andrzej A. Filip wrote:
> False positives in super-spam (>10 SA score) should be very rare.
Exactly my point.
> Are you ready/willing to report spam you receive to spamcop.net, razor,
> pyzor, ...?
That's an interesting question...
Each user has their own spam folders, so I guess I should create a cron
job per user to do so, maybe?
Does anyone do that? Is it smart?
TC
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Benny Pedersen <me...@junc.eu>.
Andrzej A. Filip skrev den 2013-04-22 16:29:
> Are you ready/willing to report spam you receive to spamcop.net,
> razor,
> pyzor, ...?
or dnswl, return-path ? :)
--
senders that put my email into body content will deliver it to my own
trashcan, so if you like to get reply, dont do it
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by "Andrzej A. Filip" <an...@gmail.com>.
On 04/22/2013 03:27 PM, Thomas Cameron wrote:
> On 04/08/2013 03:52 AM, Andrzej A. Filip wrote:
>> On 04/08/2013 05:12 AM, Thomas Cameron wrote:
>>> [...]
>>> I want to delete any spam that scores over 10, though. I believe that I
>>> should insert a new rule between the first and second, and I want to use
>>> the X-Spam-Level header. But since it uses asterisks, which are
>>> interpreted as regex wildcards, I want to make sure I've got the right
>>> syntax. I think I would need to escape out the asterisks, right?
>>>
>>> Would it look like this?
>>>
>>> :0:
>>> * ^X-Spam-Level:.*\*\*\*\*\*\*\*\*\*\*
>>> /dev/null
>>>
>>> I believe that would match 10 asterisks or more, and redirect the e-mail
>>> to /dev/null. Am I right?
>>
>> I would suggest redirecting such messages to another folder/maildir.
>> The folder should auto-purge old messages (e.g. older than 30 days).
>> Shit does happen. I remember at least one case in which mailing list
>> (ham) thread about spammer scored >10.
>>
>> Such very false positives are very unlikely/rare *but* nobody
>> responsible is going to guarantee it will not happen to you.
>
> So, I've set up two IMAP folders, "spam" for messages which are in the
> 5-10 range and "super-spam" which are over 10. I've been watching them
> since the 7th, when I updated SA and configured it based on Warren
> Togami's most excellent guide at
> http://www.spamtips.org/p/ultimate-setup-guide.html.
>
> So far the "super-spam" folder is getting messages at about 10:1 over
> "spam." I have not seen a single FP in "super-spam" in that time. In
> fact, I have not seen ANY FPs in either folder.
>
> At this point, I'm pretty comfortable just nuking that e-mail instead of
> wasting space with it.
>
> Currently I'm using procmail recipes for individual users, but I'm
> leaning heavily towards going back to spamass-milter, and rejecting
> everything that scores 10 or more.
>
> I'm definitely open to suggestions, though. The only argument I have
> seen so far is "you might get a FP." While that is absolutely valid, it
> has not happened so far. If I use spamass-milter, the sender will get a
> rejection notice, so important senders which trigger FPs will be able to
> call me and let me know. Otherwise, I don't think the message is that
> important. ;-)
>
> Thoughts?
False positives in super-spam (>10 SA score) should be very rare.
Are you ready/willing to report spam you receive to spamcop.net, razor,
pyzor, ...?
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Thomas Cameron <th...@camerontech.com>.
On 04/22/2013 09:03 AM, Matus UHLAR - fantomas wrote:
> On 22.04.13 08:27, Thomas Cameron wrote:
>> Currently I'm using procmail recipes for individual users, but I'm
>> leaning heavily towards going back to spamass-milter, and rejecting
>> everything that scores 10 or more.
>
> with thing like spamass-milter I found REFUSING mail (not devnulling!)
> sa safe. I also use score 10 as rejecting threshold.
Yeah, exactly what I had in mind.
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 22.04.13 08:27, Thomas Cameron wrote:
>Currently I'm using procmail recipes for individual users, but I'm
>leaning heavily towards going back to spamass-milter, and rejecting
>everything that scores 10 or more.
with thing like spamass-milter I found REFUSING mail (not devnulling!)
sa safe. I also use score 10 as rejecting threshold.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings
to delete high scoring spam messages]
Posted by Thomas Cameron <th...@camerontech.com>.
On 04/08/2013 03:52 AM, Andrzej A. Filip wrote:
> On 04/08/2013 05:12 AM, Thomas Cameron wrote:
>> [...]
>> I want to delete any spam that scores over 10, though. I believe that I
>> should insert a new rule between the first and second, and I want to use
>> the X-Spam-Level header. But since it uses asterisks, which are
>> interpreted as regex wildcards, I want to make sure I've got the right
>> syntax. I think I would need to escape out the asterisks, right?
>>
>> Would it look like this?
>>
>> :0:
>> * ^X-Spam-Level:.*\*\*\*\*\*\*\*\*\*\*
>> /dev/null
>>
>> I believe that would match 10 asterisks or more, and redirect the e-mail
>> to /dev/null. Am I right?
>
> I would suggest redirecting such messages to another folder/maildir.
> The folder should auto-purge old messages (e.g. older than 30 days).
> Shit does happen. I remember at least one case in which mailing list
> (ham) thread about spammer scored >10.
>
> Such very false positives are very unlikely/rare *but* nobody
> responsible is going to guarantee it will not happen to you.
So, I've set up two IMAP folders, "spam" for messages which are in the
5-10 range and "super-spam" which are over 10. I've been watching them
since the 7th, when I updated SA and configured it based on Warren
Togami's most excellent guide at
http://www.spamtips.org/p/ultimate-setup-guide.html.
So far the "super-spam" folder is getting messages at about 10:1 over
"spam." I have not seen a single FP in "super-spam" in that time. In
fact, I have not seen ANY FPs in either folder.
At this point, I'm pretty comfortable just nuking that e-mail instead of
wasting space with it.
Currently I'm using procmail recipes for individual users, but I'm
leaning heavily towards going back to spamass-milter, and rejecting
everything that scores 10 or more.
I'm definitely open to suggestions, though. The only argument I have
seen so far is "you might get a FP." While that is absolutely valid, it
has not happened so far. If I use spamass-milter, the sender will get a
rejection notice, so important senders which trigger FPs will be able to
call me and let me know. Otherwise, I don't think the message is that
important. ;-)
Thoughts?
Thomas
Dev-nulling is a bad idea [Was: Verifying .procmailrc settings to
delete high scoring spam messages]
Posted by "Andrzej A. Filip" <an...@gmail.com>.
On 04/08/2013 05:12 AM, Thomas Cameron wrote:
> [...]
> I want to delete any spam that scores over 10, though. I believe that I
> should insert a new rule between the first and second, and I want to use
> the X-Spam-Level header. But since it uses asterisks, which are
> interpreted as regex wildcards, I want to make sure I've got the right
> syntax. I think I would need to escape out the asterisks, right?
>
> Would it look like this?
>
> :0:
> * ^X-Spam-Level:.*\*\*\*\*\*\*\*\*\*\*
> /dev/null
>
> I believe that would match 10 asterisks or more, and redirect the e-mail
> to /dev/null. Am I right?
I would suggest redirecting such messages to another folder/maildir.
The folder should auto-purge old messages (e.g. older than 30 days).
Shit does happen. I remember at least one case in which mailing list
(ham) thread about spammer scored >10.
Such very false positives are very unlikely/rare *but* nobody
responsible is going to guarantee it will not happen to you.
Re: Verifying .procmailrc settings to delete high scoring spam
messages
Posted by Lucio Chiappetti <lu...@lambrate.inaf.it>.
On Sun, 7 Apr 2013, Bob Proulx wrote:
> Thomas Cameron wrote:
>> I believe that would match ... and redirect the e-mail to /dev/null. Am
>> I right?
I would'nt comment on the exact procmail syntax. I have lots of procmail
rules but wrote them long ago and my memory is getting rusty. I would
comment on some general issues.
> Also it is safer to store to a mail folder at least long enough to
> test your recipe. So just as a general paranoia instead of /dev/null
> I would at least start with a mail folder and then only after I have
> convinced myself that it is good to go only then convert it to a real
> /dev/null.
> For me I don't tend to /dev/null things immediately. I tend to always
> keep at least a queue of them around so that I can look at them.
I have a quite detailed antispam policy, the first steps of which depend
on our institute-wide policy (which I instigated), and the rest is based
on procmail http://sax.iasf-milano.inaf.it/~lucio/Procmail/
Anyhow, our spamassassin runs on the server, after a graylisting (and
since we have that most spam is blocked by graylisting), and quarantines
very very suspect stuff (on a per-server basis, not per-user ... a crontab
mails each user daily about the cumulative stuff for him/her in
quarantine, but it is rather rare that there are false positives
requesting an action. The quarantine occurs in one folder per day, and a
crontab purges folder older than a week.
My .procmailrc (apart from diverting some very specific subjects to
particular folders) does a further screening in several levels.
Originally (that was before the institute wide spamassassin was set up)
the most spammy level plus the blacklists were diverted to different
folders (named according to the reason, e.g. funny alphabets, blacklists,
virus) in a subdirectory REJECTED. All these folders were softlinked to
/dev/null. The reason to have different softlinks was that the procmail
log allowed to count a statistics of the reasons.
Now the different folders are not linked anymore to /dev/null, but to
a common folder. The (rather few) messages going there are inspected
(daily when I am present), and if not false positive, I feed the entire
folder to sa-learn on the institute server.
There are four further levels flagged by my procmail rules: suspect spam,
spam, quarantine and ok. The first two levels correspond to a directory
which contains date-named folders. I purge folders older than a week, but,
unless I'm on holiday, I am rarely away for more than a week, and can
check eventual false positives.
The quarantine directory contains a per-origin-address folders from
messages which require a challenge-and-response from the sender. The rest
(ok) is delivered normally.
So all variations on the theme ... keep it for a while and have the system
get rid of them !
--
------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
Do not blame ME, I did NOT vote Berlusconi (1994). NOR Grillo (2013).
Bis zu einem gewissen Grad bin ich entsetzt,
dass zwei Clowns gewonnen haben (Peer Steinbrueck,SPD)
------------------------------------------------------------------------
Re: Much better procmail alternative (was Re: Verifying .procmailrc
settings to delete high scoring spam messages)
Posted by Martin Gregorie <ma...@gregorie.org>.
On Mon, 2013-04-08 at 19:41 -0400, David F. Skoll wrote:
> On Mon, 8 Apr 2013 16:02:27 -0600
> Bob Proulx <bo...@proulx.com> wrote:
>
> > Karsten Bräckelmann wrote:
>
> > > Unfortunately, no. While procmail implements some flavor of
> > > "extended" Regular Expressions, there are still quite some
> > > differences to other regex engines,
>
> I got sufficiently fed up with procmail that I switched to
> Email::Filter from CPAN. If that's an option for you, I strongly
> recommend it. If you use SpamAssassin, you may already enjoy Perl hacking.
>
> My .procmailrc:
>
> :0
> | /usr/bin/perl /home/dfs/.mail-filter.pl >> /home/dfs/.mail-filter.log 2>&1
>
> and .mail-filter.pl is a greatly expanded version of the example at
> http://search.cpan.org/~rjbs/Email-Filter-1.032/lib/Email/Filter.pm
>
Not intending to trump David, but if you're not a Perl hacker, my
C-based solution may suit. Its a program, spamkiller, that sits behind
spamc and passes ham to your mail delivery setup. Spam can either be
quarantined or chucked into /dev/null. I've included scripts that manage
the quarantine bin and Perl scripts that extend logwatch to report on
spamkiller's operation and the content of the quarantine bin plus a php
page for examining quarantined spam.
Available as a tarball from http://www.libelle-systems.com/free/
Martin
> Regards,
>
> David.
Much better procmail alternative (was Re: Verifying .procmailrc
settings to delete high scoring spam messages)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Mon, 8 Apr 2013 16:02:27 -0600
Bob Proulx <bo...@proulx.com> wrote:
> Karsten Bräckelmann wrote:
> > Unfortunately, no. While procmail implements some flavor of
> > "extended" Regular Expressions, there are still quite some
> > differences to other regex engines,
I got sufficiently fed up with procmail that I switched to
Email::Filter from CPAN. If that's an option for you, I strongly
recommend it. If you use SpamAssassin, you may already enjoy Perl hacking.
My .procmailrc:
:0
| /usr/bin/perl /home/dfs/.mail-filter.pl >> /home/dfs/.mail-filter.log 2>&1
and .mail-filter.pl is a greatly expanded version of the example at
http://search.cpan.org/~rjbs/Email-Filter-1.032/lib/Email/Filter.pm
Regards,
David.
Re: Verifying .procmailrc settings to delete high scoring spam
messages
Posted by Bob Proulx <bo...@proulx.com>.
Karsten Bräckelmann wrote:
> Bob Proulx wrote:
> > * ^X-Spam-Level: \*{10}
>
> Unfortunately, no. While procmail implements some flavor of "extended"
> Regular Expressions, there are still quite some differences to other
> regex engines, like egrep's or PCRE. Most notably, the repetition
> operator {n} or {n,m} is not supported by procmail.
Drat! I hate giving wrong advice. Thanks for the correction!
I had actually pulled that out if an egrep expression that I am
actually using. My mistake was assuming that it would be the same in
procmail's ERE engine. And you know what happens when I "assume".
Thanks,
Bob
Re: Verifying .procmailrc settings to delete high scoring spam
messages
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2013-04-07 at 21:44 -0600, Bob Proulx wrote:
[ Bunch of good advise snipped. ]
> :0
> * ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*
> devnull/
>
> Since procmail uses Extended Regular Expressions there is one more
> optimization I would make. I wouldn't list out every star. It gets
> hard to count. Is there ten there? Or nine? Or eleven? Quick,
> without counting, how many? See that is hard. But you can use the
> normal extended regular expression syntax to simply list the number.
>
> :0
> * ^X-Spam-Level: \*{10}
> devnull/
Unfortunately, no. While procmail implements some flavor of "extended"
Regular Expressions, there are still quite some differences to other
regex engines, like egrep's or PCRE. Most notably, the repetition
operator {n} or {n,m} is not supported by procmail.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Verifying .procmailrc settings to delete high scoring spam messages
Posted by Thomas Cameron <th...@camerontech.com>.
On 04/07/2013 10:44 PM, Bob Proulx wrote:
> Thomas Cameron wrote:
>> :0:
>> * ^X-Spam-Level:.*\*\*\*\*\*\*\*\*\*\*
>> /dev/null
>>
>> I believe that would match 10 asterisks or more, and redirect the
>> e-mail to /dev/null. Am I right?
>
> Mostly all okay. However I don't like the ".*" in the front of
> it. That isn't likely to cause trouble but it is possible that it
> could on a crafted email message with a lot of garbage cause trouble.
> And it isn't needed. We know there will always be one space there.
> So no need for the ".*" there.
Noted, thank you!
> With /dev/null you don't need the trailing ":" in the ":0:"
> designating a lockfile. I think procmail special cases /dev/null to
> avoid the lock file in that case anyway. But just the same I wouldn't
> put the trailing colon lockfile for /dev/null.
Thanks, I realized that after I hit send. I think that was a bad
copy-n-paste, it's been taken out.
> Also it is safer to store to a mail folder at least long enough to
> test your recipe. So just as a general paranoia instead of /dev/null
> I would at least start with a mail folder and then only after I have
> convinced myself that it is good to go only then convert it to a real
> /dev/null. I like maildir folders so will normally use "folder/" to
> have procmail create a maildir folder format. And maildir folders
> never need a lockfile. But use what you like.
>
> :0
> * ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*
> devnull/
Good call, done.
> Since procmail uses Extended Regular Expressions there is one more
> optimization I would make. I wouldn't list out every star. It gets
> hard to count. Is there ten there? Or nine? Or eleven? Quick,
> without counting, how many? See that is hard. But you can use the
> normal extended regular expression syntax to simply list the number.
>
> :0
> * ^X-Spam-Level: \*{10}
> devnull/
>
> That makes the counting quick and easy.
That is very cool, thank you for the regex advice!
> For me I don't tend to /dev/null things immediately. I tend to always
> keep at least a queue of them around so that I can look at them. With
> maildir format each message is an individual file. Meaning that it is
> easy to delete them by age from the devnull/* directories. I would
> keep something like this around for whatever you feel is reasonable.
> I would probably say ten days. That way if I need to go looking for a
> potentially very spammy message I could still find it within the time
> window. I would run this daily from cron.
>
> find $HOME/Mail/devnull -type f -mtime +10 -delete
>
> HTH,
> Bob
Great advice, Bob, thank you very much! I've been watching the cruft in
my spam mail folder, and I've never seen anything over 10 that was a
false positive. I'm very confident that 10+ needs to just be nuked, but
I see your point. I'll let it get filtered into a temporary mail folder
for a few days to make sure I'm right, though.
Thank you very much for the excellent advice, I really appreciate it!
TC
Re: Verifying .procmailrc settings to delete high scoring spam
messages
Posted by Bob Proulx <bo...@proulx.com>.
Thomas Cameron wrote:
> :0:
> * ^X-Spam-Level:.*\*\*\*\*\*\*\*\*\*\*
> /dev/null
>
> I believe that would match 10 asterisks or more, and redirect the
> e-mail to /dev/null. Am I right?
Mostly all okay. However I don't like the ".*" in the front of
it. That isn't likely to cause trouble but it is possible that it
could on a crafted email message with a lot of garbage cause trouble.
And it isn't needed. We know there will always be one space there.
So no need for the ".*" there.
With /dev/null you don't need the trailing ":" in the ":0:"
designating a lockfile. I think procmail special cases /dev/null to
avoid the lock file in that case anyway. But just the same I wouldn't
put the trailing colon lockfile for /dev/null.
Also it is safer to store to a mail folder at least long enough to
test your recipe. So just as a general paranoia instead of /dev/null
I would at least start with a mail folder and then only after I have
convinced myself that it is good to go only then convert it to a real
/dev/null. I like maildir folders so will normally use "folder/" to
have procmail create a maildir folder format. And maildir folders
never need a lockfile. But use what you like.
:0
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*
devnull/
Since procmail uses Extended Regular Expressions there is one more
optimization I would make. I wouldn't list out every star. It gets
hard to count. Is there ten there? Or nine? Or eleven? Quick,
without counting, how many? See that is hard. But you can use the
normal extended regular expression syntax to simply list the number.
:0
* ^X-Spam-Level: \*{10}
devnull/
That makes the counting quick and easy.
For me I don't tend to /dev/null things immediately. I tend to always
keep at least a queue of them around so that I can look at them. With
maildir format each message is an individual file. Meaning that it is
easy to delete them by age from the devnull/* directories. I would
keep something like this around for whatever you feel is reasonable.
I would probably say ten days. That way if I need to go looking for a
potentially very spammy message I could still find it within the time
window. I would run this daily from cron.
find $HOME/Mail/devnull -type f -mtime +10 -delete
HTH,
Bob