[FWD] Re: Greylisting mails with URLs

Sander Smeenk <[email protected]>
Newsgroups gmane.mail.exim.spamassassin
Message-ID <[email protected]>
[hum, did a direct reply instead of a group reply]

Quoting Paul Makepeace ([email protected]):

You obviously were bored today :)  *heheh*

> Roughly: something to tag the email with a "URL/domain of some
> description whatever detected" and then in the GL code look for that
> domain and possibly use that as an additional or parallel GL parameter
> along with envelope and host info.

I filter out stuff on URL by creating my own set of spamassassin rules.
Greylisting as it is now would also filter out this kind of spam, won't
it? 

> Paul

ok, next mail...

Quoting Paul Makepeace ([email protected]):

> I'm sure this is obvious...
> I've noticed spamassassin is writing its various bits to
> /var/spool/exim4/.spamassassin which is Debian-exim's home dir.

True. If not configured to do otherwise.

> How is it getting this? spamd is started and indeed runs as root via
> /etc/init.d/spamassassin. So is it picking up the $HOME via spamc
> called via local_scan in exim?

Exim runs as Debian-exim, local_scal (exim that is) calls spamc, spamc
runs spamassassin as the calling user, and that is Debian-exim, whose
$HOME points to /var/spool/exim4.

>   mkdir /var/lib/spamassassin
>   chown -R Debian-exim:Debian-exim /var/lib/spamassassin

I'm thinking of doing this in my next sa-exim packages. Especially with
greylisting stuff, it's more and more important to have a nice place for
spamassassin / sa-exim related cruft. imho. Nice transition scripts, so
current setups will get converted... hmm.

> Paul

next message!

Quoting Paul Makepeace ([email protected]):

> Actually RTFM I noticed the bayes_ignore_header option:
> Which prompted me to wonder about,
>   bayes_ignore_header X-SA-Exim-Connect-IP
>   bayes_ignore_header X-SA-Exim-Mail-From
>   bayes_ignore_header X-SA-Exim-Rcpt-To
>   bayes_ignore_header X-SA-Exim-Scanned
>   bayes_ignore_header X-SA-Exim-Version

Never cared about those. They always contain the same values, and I
don't think they will actually cause spam to score higher or lower.
Must admit I haven't tried, and I don't think it would HURT adding these
headers in the ignore_header list.

> Paul

ok, next message!

Quoting Paul Makepeace ([email protected]):

> In the hopes this might spark a thread of "here's stuff I did to get
> SA-exim to work more effectively" here is a list of some recent changes
> I've been experimenting with:
> FWIW, I've found the stock SA 2.63 misses sufficiently much spam now
> that the Bayes classifier is autolearning spam, which then feeds back
> and lets even more through. To help against that I used,
>   bayes_auto_learn_threshold_nonspam -0.5
> ..rather than the default of 0.1.

Hmm. I have thought about NOT having SA-exim autolearn ham and spam,
since my system runs on my own personal bayes databases. I have
configured my spamassassin to read /home/ssmeenk/.spamassassin/bayes_*
instead.

I have required hits at 4.0, and reject mail at a score of 8.0. A friend
of mine has his permreject set to 4.0, and no problems, according to
him. I don't want to risk legit mail, since i'm also scanning for some
of the other users on my system, using MY bayes db's..
 
> The extra rules at the SA Rules Emporium have helped a lot too:
> http://www.rulesemporium.com/

Hmm. I only have the 'backhair' set, and then a ever growing set of
self-made rules in which I put rules that trigger on persistant spam
that comes through the normal rules.

> (e.g. the antidrug.cf stuff if you're a meds provider).

I've looked at the antidrug.cf set, that almost resembles my anti drug
set, which filters out a LOT of spam :)

> The SpamCopURI patch to query SURBL is well worth adding as the
> URL/domain is sometimes about the only thing that identifies a
> mail as spam. http://sourceforge.net/projects/spamcopuri

I didn't want to use remote checks, because then my mail delivery would
depend on someone elses ability to keep a stable server, AND my
connection was too slow to handle that back then. I could check it out
now, along with sender / recipient callouts.

> The SA-exim greylisting patch is really great - benefits:
> IMO, if you've been putting off implementing this on your system,
> definitely consider pushing it up the sysadmin TODO list.

I hate patching spamassassin. Marc, any word on upstream implementing
your patches? :)

> Paul

next message!

ah, no next message.
okay then. 

I also drop TONS of mails with my ACL in exim that rejects HELO's with
my own IP. I don't know if you already have that, but i'd recommend it.

Furthermore I noticed that recently more and more spam came through the
filters, but I think this had to do with the Received-header problem,
and me still running sa-exim.
I fear that my bayes db's might have been "poisoned"...

Another question, do you sa-learn? And if so, do you sa-learn ham, spam
or both? I only sa-learn spam. This works for me, but people told me I
should also sa-learn ham...

For now, this is all my text, and i will go fix me some food. :)

Regards,
Sander.
-- 
| Why is the time of day with the slowest traffic called rush hour?
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D

----- End forwarded message -----

-- 
| Why do they call it "chilli" if it's hot?
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.