4:57 p.m.
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
--
=====================================================================
D. D. Brierton darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
5:58 p.m.
Am Do, den 05.08.2004 schrieb D. D. Brierton um 23:57:
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?
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.
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
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
is correct syntax.
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
6:17 p.m.
On Thu, 2004-08-05 at 23:58, Alexander Dalloz wrote:
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.
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.
> 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
* ^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 ("*")?
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 darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
6:45 p.m.
On Thu, 2004-08-05 at 19:17, D. D. Brierton wrote:
On Thu, 2004-08-05 at 23:58, Alexander Dalloz wrote:
> 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. :)
--
Scot L. Harris
webid(a)cfl.rr.com
if (!cost_analysis) goto darwinism;
- Mike Galbraith explaining economics on linux-kernel
8:11 p.m.
On Fri, 2004-08-06 at 00:45, Scot L. Harris wrote:
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.
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.)
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.
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 darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
8:16 p.m.
On Fri, 2004-08-06 at 02:11, D. D. Brierton wrote:
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
--
=====================================================================
D. D. Brierton darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
8:45 p.m.
Am Fr, den 06.08.2004 schrieb D. D. Brierton um 3:11:
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(a)metatron.dogma.lan>, reject=550 5.7.1 recipient
denied, because MX 10 'Vent.mokrohajska-school.sk.' [193.87.162.1] for
<pkramervb(a)mokrohajska-school.sk> rejected sender. Their reason
"<pkramervb(a)mokrohajska-school.sk>: User unknown": 1 Time(s)
discarded: 1 Time(s)
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
9:15 p.m.
On Fri, 2004-08-06 at 02:45, Alexander Dalloz wrote:
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(a)metatron.dogma.lan>, reject=550 5.7.1 recipient
denied, because MX 10 'Vent.mokrohajska-school.sk.' [193.87.162.1] for
<pkramervb(a)mokrohajska-school.sk> rejected sender. Their reason
"<pkramervb(a)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
--
=====================================================================
D. D. Brierton darren(a)dzr-web.com www.dzr-web.com
Trying is the first step towards failure (Homer Simpson)
=====================================================================
9:43 p.m.
Am Fr, den 06.08.2004 schrieb D. D. Brierton um 4:15:
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_veri...
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
8:47 p.m.
On Thu, 2004-08-05 at 21:11, D. D. Brierton wrote:
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.
> 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.
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.
> 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.
--
Scot L. Harris
webid(a)cfl.rr.com
Ummm, well, OK. The network's the network, the computer's the computer.
Sorry for the confusion.
-- Sun Microsystems
7230
days inactive
7231
days old
9 comments
3 participants
participants (3)
-
Alexander Dalloz -
D. D. Brierton -
Scot L. Harris