Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings to delete high scoring spam messages]
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, uh...@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]
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
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings to delete high scoring spam messages]
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, uh...@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]
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]
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]
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]
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]
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: Much better procmail alternative (was Re: Verifying .procmailrc settings to delete high scoring spam messages)
On Mon, 2013-04-08 at 19:41 -0400, David F. Skoll wrote: On Mon, 8 Apr 2013 16:02:27 -0600 Bob Proulx b...@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 21 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.
Re: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings to delete high scoring spam messages]
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: Verifying .procmailrc settings to delete high scoring spam messages
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)
Dev-nulling is a bad idea [Was: Verifying .procmailrc settings to delete high scoring spam messages]
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: Dev-nulling is a bad idea [Was: Verifying .procmailrc settings to delete high scoring spam messages]
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]
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: Verifying .procmailrc settings to delete high scoring spam messages
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;il;i++){ i%8? c=1:
(c=*++x); c128 (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
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
Much better procmail alternative (was Re: Verifying .procmailrc settings to delete high scoring spam messages)
On Mon, 8 Apr 2013 16:02:27 -0600 Bob Proulx b...@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 21 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.
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: Verifying .procmailrc settings to delete high scoring spam messages
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
Re: Verifying .procmailrc settings to delete high scoring spam messages
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
