Re: Tuning recommendations?
On Tue, 2016-09-13 at 08:12 -0400, Joe Quinn wrote: > > On 9/13/2016 1:55 AM, John Hardin wrote: > > > > > > On Mon, 12 Sep 2016, thomas cameron wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Keep the tips coming, I appreciate learning from you! > > Here's another: there's some anecdotal evidence that publishing > > your > > own SPF record reduces the likelihood you'll be joe-jobbed. I'm > > not > > sure whether that's still the case, but it did help a few years > > back. > > > > > Well, if the choice is between having an SPF record and not having > an SPF record, I choose having it every time. ;) > Agreed. Before I set up an SPF record for my domain, I was getting a lot of bounced spam (spam sent to $third_party and rejected due to a nonexistent user and coming to me because my domain was forged as the sender). After I set up an SPF record this type of spam vanished almost overnight. However, its important to validate your SPF record, once you've set it up, and to to use the '-all' rather than '~all'. I use http://www.kitterman.com/spf/validate.html as my validation tool. https://dmarcian.com/spf-survey/ is OK too, despite an annoying CAPTCHA before you can use it. Martin
Re: Tuning recommendations?
On 9/13/2016 1:55 AM, John Hardin wrote: On Mon, 12 Sep 2016, thomas cameron wrote: Keep the tips coming, I appreciate learning from you! Here's another: there's some anecdotal evidence that publishing your own SPF record reduces the likelihood you'll be joe-jobbed. I'm not sure whether that's still the case, but it did help a few years back. Well, if the choice is between having an SPF record and not having an SPF record, I choose having it every time. ;)
Re: Tuning recommendations?
On Mon, 12 Sep 2016, thomas cameron wrote: Keep the tips coming, I appreciate learning from you! Here's another: there's some anecdotal evidence that publishing your own SPF record reduces the likelihood you'll be joe-jobbed. I'm not sure whether that's still the case, but it did help a few years back. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- We have to realize that people who run the government can and do change. Our society and laws must assume that bad people - criminals even - will run the government, at least part of the time. -- John Gilmore --- 5 days until the 229th anniversary of the signing of the U.S. Constitution
Re: Tuning recommendations?
On 09/12/2016 02:32 PM, John Hardin wrote:
> On Mon, 12 Sep 2016, thomas cameron wrote:
>
>> On 09/12/2016 01:06 PM, John Hardin wrote:
>>> On Mon, 12 Sep 2016, thomas cameron wrote:
>>>
>>>
>>> Make sure you have a local recursing (**NOT** forwarding) DNS server
>>> that your MTA and SA are configured to use. Reason: if you're forwarding
>>> your MTA DNS requests to your ISP's DNS server, the aggregated traffic
>>> of you plus all the other ISP clients can exceed the various DNSBL and
>>> URIBL free-usage limits, rendering those tools useless.
>>
>> [root@mail-west ~]# grep recurs /etc/named.conf
>> allow-recursion { 127.0.0.1; };
>>
>>> A clear indicator this is happening: URIBL_BLOCKED hits.
>>
>> I see "URIBL_BLACK Contains an URL listed in the URIBL blacklist" in the
>> headers of many of the messages that got through. Is that what you mean?
>
> No. URIBL_BLACK indicates your URIBL queries are succeeding, that's a
> hit. URIBL_BLOCKED means "request blocked", probably due to exceeding
> the limits.
OK, thanks.
>>> Train up your Bayes using hand-vetted spam *and* ham, at least 200 of
>>> each. Using autolearn initially can be problematic, so disable that
>>> until SA is doing a fairly good job using hand-trained Bayes. Then you
>>> can let autolearn keep it up-to-date if you like, and continue to
>>> capture and manually train any persistent misses or near-misses.
>>> Generally the more you feed Bayes the better it performs, but it must be
>>> accurately classified. If you feeed garbage to Bayes, you'll get garbage
>>> results.
>>
>> Good to know, thanks. I am running sa-learn --ham --mbox $MAIL now. I've
>> been running sa-learn --spam against the spam messages I've moved to my
>> spam folder, but forgot to teach it about ham.
>
> It's a really bad idea to train your inbox as ham. There may be stuff
> (specifically, FNs) in there you haven't seen yet or haven't removed.
> Keep a separate train-as-ham folder that you manually populate after
> actually looking at the messages, just like you're keeping a
> train-as-spam folder.
>
> You might want to wipe and retrain from scratch after setting that up,
> especially if you're seeing low BAYES score hits on spams and FPs.
I can certainly do that.
> Are you seeing any BAYES rule hits at all yet?
Yes, including a fair number of BAYES_999 and BAYES_99, which I would
have thought would have more weight than it apparently does. I know I
can custom score in local.cf, but I've always read that I should avoid
changing default scores unless I *really* know what I'm doing. Clearly,
I'm not there yet.
>>> Keep hand-classified Bayes corpora around in case you ever need to wipe
>>> and retrain from scratch.
>>
>> OK.
>>
>>> Ensure you're training Bayes as the user that SA is running under.
>>> Training the wrong Bayes database is a common cause of problems.
>>
>> It's a small server, so I'm doing this via procmail and spamc.
>> Everything runs in the context of the individual users. I need to run
>> sa-learn --ham as each user against their inboxes, I guess. I can add
>> cron jobs for each user to do that.
>
> You might also consider running a shared/global Bayes, if all your
> users' mail streams are fairly similar w/r/t "what is ham?" There should
> be instructions in the SA wiki for setting up shared/global Bayes.
I used to run SA via spamass-milter, and use a single Bayes DB under
user spam, but when I downsized my server, the hassle of feeding that
shared DB became bigger than the benefit. I will revisit that conclusion.
>>> Consider doing some MTA-level DNSBL checks. The Zen DNSBL is
>>> well-regarded. If you're using Postfix then there are some emails from
>>> Reindl Harald on this list regarding weighted DNSBL scoring that you may
>>> find useful. You'll have to search the archives to find those.
>>
>> I'm using sendmail, and I have these checks on:
>>
>> FEATURE(`dnsbl',`in.dnsbl.org ')dnl
>> FEATURE(`dnsbl',`sbl-xbl.spamhaus.org')dnl
>> FEATURE(`dnsbl',`cbl.abuseat.org')dnl
>>
>> I will add FEATURE(`dnsbl',`zen.spamhaus.org')dnl to it.
>
> Zen incorporates a couple of the ones you're already using, don't double
> up.
OK, good to know.
>>> There are some other MTA-level checks you can perform, like greet pause
>>> and HELO validation (e.g. reject if the HELO has no dots).
>>
>> Like this? http://www.harker.com/sendmail/checkhelo.html
>
> Here's greet pause:
>
> FEATURE(`greet_pause',3000)dnl
This is very helpful, thanks!
> I use milter-regex for HELO checks, it's a lot easier than hacking
> sendmail.cf (pokes sigmonster). You might consider milter-regex and take
> a look at this:
>
> http://www.impsec.org/~jhardin/antispam/milter-regex.conf
>
> There are some things in there specific to a very small install, for
> example I expect all mail legitimately from my domain to be coming in
> from localhost so a HELO in my domain on the real IP is always bogus.
> Don't just adopt that config blindly.
>
>>> Consider greylisting.
>>
>> I
Re: Tuning recommendations?
On Mon, 12 Sep 2016, Ian Zimmerman wrote: On 2016-09-12 11:06, John Hardin wrote: Consider greylisting. This will depend on the OP business needs, Right, which is why I said "consider". -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Riff: Torg, you traded our magic beans for a _cow_? Torg: It's a _magic_ cow! It's full of steaks! Riff: Whoa!-- Sluggy 04/28/2002 --- 5 days until the 229th anniversary of the signing of the U.S. Constitution
Re: Tuning recommendations?
On Mon, 12 Sep 2016, thomas cameron wrote:
On 09/12/2016 01:06 PM, John Hardin wrote:
On Mon, 12 Sep 2016, thomas cameron wrote:
Make sure you have a local recursing (**NOT** forwarding) DNS server
that your MTA and SA are configured to use. Reason: if you're forwarding
your MTA DNS requests to your ISP's DNS server, the aggregated traffic
of you plus all the other ISP clients can exceed the various DNSBL and
URIBL free-usage limits, rendering those tools useless.
[root@mail-west ~]# grep recurs /etc/named.conf
allow-recursion { 127.0.0.1; };
A clear indicator this is happening: URIBL_BLOCKED hits.
I see "URIBL_BLACK Contains an URL listed in the URIBL blacklist" in the
headers of many of the messages that got through. Is that what you mean?
No. URIBL_BLACK indicates your URIBL queries are succeeding, that's a hit.
URIBL_BLOCKED means "request blocked", probably due to exceeding the
limits.
Train up your Bayes using hand-vetted spam *and* ham, at least 200 of
each. Using autolearn initially can be problematic, so disable that
until SA is doing a fairly good job using hand-trained Bayes. Then you
can let autolearn keep it up-to-date if you like, and continue to
capture and manually train any persistent misses or near-misses.
Generally the more you feed Bayes the better it performs, but it must be
accurately classified. If you feeed garbage to Bayes, you'll get garbage
results.
Good to know, thanks. I am running sa-learn --ham --mbox $MAIL now. I've
been running sa-learn --spam against the spam messages I've moved to my
spam folder, but forgot to teach it about ham.
It's a really bad idea to train your inbox as ham. There may be stuff
(specifically, FNs) in there you haven't seen yet or haven't removed. Keep
a separate train-as-ham folder that you manually populate after actually
looking at the messages, just like you're keeping a train-as-spam folder.
You might want to wipe and retrain from scratch after setting that up,
especially if you're seeing low BAYES score hits on spams and FPs.
Are you seeing any BAYES rule hits at all yet?
Keep hand-classified Bayes corpora around in case you ever need to wipe
and retrain from scratch.
OK.
Ensure you're training Bayes as the user that SA is running under.
Training the wrong Bayes database is a common cause of problems.
It's a small server, so I'm doing this via procmail and spamc.
Everything runs in the context of the individual users. I need to run
sa-learn --ham as each user against their inboxes, I guess. I can add
cron jobs for each user to do that.
You might also consider running a shared/global Bayes, if all your users'
mail streams are fairly similar w/r/t "what is ham?" There should be
instructions in the SA wiki for setting up shared/global Bayes.
Consider doing some MTA-level DNSBL checks. The Zen DNSBL is
well-regarded. If you're using Postfix then there are some emails from
Reindl Harald on this list regarding weighted DNSBL scoring that you may
find useful. You'll have to search the archives to find those.
I'm using sendmail, and I have these checks on:
FEATURE(`dnsbl',`in.dnsbl.org ')dnl
FEATURE(`dnsbl',`sbl-xbl.spamhaus.org')dnl
FEATURE(`dnsbl',`cbl.abuseat.org')dnl
I will add FEATURE(`dnsbl',`zen.spamhaus.org')dnl to it.
Zen incorporates a couple of the ones you're already using, don't double
up.
There are some other MTA-level checks you can perform, like greet pause
and HELO validation (e.g. reject if the HELO has no dots).
Like this? http://www.harker.com/sendmail/checkhelo.html
Here's greet pause:
FEATURE(`greet_pause',3000)dnl
I use milter-regex for HELO checks, it's a lot easier than hacking
sendmail.cf (pokes sigmonster). You might consider milter-regex and take a
look at this:
http://www.impsec.org/~jhardin/antispam/milter-regex.conf
There are some things in there specific to a very small install, for
example I expect all mail legitimately from my domain to be coming in from
localhost so a HELO in my domain on the real IP is always bogus. Don't
just adopt that config blindly.
Consider greylisting.
I am using milter-greylist, and it is very helpful. A lot of these
messages are actually skipping greylisting, though!
Greylisting isn't a panacaea. There *are* spambots who retry, and spammers
who send through real MTAs. It helps reduce the cheap anklebiters, though.
X-Greylist: Sender passed SPF test, not delayed by
milter-greylist-4.5.16 (XXX [XXX.XXX.XXX.XXX]); Mon, 12 Sep 2016
18:11:18 + (UTC)
You might not want to bypass greylisting based on SPF. If the sender is
using a spam domain, they could easily set up "accept from 0.0.0.0/0" in
that domain's SPF.
Keep the tips coming, I appreciate learning from you!
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
--
Re: Tuning recommendations?
On 2016-09-12 11:06, John Hardin wrote: > Consider greylisting. This will depend on the OP business needs, but a poor man's version of graylisting is to just delay deliveries unconditionally for a couple of minutes. (I use 2 minutes). If you do this in the MTA make sure the delay is before SA in the processing pipeline. This will allow time for RBLs and collaborative claeringhouses like Razor to see the spam before SA on your system checks it. I do this because I don't control the MX host, and thus I have no information about the connecting IP address, except by inspecting the headers, which feels "wrong" do to in the MTA. -- Please *no* private Cc: on mailing lists and newsgroups Why does the arrow on Hillary signs point to the right?
Re: Tuning recommendations?
On 09/12/2016 01:40 PM, li...@rhsoft.net wrote:
>
>
> Am 12.09.2016 um 20:34 schrieb thomas cameron:
>> On 09/12/2016 01:06 PM, John Hardin wrote:
>>> On Mon, 12 Sep 2016, thomas cameron wrote:
>>>
>>> Make sure you have a local recursing (**NOT** forwarding) DNS server
>>> that your MTA and SA are configured to use. Reason: if you're forwarding
>>> your MTA DNS requests to your ISP's DNS server, the aggregated traffic
>>> of you plus all the other ISP clients can exceed the various DNSBL and
>>> URIBL free-usage limits, rendering those tools useless.
>>
>> [root@mail-west ~]# grep recurs /etc/named.conf
>> allow-recursion { 127.0.0.1; };
>>
>>> A clear
>>> indicator this is happening: URIBL_BLOCKED hits.
>>
>> I see "URIBL_BLACK Contains an URL listed in the URIBL blacklist" in the
>> headers of many of the messages that got through. Is that what you mean?
>
> no that means the message had a hit and so it seems your are using only
> 127.0.0.1 as nameserver and that nameserver does *not* forwarding
Ah, OK. I actually just changed my resolv.conf to do DNS lookups from
127.0.0.1. Before, it was using public DNS servers.
> it would be really helpful if you just post the full report-header of
> such a message, otherwise you are at your own
Sure, I didn't want to bomb the list with crud, sorry. Here's the header
of the latest spam to slip through.
Return-Path:
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
mail-west.camerontech.com
X-Spam-Level: ***
X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99,DIET_1,
HTML_FONT_LOW_CONTRAST,HTML_IMAGE_RATIO_02,HTML_MESSAGE,SPF_PASS,
T_HTML_TAG_BALANCE_CENTER,T_REMOTE_IMAGE autolearn=no autolearn_force=no
version=3.4.0
Received: from substantiate.westbegalssc.com
(91-239-125-145.thinkdedicated.com [91.239.125.145] (may be forged))
by mail-west.camerontech.com (8.14.7/8.14.7) with ESMTP id
u8CIX42I002741
for ; Mon, 12 Sep 2016 18:33:29 GMT
To:
Date: Mon, 12 Sep 2016 13:33:01 -0500
From: "Paula Fields"
Reply-To:
Message-ID:
Subject: Great Science: Shred lbs while you sit in your cublicle.
Mime-Version: 1
Content-Type: multipart/alternative;
boundary="897htfNCA6B4duDQ193OAjlzRH078d7wF"
X-Greylist: Sender passed SPF test, not delayed by
milter-greylist-4.5.16 (mail-west.camerontech.com [104.131.155.84]);
Mon, 12 Sep 2016 18:33:36 + (UTC)
Re: Tuning recommendations?
Am 12.09.2016 um 20:34 schrieb thomas cameron:
On 09/12/2016 01:06 PM, John Hardin wrote:
On Mon, 12 Sep 2016, thomas cameron wrote:
Make sure you have a local recursing (**NOT** forwarding) DNS server
that your MTA and SA are configured to use. Reason: if you're forwarding
your MTA DNS requests to your ISP's DNS server, the aggregated traffic
of you plus all the other ISP clients can exceed the various DNSBL and
URIBL free-usage limits, rendering those tools useless.
[root@mail-west ~]# grep recurs /etc/named.conf
allow-recursion { 127.0.0.1; };
A clear
indicator this is happening: URIBL_BLOCKED hits.
I see "URIBL_BLACK Contains an URL listed in the URIBL blacklist" in the
headers of many of the messages that got through. Is that what you mean?
no that means the message had a hit and so it seems your are using only
127.0.0.1 as nameserver and that nameserver does *not* forwarding
it would be really helpful if you just post the full report-header of
such a message, otherwise you are at your own
Re: Tuning recommendations?
On 09/12/2016 01:06 PM, John Hardin wrote:
> On Mon, 12 Sep 2016, thomas cameron wrote:
>
>
> Make sure you have a local recursing (**NOT** forwarding) DNS server
> that your MTA and SA are configured to use. Reason: if you're forwarding
> your MTA DNS requests to your ISP's DNS server, the aggregated traffic
> of you plus all the other ISP clients can exceed the various DNSBL and
> URIBL free-usage limits, rendering those tools useless.
[root@mail-west ~]# grep recurs /etc/named.conf
allow-recursion { 127.0.0.1; };
> A clear
> indicator this is happening: URIBL_BLOCKED hits.
I see "URIBL_BLACK Contains an URL listed in the URIBL blacklist" in the
headers of many of the messages that got through. Is that what you mean?
> Train up your Bayes using hand-vetted spam *and* ham, at least 200 of
> each. Using autolearn initially can be problematic, so disable that
> until SA is doing a fairly good job using hand-trained Bayes. Then you
> can let autolearn keep it up-to-date if you like, and continue to
> capture and manually train any persistent misses or near-misses.
> Generally the more you feed Bayes the better it performs, but it must be
> accurately classified. If you feeed garbage to Bayes, you'll get garbage
> results.
Good to know, thanks. I am running sa-learn --ham --mbox $MAIL now. I've
been running sa-learn --spam against the spam messages I've moved to my
spam folder, but forgot to teach it about ham.
> Keep hand-classified Bayes corpora around in case you ever need to wipe
> and retrain from scratch.
OK.
> Ensure you're training Bayes as the user that SA is running under.
> Training the wrong Bayes database is a common cause of problems.
It's a small server, so I'm doing this via procmail and spamc.
Everything runs in the context of the individual users. I need to run
sa-learn --ham as each user against their inboxes, I guess. I can add
cron jobs for each user to do that.
> Consider doing some MTA-level DNSBL checks. The Zen DNSBL is
> well-regarded. If you're using Postfix then there are some emails from
> Reindl Harald on this list regarding weighted DNSBL scoring that you may
> find useful. You'll have to search the archives to find those.
I'm using sendmail, and I have these checks on:
FEATURE(`dnsbl',`in.dnsbl.org ')dnl
FEATURE(`dnsbl',`sbl-xbl.spamhaus.org')dnl
FEATURE(`dnsbl',`cbl.abuseat.org')dnl
I will add FEATURE(`dnsbl',`zen.spamhaus.org')dnl to it.
> There are some other MTA-level checks you can perform, like greet pause
> and HELO validation (e.g. reject if the HELO has no dots).
Like this? http://www.harker.com/sendmail/checkhelo.html
> Consider greylisting.
I am using milter-greylist, and it is very helpful. A lot of these
messages are actually skipping greylisting, though!
X-Greylist: Sender passed SPF test, not delayed by
milter-greylist-4.5.16 (XXX [XXX.XXX.XXX.XXX]); Mon, 12 Sep 2016
18:11:18 + (UTC)
Keep the tips coming, I appreciate learning from you!
Thomas
Re: Tuning recommendations?
On 09/12/2016 11:50 AM, Jesse Norell wrote: > On Mon, 2016-09-12 at 11:40 -0500, thomas cameron wrote: >> Any other tips welcome! > > You didn't mention any details of your setup, but some very basic tips > are to run a current version of spamassassin and run sa-update > regularly. You might verify (or confirm) the user you train bayes with > is the same user that the scanner runs as. > Sorry, forgot to mention that I'm running Sendmail and not postfix. It's a small server, only serving a couple of users, so I am just using ~/.procmailrc: [root@mail-west ~]# cat /home/thomas.cameron/.procmailrc MAILDIR=$HOME/mail LOGFILE=$MAILDIR/procmail.log :0fw: spamassassin.lock * < 1024000 | spamc :0 * ^X-Spam-Flag:.*YES spam
Re: Tuning recommendations?
On Mon, 12 Sep 2016, thomas cameron wrote: Howdy, all - I rolled a new mail server out for my small business, and I've got a pretty vanilla SA setup. It's just not doing a very good job of catching spam. I'm getting a TON of "Amazon gift card" and "female hair loss" and "work from home" spam in my inbox. I feel like if I see one more e-mail about Blake Shelton, I'm gonna scream. Is there a good tuning/config page anywhere? Last time I messed with SA, I used www.spamtips.org. It's pretty old, though, so I imagine there are better ways. I also used to use rules du jour, but I read that that's old and not maintained any more. What do you guys recommend for tuning? It's been so long since I really dove deep into SA, you can just assume I'm starting from scratch. Make sure you have a local recursing (**NOT** forwarding) DNS server that your MTA and SA are configured to use. Reason: if you're forwarding your MTA DNS requests to your ISP's DNS server, the aggregated traffic of you plus all the other ISP clients can exceed the various DNSBL and URIBL free-usage limits, rendering those tools useless. A clear indicator this is happening: URIBL_BLOCKED hits. Train up your Bayes using hand-vetted spam *and* ham, at least 200 of each. Using autolearn initially can be problematic, so disable that until SA is doing a fairly good job using hand-trained Bayes. Then you can let autolearn keep it up-to-date if you like, and continue to capture and manually train any persistent misses or near-misses. Generally the more you feed Bayes the better it performs, but it must be accurately classified. If you feeed garbage to Bayes, you'll get garbage results. Keep hand-classified Bayes corpora around in case you ever need to wipe and retrain from scratch. Ensure you're training Bayes as the user that SA is running under. Training the wrong Bayes database is a common cause of problems. Consider doing some MTA-level DNSBL checks. The Zen DNSBL is well-regarded. If you're using Postfix then there are some emails from Reindl Harald on this list regarding weighted DNSBL scoring that you may find useful. You'll have to search the archives to find those. There are some other MTA-level checks you can perform, like greet pause and HELO validation (e.g. reject if the HELO has no dots). Consider greylisting. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Windows and its users got mentioned at home today, after my wife the psych major brought up Seligman's theory of "learned helplessness." -- Dan Birchall in a.s.r --- 5 days until the 229th anniversary of the signing of the U.S. Constitution
Re: Tuning recommendations?
On 09/12/2016 11:50 AM, Jesse Norell wrote: > On Mon, 2016-09-12 at 11:40 -0500, thomas cameron wrote: >> Any other tips welcome! > > You didn't mention any details of your setup, but some very basic tips > are to run a current version of spamassassin and run sa-update > regularly. You might verify (or confirm) the user you train bayes with > is the same user that the scanner runs as. Fair point, sorry. I'm running RHEL 7, using spamassassin-3.4.0-2.el7.x86_64 The only real changes I've made are in local.cf: [root@mail-west ~]# cat /etc/mail/spamassassin/local.cf # These values can be overridden by editing ~/.spamassassin/user_prefs.cf # (see spamassassin(1) for details) # These should be safe assumptions and allow for simple visual sifting # without risking lost emails. required_hits 5 report_safe 0 rewrite_header Subject ***SPAM(_SCORE_)*** use_bayes 1 bayes_auto_learn 1 bayes_ignore_header X-Bogosity bayes_ignore_header X-Spam-Flag bayes_ignore_header X-Spam-Status # per http://www.spamtips.org/2011/02/smfbracketsto-rule.html header SMF_BRACKETS_TO To:raw =~ /<<[^<>]+>>/ describe SMF_BRACKETS_TO Double-brackets around To header address score SMF_BRACKETS_TO 1.5 # per http://www.spamtips.org/2011/01/disable-dnsfromahblrhsbl.html score DNS_FROM_AHBL_RHSBL 0 # per http://www.spamtips.org/2011/01/disable-rfc-ignorantorg-rules.html # Add these lines to your local.cf then restart your spamd score __RFC_IGNORANT_ENVFROM0 score DNS_FROM_RFC_DSN 0 score DNS_FROM_RFC_BOGUSMX 0 score __DNS_FROM_RFC_POST 0 score __DNS_FROM_RFC_ABUSE 0 score __DNS_FROM_RFC_WHOIS 0 Other than that, it's bone stock.
Re: Tuning recommendations?
Until you have a trained Bayes ham/spam set you can only really wait and train. And ensure you take regular updates ==John On Mon, 12 Sep 2016, thomas cameron wrote: Howdy, all - I rolled a new mail server out for my small business, and I've got a pretty vanilla SA setup. It's just not doing a very good job of catching spam. I'm getting a TON of "Amazon gift card" and "female hair loss" and "work from home" spam in my inbox. I feel like if I see one more e-mail about Blake Shelton, I'm gonna scream. Is there a good tuning/config page anywhere? Last time I messed with SA, I used www.spamtips.org. It's pretty old, though, so I imagine there are better ways. I also used to use rules du jour, but I read that that's old and not maintained any more. What do you guys recommend for tuning? It's been so long since I really dove deep into SA, you can just assume I'm starting from scratch. Many thanks! Thomas
Re: Tuning recommendations?
On Mon, 2016-09-12 at 11:40 -0500, thomas cameron wrote: > Any other tips welcome! You didn't mention any details of your setup, but some very basic tips are to run a current version of spamassassin and run sa-update regularly. You might verify (or confirm) the user you train bayes with is the same user that the scanner runs as. -- Jesse Norell Kentec Communications, Inc. 970-522-8107 - www.kci.net
Re: Tuning recommendations?
On 09/12/2016 10:53 AM, li...@rhsoft.net wrote: > > > Am 12.09.2016 um 17:51 schrieb thomas cameron: >> I rolled a new mail server out for my small business, and I've got a >> pretty vanilla SA setup. It's just not doing a very good job of catching >> spam. I'm getting a TON of "Amazon gift card" and "female hair loss" and >> "work from home" spam in my inbox. I feel like if I see one more e-mail >> about Blake Shelton, I'm gonna scream > > train your bayes proper with enough ham *and* spam and do it with the > user spamassassin runs Yeah, I have a cron job that does that. 0 2 * * * sa-learn --mbox --spam $HOME/mail/spam 1 2 * * * sa-learn --mbox --spam $HOME/mail/super-spam 2 2 * * * sa-learn --mbox --ham $HOME/mail/ham I hesitate to run --ham against my inbox because so much spam is getting through, so I copy a bunch of stuff over to the ham folder and train from there. Any other tips welcome! Thomas
Re: Tuning recommendations?
Am 12.09.2016 um 17:51 schrieb thomas cameron: I rolled a new mail server out for my small business, and I've got a pretty vanilla SA setup. It's just not doing a very good job of catching spam. I'm getting a TON of "Amazon gift card" and "female hair loss" and "work from home" spam in my inbox. I feel like if I see one more e-mail about Blake Shelton, I'm gonna scream train your bayes proper with enough ham *and* spam and do it with the user spamassassin runs
Tuning recommendations?
Howdy, all - I rolled a new mail server out for my small business, and I've got a pretty vanilla SA setup. It's just not doing a very good job of catching spam. I'm getting a TON of "Amazon gift card" and "female hair loss" and "work from home" spam in my inbox. I feel like if I see one more e-mail about Blake Shelton, I'm gonna scream. Is there a good tuning/config page anywhere? Last time I messed with SA, I used www.spamtips.org. It's pretty old, though, so I imagine there are better ways. I also used to use rules du jour, but I read that that's old and not maintained any more. What do you guys recommend for tuning? It's been so long since I really dove deep into SA, you can just assume I'm starting from scratch. Many thanks! Thomas
