[OT] procmail recipe advice for spamassassin

[D. D. Brierton]

Could anyone give me some quick advice on writing a procmail recipe? I'm
currently running spamd as a service and procmail filters messages
through spamc by including this line:

INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

This works great, especially in conjunction with bayesian filtering
using sa-learn on false negative and positives (well I've only ever had
one of the latter). But a lot of the spam I receive has a ridiculously
high spam score, for example 28.0! Messages with such a high score
should just get dumped in /dev/null. What would you suggest is a
sensible and safe minimum score for something to go into /dev/null? 12?
15? Higher?

Now, as for the recipe. I'm guessing it should go something like this
(if 15 is the score -- I'm assuming each asterix represents 1 point):

:0 H
* ^X-Spam-Level:\s-*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

What I *think* my regexp above says is 'match a line beginning (^) with
"X-Spam-Level:" followed by any amount of white space (\s-*) followed by
"***************" (\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*).'

Any comments or advice? I don't want this to eat my brane.

TIA.

Best, Darren

[Alexander Dalloz]

Post by D. D. Brierton
Could anyone give me some quick advice on writing a procmail recipe? I'm
currently running spamd as a service and procmail filters messages
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
This works great, especially in conjunction with bayesian filtering
using sa-learn on false negative and positives (well I've only ever had
one of the latter). But a lot of the spam I receive has a ridiculously
high spam score, for example 28.0! Messages with such a high score
should just get dumped in /dev/null. What would you suggest is a
sensible and safe minimum score for something to go into /dev/null? 12?
15? Higher?

I wouldn't at all put anything to /dev/null automatically. Just let it
write to an mbox file or Maildir which you once a week or every 2 weeks
observer with just a few, quick looks. Then, if nothing good in it, kill
all confirmed SPAM.

I would start at about 5 or 6 points by SA to normal SPAM folder, up to
15 points to a certain SPAM folder, up from 15 to a very certain SPAM
folder. In your .procmailrc you have to let the message pass the rules
from high SPAM level check to lower level.

Post by D. D. Brierton
Now, as for the recipe. I'm guessing it should go something like this
:0 H
* ^X-Spam-Level:\s-*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

is correct syntax.

Post by D. D. Brierton
What I *think* my regexp above says is 'match a line beginning (^) with
"X-Spam-Level:" followed by any amount of white space (\s-*) followed by
"***************" (\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*).'
Any comments or advice? I don't want this to eat my brane.
Best, Darren

You know that the SpamAssassin website has exactly fitting documentation
about that?

http://wiki.apache.org/spamassassin/UsedViaProcmail

Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 00:50:12 up 1 day, 18:17, load average: 0.14, 0.25, 0.20
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040806/2baed266/attachment.bin

[D. D. Brierton]

Post by Alexander Dalloz
I wouldn't at all put anything to /dev/null automatically. Just let it
write to an mbox file or Maildir which you once a week or every 2 weeks
observer with just a few, quick looks. Then, if nothing good in it, kill
all confirmed SPAM.

I guess that will be the right thing to do initially, to test it's
working. But eventually I want anything that is 99.9% probable spam to
go straight to the bit bucket. It isn't *that* time consuming to check
through spam to make sure it really is spam, but I've realised recently
that it makes me really really annoyed (at the spammers) and I could
just do without that.

Post by Alexander Dalloz
I would start at about 5 or 6 points by SA to normal SPAM folder, up to
15 points to a certain SPAM folder, up from 15 to a very certain SPAM
folder. In your .procmailrc you have to let the message pass the rules
from high SPAM level check to lower level.

That's okay. I let Evolution filter into a Junk folder on the header:

X-Spam-Status: Yes

The procmail extra recipe I'm considering below is to prune the size of
that folder, so I don't have so much annoying cr*p to check over.

Post by Alexander Dalloz

Post by D. D. Brierton
Now, as for the recipe. I'm guessing it should go something like this
:0 H
* ^X-Spam-Level:\s-*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
is correct syntax.

Right. So I don't have to worry about whether there is one or more
spaces in between the colon (":") and the first asterisk ("*")?

Post by Alexander Dalloz
You know that the SpamAssassin website has exactly fitting documentation
about that?
http://wiki.apache.org/spamassassin/UsedViaProcmail

Sorry. No, I really didn't and I *did* google this before posting. For
some reason it didn't show up.

Thanks Alexander for the feedback. It's much appreciated.

Best, Darren

[Scot L. Harris]

Post by D. D. Brierton

Post by Alexander Dalloz
I wouldn't at all put anything to /dev/null automatically. Just let it
write to an mbox file or Maildir which you once a week or every 2 weeks
observer with just a few, quick looks. Then, if nothing good in it, kill
all confirmed SPAM.

I guess that will be the right thing to do initially, to test it's
working. But eventually I want anything that is 99.9% probable spam to
go straight to the bit bucket. It isn't *that* time consuming to check
through spam to make sure it really is spam, but I've realised recently
that it makes me really really annoyed (at the spammers) and I could
just do without that.
From the sound of things you are running a full MTA using sendmail or

procmail. If you really don't want to have to wade through the spam
that spamassassin marks for you try greylisting.

I implemented milter-greylist with sendmail. We were getting between
3000 and 6000 spam messages a day. After implementing greylisting we
get 3 to 10 spam a day. (that is not a typo, 3 to 10)

spamassassin tags the ones that still come in but the time it takes to
check for false positives is negligible now. In addition the email
server does not use nearly the resources it once did. Plus the savings
on bandwidth since the server never receives the body of the spam
messages.

If you are using procmail there is software available that implements
greylisting for that as well.

Since implementing this I have been able to get back to doing real work
instead of fighting spam so much. :)

[D. D. Brierton]

Post by D. D. Brierton
From the sound of things you are running a full MTA using sendmail or
procmail.

fetchmail, postfix, and procmail (although procmail does very little, I
let Evolution do all of my filtering into folders).

I'm not sure you'd call it a *full* MTA, in the sense that it isn't open
to the outside world. Because I'm a web developer its useful to have a
mail server running on the loopback interface so I can't test web
applications which need to connect to an SMTP server.

But I do pull my mail using fetchmail, which means it ends up via
postfix and procmail in /var/spool/mail/darren which is where Evolution
finds it.

Post by D. D. Brierton
If you really don't want to have to wade through the spam
that spamassassin marks for you try greylisting.

Yes, I've read up on grey-listing a little, and I think I've seen a post
or two on this list about it. The trouble is that I'm not sure if it
would work for me. (But I haven't had a chance to look into it
properly.)

Post by D. D. Brierton
I implemented milter-greylist with sendmail. We were getting between
3000 and 6000 spam messages a day. After implementing greylisting we
get 3 to 10 spam a day. (that is not a typo, 3 to 10)

I get between 200 and 300 a day. But the trouble is that all the mail is
retrieved by fetchmail, from servers where its already been accepted. I
don't know if grey-listing would work in those circumstances.

Post by D. D. Brierton
Since implementing this I have been able to get back to doing real work
instead of fighting spam so much. :)

Spam doesn't make too much of an impact on my time, but it really does
on my mood. I'm not sure which is worse. Sometime I feel myself just
getting really angry when I'm going through the spam folder. I know I
should try and chill more, but spammers really irritate me. It's the
sort of anti-social behaviour that just chips a few degrees off of the
quality of everyone's lives. They really piss me off.

Best, Darren

[D. D. Brierton]

its useful to have a mail server running on the loopback interface so
I can't test web applications which need to connect to an SMTP server.

Heh. There's nothing like a typo which entirely reverses the meaning of
what you were trying to say.

I meant to say "so I CAN test web applications".

Best, Darren

[Alexander Dalloz]

Post by D. D. Brierton
I get between 200 and 300 a day. But the trouble is that all the mail is
retrieved by fetchmail, from servers where its already been accepted. I
don't know if grey-listing would work in those circumstances.

No, in that situation greylisting would be contra productive.

Real time sender verification with your Postfix. I use it for
fetchmailed mail with milter-sender integrated into Sendmail. It saves
me from a lot of SPAM because many if not most senders of SPAM is faked
and thus not existing. This way, with sender address verification the
mail is simply discarded. An example from my logs:

Milter: to=<fetchmail at metatron.dogma.lan>, reject=550 5.7.1 recipient
denied, because MX 10 'Vent.mokrohajska-school.sk.' [193.87.162.1] for
<pkramervb at mokrohajska-school.sk> rejected sender. Their reason
"<pkramervb at mokrohajska-school.sk>: User unknown": 1 Time(s)
discarded: 1 Time(s)

Post by D. D. Brierton
Best, Darren

Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 03:40:40 up 1 day, 21:08, load average: 0.30, 0.23, 0.19
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040806/0653512d/attachment.bin

[D. D. Brierton]

Post by Alexander Dalloz
Real time sender verification with your Postfix. I use it for
fetchmailed mail with milter-sender integrated into Sendmail. It saves
me from a lot of SPAM because many if not most senders of SPAM is faked
and thus not existing. This way, with sender address verification the
Milter: to=<fetchmail at metatron.dogma.lan>, reject=550 5.7.1 recipient
denied, because MX 10 'Vent.mokrohajska-school.sk.' [193.87.162.1] for
<pkramervb at mokrohajska-school.sk> rejected sender. Their reason
"<pkramervb at mokrohajska-school.sk>: User unknown": 1 Time(s)
discarded: 1 Time(s)

Do you have a URL or some such where I could read up on this a bit more?
That looks very interesting. (Even if I don't implement it for myself,
it could be very useful for web applications that talk to SMTP servers,
which we all know is a security minefield.)

Thanks a lot for the great feedback.

Best, Darren

[Alexander Dalloz]

Post by D. D. Brierton
Do you have a URL or some such where I could read up on this a bit more?
That looks very interesting. (Even if I don't implement it for myself,
it could be very useful for web applications that talk to SMTP servers,
which we all know is a security minefield.)
Best, Darren

Postfix: http://www.postfix.org/ADDRESS_VERIFICATION_README.html
http://www.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_sender_address_verification.shtml

Sendmail: http://www.snert.com/Software/milter-sender/

General information about techniques:

http://slett.net/spam-filtering-for-mx/smtpchecks.html

Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 04:36:27 up 1 day, 22:04, load average: 0.22, 0.12, 0.16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040806/bcb5bf70/attachment.bin

[Alexander Dalloz]

Post by D. D. Brierton
Do you have a URL or some such where I could read up on this a bit more?
That looks very interesting. (Even if I don't implement it for myself,
it could be very useful for web applications that talk to SMTP servers,
which we all know is a security minefield.)
Best, Darren

Postfix: http://www.postfix.org/ADDRESS_VERIFICATION_README.html
http://www.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_sender_address_verification.shtml

Sendmail: http://www.snert.com/Software/milter-sender/

General information about techniques:

http://slett.net/spam-filtering-for-mx/smtpchecks.html

Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 04:36:27 up 1 day, 22:04, load average: 0.22, 0.12, 0.16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040806/bcb5bf70/attachment-0002.bin

[D. D. Brierton]

Post by Alexander Dalloz
Real time sender verification with your Postfix. I use it for
fetchmailed mail with milter-sender integrated into Sendmail. It saves
me from a lot of SPAM because many if not most senders of SPAM is faked
and thus not existing. This way, with sender address verification the
Milter: to=<fetchmail at metatron.dogma.lan>, reject=550 5.7.1 recipient
denied, because MX 10 'Vent.mokrohajska-school.sk.' [193.87.162.1] for
<pkramervb at mokrohajska-school.sk> rejected sender. Their reason
"<pkramervb at mokrohajska-school.sk>: User unknown": 1 Time(s)
discarded: 1 Time(s)

Do you have a URL or some such where I could read up on this a bit more?
That looks very interesting. (Even if I don't implement it for myself,
it could be very useful for web applications that talk to SMTP servers,
which we all know is a security minefield.)

Thanks a lot for the great feedback.

Best, Darren

[Scot L. Harris]

Post by D. D. Brierton
fetchmail, postfix, and procmail (although procmail does very little, I
let Evolution do all of my filtering into folders).
But I do pull my mail using fetchmail, which means it ends up via
postfix and procmail in /var/spool/mail/darren which is where Evolution
finds it.

Ah. Then greylisting won't do you much good. The way it works is when
a remote MTA (or spammer) tries to send you a message your MTA issues a
415 error (temporary error message) and saves the remote MTA's IP
address, the sender address, and the recipient address as a tuple. A
delay is imposed so if the same MTA tries to send the same message again
before the delay has timed out it will get another 415 error. After the
delay period when the MTA tries again the message is accepted.
Depending on the implementation that particular tuple can be auto
whitelisted for 24 hours or whatever you decide to set. So any
additional email from that source will not be delayed.

For legitimate email message will be delayed but will still get
through. The actual delay is dependent on the remote MTA's settings.

Spammers on the other had typically don't queue up a message and resend
it. After the first 415 error they just move on to another
message/system so you never hear from them again.

With a delay value of just a few minutes you get as good a result as if
you used 30 minutes for the delay.

Post by D. D. Brierton

Post by Scot L. Harris
If you really don't want to have to wade through the spam
that spamassassin marks for you try greylisting.

Yes, I've read up on grey-listing a little, and I think I've seen a post
or two on this list about it. The trouble is that I'm not sure if it
would work for me. (But I haven't had a chance to look into it
properly.)

Since you are using fetchmail it won't work. Sorry.

Post by D. D. Brierton
I get between 200 and 300 a day. But the trouble is that all the mail is
retrieved by fetchmail, from servers where its already been accepted. I
don't know if grey-listing would work in those circumstances.

Post by Scot L. Harris
Since implementing this I have been able to get back to doing real work
instead of fighting spam so much. :)

Spam doesn't make too much of an impact on my time, but it really does
on my mood. I'm not sure which is worse. Sometime I feel myself just
getting really angry when I'm going through the spam folder. I know I
should try and chill more, but spammers really irritate me. It's the
sort of anti-social behaviour that just chips a few degrees off of the
quality of everyone's lives. They really piss me off.
Best, Darren

I am with you on that! I just don't understand why there are enough
people out there answering this crap to make it worth the time and
effort to send it out. Have never been able to understand that.

I have been using spamassassin at home via filter in my email client.
About once a week I clear out the spam folder after checking it and
feeding to sa-learn. I get maybe 4 or 5 that slip through to my inbox.
And I can't remember the last time I had a false positive.

At work with greylisting the spam problem has all but gone away. Highly
recommended if you can set it up. If all MTAs implemented along with
spamassassin the spam problem would pretty much be solved.

[D. D. Brierton]

its useful to have a mail server running on the loopback interface so
I can't test web applications which need to connect to an SMTP server.

Heh. There's nothing like a typo which entirely reverses the meaning of
what you were trying to say.

I meant to say "so I CAN test web applications".

Best, Darren

[Alexander Dalloz]

Post by D. D. Brierton
I get between 200 and 300 a day. But the trouble is that all the mail is
retrieved by fetchmail, from servers where its already been accepted. I
don't know if grey-listing would work in those circumstances.

No, in that situation greylisting would be contra productive.

Real time sender verification with your Postfix. I use it for
fetchmailed mail with milter-sender integrated into Sendmail. It saves
me from a lot of SPAM because many if not most senders of SPAM is faked
and thus not existing. This way, with sender address verification the
mail is simply discarded. An example from my logs:

Milter: to=<fetchmail at metatron.dogma.lan>, reject=550 5.7.1 recipient
denied, because MX 10 'Vent.mokrohajska-school.sk.' [193.87.162.1] for
<pkramervb at mokrohajska-school.sk> rejected sender. Their reason
"<pkramervb at mokrohajska-school.sk>: User unknown": 1 Time(s)
discarded: 1 Time(s)

Post by D. D. Brierton
Best, Darren

Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 03:40:40 up 1 day, 21:08, load average: 0.30, 0.23, 0.19
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040806/0653512d/attachment-0002.bin

[Scot L. Harris]

Post by D. D. Brierton
fetchmail, postfix, and procmail (although procmail does very little, I
let Evolution do all of my filtering into folders).
But I do pull my mail using fetchmail, which means it ends up via
postfix and procmail in /var/spool/mail/darren which is where Evolution
finds it.

Ah. Then greylisting won't do you much good. The way it works is when
a remote MTA (or spammer) tries to send you a message your MTA issues a
415 error (temporary error message) and saves the remote MTA's IP
address, the sender address, and the recipient address as a tuple. A
delay is imposed so if the same MTA tries to send the same message again
before the delay has timed out it will get another 415 error. After the
delay period when the MTA tries again the message is accepted.
Depending on the implementation that particular tuple can be auto
whitelisted for 24 hours or whatever you decide to set. So any
additional email from that source will not be delayed.

For legitimate email message will be delayed but will still get
through. The actual delay is dependent on the remote MTA's settings.

Spammers on the other had typically don't queue up a message and resend
it. After the first 415 error they just move on to another
message/system so you never hear from them again.

With a delay value of just a few minutes you get as good a result as if
you used 30 minutes for the delay.

Post by D. D. Brierton

Post by Scot L. Harris
If you really don't want to have to wade through the spam
that spamassassin marks for you try greylisting.

Yes, I've read up on grey-listing a little, and I think I've seen a post
or two on this list about it. The trouble is that I'm not sure if it
would work for me. (But I haven't had a chance to look into it
properly.)

Since you are using fetchmail it won't work. Sorry.

Post by D. D. Brierton
I get between 200 and 300 a day. But the trouble is that all the mail is
retrieved by fetchmail, from servers where its already been accepted. I
don't know if grey-listing would work in those circumstances.

Post by Scot L. Harris
Since implementing this I have been able to get back to doing real work
instead of fighting spam so much. :)

Spam doesn't make too much of an impact on my time, but it really does
on my mood. I'm not sure which is worse. Sometime I feel myself just
getting really angry when I'm going through the spam folder. I know I
should try and chill more, but spammers really irritate me. It's the
sort of anti-social behaviour that just chips a few degrees off of the
quality of everyone's lives. They really piss me off.
Best, Darren

I am with you on that! I just don't understand why there are enough
people out there answering this crap to make it worth the time and
effort to send it out. Have never been able to understand that.

I have been using spamassassin at home via filter in my email client.
About once a week I clear out the spam folder after checking it and
feeding to sa-learn. I get maybe 4 or 5 that slip through to my inbox.
And I can't remember the last time I had a false positive.

At work with greylisting the spam problem has all but gone away. Highly
recommended if you can set it up. If all MTAs implemented along with
spamassassin the spam problem would pretty much be solved.

[D. D. Brierton]

Post by D. D. Brierton
From the sound of things you are running a full MTA using sendmail or
procmail.

fetchmail, postfix, and procmail (although procmail does very little, I
let Evolution do all of my filtering into folders).

I'm not sure you'd call it a *full* MTA, in the sense that it isn't open
to the outside world. Because I'm a web developer its useful to have a
mail server running on the loopback interface so I can't test web
applications which need to connect to an SMTP server.

But I do pull my mail using fetchmail, which means it ends up via
postfix and procmail in /var/spool/mail/darren which is where Evolution
finds it.

Post by D. D. Brierton
If you really don't want to have to wade through the spam
that spamassassin marks for you try greylisting.

Yes, I've read up on grey-listing a little, and I think I've seen a post
or two on this list about it. The trouble is that I'm not sure if it
would work for me. (But I haven't had a chance to look into it
properly.)

Post by D. D. Brierton
I implemented milter-greylist with sendmail. We were getting between
3000 and 6000 spam messages a day. After implementing greylisting we
get 3 to 10 spam a day. (that is not a typo, 3 to 10)

I get between 200 and 300 a day. But the trouble is that all the mail is
retrieved by fetchmail, from servers where its already been accepted. I
don't know if grey-listing would work in those circumstances.

Post by D. D. Brierton
Since implementing this I have been able to get back to doing real work
instead of fighting spam so much. :)

Spam doesn't make too much of an impact on my time, but it really does
on my mood. I'm not sure which is worse. Sometime I feel myself just
getting really angry when I'm going through the spam folder. I know I
should try and chill more, but spammers really irritate me. It's the
sort of anti-social behaviour that just chips a few degrees off of the
quality of everyone's lives. They really piss me off.

Best, Darren

[Scot L. Harris]

Post by D. D. Brierton

Post by Alexander Dalloz
I wouldn't at all put anything to /dev/null automatically. Just let it
write to an mbox file or Maildir which you once a week or every 2 weeks
observer with just a few, quick looks. Then, if nothing good in it, kill
all confirmed SPAM.

I guess that will be the right thing to do initially, to test it's
working. But eventually I want anything that is 99.9% probable spam to
go straight to the bit bucket. It isn't *that* time consuming to check
through spam to make sure it really is spam, but I've realised recently
that it makes me really really annoyed (at the spammers) and I could
just do without that.
From the sound of things you are running a full MTA using sendmail or

procmail. If you really don't want to have to wade through the spam
that spamassassin marks for you try greylisting.

I implemented milter-greylist with sendmail. We were getting between
3000 and 6000 spam messages a day. After implementing greylisting we
get 3 to 10 spam a day. (that is not a typo, 3 to 10)

spamassassin tags the ones that still come in but the time it takes to
check for false positives is negligible now. In addition the email
server does not use nearly the resources it once did. Plus the savings
on bandwidth since the server never receives the body of the spam
messages.

If you are using procmail there is software available that implements
greylisting for that as well.

Since implementing this I have been able to get back to doing real work
instead of fighting spam so much. :)

[D. D. Brierton]

Post by Alexander Dalloz
I wouldn't at all put anything to /dev/null automatically. Just let it
write to an mbox file or Maildir which you once a week or every 2 weeks
observer with just a few, quick looks. Then, if nothing good in it, kill
all confirmed SPAM.

I guess that will be the right thing to do initially, to test it's
working. But eventually I want anything that is 99.9% probable spam to
go straight to the bit bucket. It isn't *that* time consuming to check
through spam to make sure it really is spam, but I've realised recently
that it makes me really really annoyed (at the spammers) and I could
just do without that.

Post by Alexander Dalloz
I would start at about 5 or 6 points by SA to normal SPAM folder, up to
15 points to a certain SPAM folder, up from 15 to a very certain SPAM
folder. In your .procmailrc you have to let the message pass the rules
from high SPAM level check to lower level.

That's okay. I let Evolution filter into a Junk folder on the header:

X-Spam-Status: Yes

The procmail extra recipe I'm considering below is to prune the size of
that folder, so I don't have so much annoying cr*p to check over.

Post by Alexander Dalloz

Post by D. D. Brierton
Now, as for the recipe. I'm guessing it should go something like this
:0 H
* ^X-Spam-Level:\s-*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
is correct syntax.

Right. So I don't have to worry about whether there is one or more
spaces in between the colon (":") and the first asterisk ("*")?

Post by Alexander Dalloz
You know that the SpamAssassin website has exactly fitting documentation
about that?
http://wiki.apache.org/spamassassin/UsedViaProcmail

Sorry. No, I really didn't and I *did* google this before posting. For
some reason it didn't show up.

Thanks Alexander for the feedback. It's much appreciated.

Best, Darren

[D. D. Brierton]

Could anyone give me some quick advice on writing a procmail recipe? I'm
currently running spamd as a service and procmail filters messages
through spamc by including this line:

INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

This works great, especially in conjunction with bayesian filtering
using sa-learn on false negative and positives (well I've only ever had
one of the latter). But a lot of the spam I receive has a ridiculously
high spam score, for example 28.0! Messages with such a high score
should just get dumped in /dev/null. What would you suggest is a
sensible and safe minimum score for something to go into /dev/null? 12?
15? Higher?

Now, as for the recipe. I'm guessing it should go something like this
(if 15 is the score -- I'm assuming each asterix represents 1 point):

:0 H
* ^X-Spam-Level:\s-*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

What I *think* my regexp above says is 'match a line beginning (^) with
"X-Spam-Level:" followed by any amount of white space (\s-*) followed by
"***************" (\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*).'

Any comments or advice? I don't want this to eat my brane.

TIA.

Best, Darren

[Alexander Dalloz]

Post by D. D. Brierton
Could anyone give me some quick advice on writing a procmail recipe? I'm
currently running spamd as a service and procmail filters messages
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
This works great, especially in conjunction with bayesian filtering
using sa-learn on false negative and positives (well I've only ever had
one of the latter). But a lot of the spam I receive has a ridiculously
high spam score, for example 28.0! Messages with such a high score
should just get dumped in /dev/null. What would you suggest is a
sensible and safe minimum score for something to go into /dev/null? 12?
15? Higher?

I wouldn't at all put anything to /dev/null automatically. Just let it
write to an mbox file or Maildir which you once a week or every 2 weeks
observer with just a few, quick looks. Then, if nothing good in it, kill
all confirmed SPAM.

I would start at about 5 or 6 points by SA to normal SPAM folder, up to
15 points to a certain SPAM folder, up from 15 to a very certain SPAM
folder. In your .procmailrc you have to let the message pass the rules
from high SPAM level check to lower level.

Post by D. D. Brierton
Now, as for the recipe. I'm guessing it should go something like this
:0 H
* ^X-Spam-Level:\s-*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

is correct syntax.

Post by D. D. Brierton
What I *think* my regexp above says is 'match a line beginning (^) with
"X-Spam-Level:" followed by any amount of white space (\s-*) followed by
"***************" (\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*).'
Any comments or advice? I don't want this to eat my brane.
Best, Darren

You know that the SpamAssassin website has exactly fitting documentation
about that?

http://wiki.apache.org/spamassassin/UsedViaProcmail

Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 00:50:12 up 1 day, 18:17, load average: 0.14, 0.25, 0.20
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040806/2baed266/attachment-0002.bin