You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Robert S <ro...@gmail.com> on 2013/06/22 04:41:28 UTC
False negatives/positives on debian
I am running spamassassin_3.3.2-5 on debian Wheezy on a small business
server (x86). I am getting numerous complaints about mail being falely
categorised as spam/ham. I also use version 3.3.2 on my home server using
gentoo (amd64) and don't have these problems. I have removed all
customisations and have reinstalled spamassassin on my debian machine.
There still seem to be problems - here's an example using the provided
sample files. Can anybody help?
This message seems to get blocked in a lot of blocklists (which also seem
to happen to my users' messages).
Options for SA are:
# ps ax |grep spam
22408 ? Ss 0:02 /usr/sbin/spamd --create-prefs --max-children 5
--helper-home-dir -d --pidfile=/var/run/spamd.pid
/etc/procmailrc includes this:
* < 256000
| /usr/bin/spamc
$ spamc < sample-nonspam.txt
Received: from localhost by debian.myserver.net.au
with SpamAssassin (version 3.3.2);
Sat, 22 Jun 2013 12:06:12 +1000
From: Keith Dawson <da...@world.std.com>
To: tbtf@world.std.com
Subject: TBTF ping for 2001-04-20: Reviving
Date: Fri, 20 Apr 2001 16:59:58 -0400
Message-Id: <v0421010eb70653b14e06@[208.192.102.193]>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
debian.myserver.net.au
X-Spam-Flag: YES
X-Spam-Level: ********
X-Spam-Status: Yes, score=8.5 required=5.0 tests=RP_MATCHES_RCVD,SAGREY,
URIBL_AB_SURBL,URIBL_BLOCKED,URIBL_GREY,URIBL_MW_SURBL,URIBL_PH_SURBL,
URIBL_RED,URIBL_WS_SURBL autolearn=no version=3.3.2
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_51C50694.B9FC2455"
This is a multi-part message in MIME format.
------------=_51C50694.B9FC2455
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Spam detection software, running on the system "debian.myserver.net.au", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: -----BEGIN PGP SIGNED MESSAGE----- TBTF ping for
2001-04-20:
Reviving T a s t y B i t s f r o m t h e T e c h n o l o g y F r o n t
[...]
Content analysis details: (8.5 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-1.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 URIBL_RED Contains an URL listed in the URIBL redlist
[URIs: tbtf.com]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: tbtf.com]
1.1 URIBL_GREY Contains an URL listed in the URIBL greylist
[URIs: tbtf.com]
0.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
[URIs: tbtf.com]
4.5 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
[URIs: tbtf.com]
1.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
[URIs: tbtf.com]
1.7 URIBL_MW_SURBL Contains a Malware Domain or IP listed in the
MW SURBL
blocklist
[URIs: tbtf.com]
1.0 SAGREY Adds 1.0 to spam from first-time senders
------------=_51C50694.B9FC2455
Content-Type: message/rfc822; x-spam-type=original
Content-Description: original message before SpamAssassin
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Return-Path: <tb...@world.std.com>
Delivered-To: foo@foo.com
Received: from europe.std.com (europe.std.com [199.172.62.20])
by mail.netnoteinc.com (Postfix) with ESMTP id 392E1114061
for <fo...@foo.com>; Fri, 20 Apr 2001 21:34:46 +0000 (Eire)
Received: (from daemon@localhost)
by europe.std.com (8.9.3/8.9.3) id RAA09630
for tbtf-outgoing; Fri, 20 Apr 2001 17:31:18 -0400 (EDT)
Received: from sgi04-e.std.com (sgi04-e.std.com [199.172.62.134])
by europe.std.com (8.9.3/8.9.3) with ESMTP id RAA08749
for <tb...@facteur.std.com>; Fri, 20 Apr 2001 17:24:31 -0400 (EDT)
Received: from world.std.com (world-f.std.com [199.172.62.5])
by sgi04-e.std.com (8.9.3/8.9.3) with ESMTP id RAA8278330
for <tb...@facteur.std.com>; Fri, 20 Apr 2001 17:24:31 -0400 (EDT)
Received: (from dawson@localhost)
by world.std.com (8.9.3/8.9.3) id RAA26781
for tbtf@world.std.com; Fri, 20 Apr 2001 17:24:31 -0400 (EDT)
Received: from sgi04-e.std.com (sgi04-e.std.com [199.172.62.134])
by europe.std.com (8.9.3/8.9.3) with ESMTP id RAA07541
for <tb...@facteur.std.com>; Fri, 20 Apr 2001 17:12:06 -0400 (EDT)
Received: from world.std.com (world-f.std.com [199.172.62.5])
by sgi04-e.std.com (8.9.3/8.9.3) with ESMTP id RAA8416421
for <tb...@facteur.std.com>; Fri, 20 Apr 2001 17:12:06 -0400 (EDT)
Received: from [208.192.102.193] (ppp0c199.std.com [208.192.102.199])
by world.std.com (8.9.3/8.9.3) with ESMTP id RAA14226
for <tb...@world.std.com>; Fri, 20 Apr 2001 17:12:04 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <v0421010eb70653b14e06@[208.192.102.193]>
Date: Fri, 20 Apr 2001 16:59:58 -0400
To: tbtf@world.std.com
From: Keith Dawson <da...@world.std.com>
Subject: TBTF ping for 2001-04-20: Reviving
Content-Type: text/plain; charset="us-ascii"
Sender: tbtf-approval@world.std.com
Precedence: list
Reply-To: tbtf-approval@europe.std.com
-----BEGIN PGP SIGNED MESSAGE-----
TBTF ping for 2001-04-20: Reviving
T a s t y B i t s f r o m t h e T e c h n o l o g y F r o n t
Timely news of the bellwethers in computer and communications
technology that will affect electronic commerce -- since 1994
Your Host: Keith Dawson
ISSN: 1524-9948
This issue: < http://tbtf.com/archive/2001-04-20.html >
To comment on this issue, please use this forum at Quick Topic:
< http://www.quicktopic.com/tbtf/H/kQGJR2TXL6H >
________________________________________________________________________
Q u o t e O f T h e M o m e n t
Even organizations that promise "privacy for their customers" rarely
if ever promise "continued privacy for their former customers..."
Once you cancel your account with any business, their promises of
keeping the information about their customers private no longer
apply... you're not a customer any longer.
This is in the large category of business behaviors that individuals
would consider immoral and deceptive -- and businesses know are not
illegal.
-- "_ankh," writing on the XNStalk mailing list
________________________________________________________________________
..TBTF's long hiatus is drawing to a close
Hail subscribers to the TBTF mailing list. Some 2,000 [1] of you
have signed up since the last issue [2] was mailed on 2000-07-20.
This brief note is the first of several I will send to this list to
excise the dead addresses prior to resuming regular publication.
While you time the contractions of the newsletter's rebirth, I in-
vite you to read the TBTF Log [3] and sign up for its separate free
subscription. Send "subscribe" (no quotes) with any subject to
tbtf-log-request@tbtf.com . I mail out collected Log items on Sun-
days.
If you need to stay more immediately on top of breaking stories,
pick up the TBTF Log's syndication file [4] or read an aggregator
that does. Examples are Slashdot's Cheesy Portal [5], Userland [6],
and Sitescooper [7]. If your news obsession runs even deeper and you
own an SMS-capable cell phone or PDA, sign up on TBTF's WebWire-
lessNow portal [8]. A free call will bring you the latest TBTF Log
headline, Jargon Scout [9] find, or Siliconium [10].
Two new columnists have bloomed on TBTF since last summer: Ted By-
field's roving_reporter [11] and Gary Stock's UnBlinking [12]. Late-
ly Byfield has been writing in unmatched depth about ICANN, but the
roving_reporter nym's roots are in commentary at the intersection of
technology and culture. Stock's UnBlinking latches onto topical sub-
jects and pursues them to the ends of the Net. These writers' voices
are compelling and utterly distinctive.
[1] http://tbtf.com/growth.html
[2] http://tbtf.com/archive/2000-07-20.html
[3] http://tbtf.com/blog/
[4] http://tbtf.com/tbtf.rdf
[5] http://www.slashdot.org/cheesyportal.shtml
[6] http://my.userland.com/
[7] http://www.sitescooper.org/
[8] http://tbtf.com/pull-wwn/
[9] http://tbtf.com/jargon-scout.html
[10] http://tbtf.com/siliconia.html
[11] http://tbtf.com/roving_reporter/
[12] http://tbtf.com/unblinking/
________________________________________________________________________
S o u r c e s
> For a complete list of TBTF's email and Web sources, see
http://tbtf.com/sources.html .
________________________________________________________________________
B e n e f a c t o r s
TBTF is free. If you get value from this publication, please visit
the TBTF Benefactors page < http://tbtf.com/the-benefactors.html >
and consider contributing to its upkeep.
________________________________________________________________________
TBTF home and archive at http://tbtf.com/ . To unsubscribe send
the message "unsubscribe" to tbtf-request@tbtf.com. TBTF is Copy-
right 1994-2000 by Keith Dawson, <da...@world.std.com>. Commercial
use prohibited. For non-commercial purposes please forward, post,
and link as you see fit.
_______________________________________________
Keith Dawson dawson@world.std.com
Layer of ash separates morning and evening milk.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQCVAwUBOuCi3WAMawgf2iXRAQHeAQQA3YSePSQ0XzdHZUVskFDkTfpE9XS4fHQs
WaT6a8qLZK9PdNcoz3zggM/Jnjdx6CJqNzxPEtxk9B2DoGll/C/60HWNPN+VujDu
Xav65S0P+Px4knaQcCIeCamQJ7uGcsw+CqMpNbxWYaTYmjAfkbKH1EuLC2VRwdmD
wQmwrDp70v8=
=8hLB
-----END PGP SIGNATURE-----
------------=_51C50694.B9FC2455--
Re: False negatives/positives on debian
Posted by Axb <ax...@gmail.com>.
FTR:
iirc, OpenDNS is also blocked from doing URIBL queries.
the web is full of forum post regarding this so it may be best not to
forward to them as your fallback.
unbound or powerdns-recursor on a separate local box/VM/would be the
safeest choice.
It also spares you from potential third party query manipulation.
On 06/22/2013 01:16 PM, Robert S wrote:
> I've eliminated this problem by using openDNS servers:
>
> # cat /etc/resolv.conf
> domain mydomain.net.au
> search mydomain.net.au
> nameserver 192.168.0.33 #<--- My server IP
> nameserver 208.67.220.220
> nameserver 208.67.222.222
>
> Is this likely to have untoward consequences? I've also looked at using
> unbound - which looks quite straightforward.
>
>
> On Sat, Jun 22, 2013 at 8:57 PM, Benny Pedersen <me...@junc.eu> wrote:
>
>> John Hardin skrev den 2013-06-22 06:45:
>>
>>
>> If you're running dnsmasq locally, you should list it first so that
>>> you take advantage of its local cache and only fall back to direct
>>> queries of your ISP's servers if dnsmasq fails for some reason.
>>>
>>
>> that only hold water if /etc/resolv.conf does not contain options rotate,
>> its not a question of first :)
>>
>>
>> --
>> 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: False negatives/positives on debian
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Sat, 22 Jun 2013, Robert S wrote:
> I've eliminated this problem by using openDNS servers:
>
> # cat /etc/resolv.conf
> domain mydomain.net.au
> search mydomain.net.au
> nameserver 192.168.0.33 #<--- My server IP
> nameserver 208.67.220.220
> nameserver 208.67.222.222
>
> Is this likely to have untoward consequences? I've also looked at using unbound - which looks quite straightforward.
Assuming that your dnsmasq (or other DNS-server) is running on the same
machine as your SA, use the loopback IP addr (127.0.0.1) instead of the
explicit IP addr of your server's ethernet interface.
IE, in your resolv.conf use:
domain mydomain.net.au
search mydomain.net.au
nameserver 127.0.0.1
nameserver 208...stuff
nameserver some.other.server..
This is for several reasons:
1) ease of maintenance, always works, even after changing your
server's IP addr for what ever reason.
2) security, you can then change your DNS server to only listen
for queries on the loopback addr and make it more immune to
remote attacks.
3) performance, DNS queries work best if they fit in a single
UDP packet. The loopback has a larger MTU than standard
enet interfaces, so more likely to handle large DNS queries
w/o fragmentation or TCP fallback.
Now if you're also using that DNS server to provide DNS service
for other client machine on your local LAN then you cannot do
the change in (2) (make DNS server only listen to loopback) but
it still simplifies configuration. (allow all queries on lo0 and
selected queries on eth*).
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: False negatives/positives on debian
Posted by John Hardin <jh...@impsec.org>.
On Sat, 22 Jun 2013, Robert S wrote:
> I've eliminated this problem by using openDNS servers:
>
> Is this likely to have untoward consequences?
Yes. OpenDNS is potentially aggregating *more* traffic than your ISP
does...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Maxim XXXVII: There is no 'overkill.' There is only 'open fire' and
'time to reload.'
-----------------------------------------------------------------------
387 days since the first successful private support mission to ISS (SpaceX)
Re: False negatives/positives on debian
Posted by Benny Pedersen <me...@junc.eu>.
Karsten Bräckelmann skrev den 2013-06-22 23:18:
> I'd argue the evidence provided in this thread suggests to stick to
> the
> first nameserver currently listed in your resolv.conf -- your own.
how are you comming to that conclusion ? :)
one nameserver in resolv.conf, no more no less, if more then one
nameserver in resolv.conf one must remember to add options rotate, else
only first listed nameserver is used, but here the point is to use own
dns resolver that is not depending on other users abuse of shared dns
server, one more point ?, well if your dns queryes is blocked then the
domains you try to get rr from cant spam you, since there dns blocking
block back to them self
after 15 years i still see this happend, and can only say if you want
to block continue, but dont ask me of unblocking when dns is blocked
from my own ip, basicly dns should not being used with forward at all,
forwards is just something dhcp clients does in lan, not in generic isps
setup, dhcp clients is exception here
--
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: False negatives/positives on debian
Posted by Benny Pedersen <me...@junc.eu>.
Robert S skrev den 2013-06-23 00:06:
> Hi.
>
> Just to recap - at the moment I'm running dnsmasq on my local server.
> My resolv.conf now looks like this:
>
> domain mydomain.com.au
> search mydomain.com.au
> nameserver 127.0.0.1
> nameserver 208.67.220.220 # OpenDNS
> nameserver 208.67.222.222 # OpenDNS
>
> Things have been working OK on this setup. This should always use my
> local NS first. Dnsmasq reads its config from the two OpenDNS
> servers
> in this file - here is the log message when it starts:
>
> Jun 23 07:55:37 mydomain dnsmasq[25455]: ignoring nameserver
> 127.0.0.1
> - local interface
> Jun 23 07:55:37 mydomain dnsmasq[25455]: read /etc/hosts - 2
> addresses
> /etc/resolv.conf:
> search foo.example.org
> nameserver 127.0.0.1
>
> /etc/dnsmasq.conf:
> domain-needed
> bogus-priv
> filterwin2k
> server=opendns.ns.ip1
> server=opendns.ns.ip2
> domain=foo.example.org
> local-ttl=86400
its riski to set ttl to high, 24 hours is overkill, but less then 300
is pointless
if its still not working post you own config
>
> On Sun, Jun 23, 2013 at 7:44 AM, Karsten Bräckelmann
> <gu...@rudersport.de> wrote:
>> On Sat, 2013-06-22 at 22:34 +0100, RW wrote:
>>> On Sat, 22 Jun 2013 23:18:24 +0200 Karsten Bräckelmann wrote:
>>>
>>> > > If these things are true then the last question is - is it safe
>>> to
>>> > > use OpenDNS IP addresses in my resolv.conf (and hence the
>>> remainder
>>> > > of my small network) or should I stick to the addresses
>>> provided by
>>> > > my ISP?
>>> >
>>> > I'd argue the evidence provided in this thread suggests to stick
>>> to
>>> > the first nameserver currently listed in your resolv.conf -- your
>>> own.
>>>
>>> Except that it shouldn't be dnsmasq, which is just a cache.
>>
>> True, preferably it shouldn't. It may be, though, if it forwards to
>> a
>> resolving DNS that easily flies below the radar and doesn't get
>> blocked
>> for abuse by a DNSxL.
>>
>> I don't recall if the OP is running dnsmasq on his local DNS.
>>
>> However, when he dropped his ISP's nameservers and his local one
>> became
>> the first listed, it started to work. So his local DNS seems not to
>> forward to the same nameservers he originally showed.
>>
>>
>> --
>> 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;i<l;i++){
>> i%8? c<<=1:
>> (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){
>> putchar(t[s]);h=m;s=0; }}}
>>
--
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: False negatives/positives on debian
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2013-06-23 at 08:06 +1000, Robert S wrote:
> Just to recap - at the moment I'm running dnsmasq on my local server.
> My resolv.conf now looks like this:
>
> domain mydomain.com.au
> search mydomain.com.au
> nameserver 127.0.0.1
> nameserver 208.67.220.220 # OpenDNS
> nameserver 208.67.222.222 # OpenDNS
>
> Things have been working OK on this setup. This should always use my
> local NS first. Dnsmasq reads its config from the two OpenDNS servers
> in this file - here is the log message when it starts:
I've never used dnsmasq, though a quick search seems to confirm it uses
the nameservers in resolv.conf by default.
(BTW, in your previous conf paste, your "local server" was 192.168.0.33,
which has a rather different connotation than 127/8 -- "other machine in
LAN" and "localhost" respectively.)
OpenDNS indeed does not seem to be blocked by URIBL, querying for the
permanent testpoint. Moreover, it is almost impossible to find issues
regarding OpenDNS and URIBL, SURBL, Spamhaus and friends after 2009.
Are the interwebs broken, or does OpenDNS pay for the non-free data-feed
subscription? Couldn't confirm this, either.
--
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: False negatives/positives on debian
Posted by Robert S <ro...@gmail.com>.
Hi.
Just to recap - at the moment I'm running dnsmasq on my local server.
My resolv.conf now looks like this:
domain mydomain.com.au
search mydomain.com.au
nameserver 127.0.0.1
nameserver 208.67.220.220 # OpenDNS
nameserver 208.67.222.222 # OpenDNS
Things have been working OK on this setup. This should always use my
local NS first. Dnsmasq reads its config from the two OpenDNS servers
in this file - here is the log message when it starts:
Jun 23 07:55:37 mydomain dnsmasq[25455]: ignoring nameserver 127.0.0.1
- local interface
Jun 23 07:55:37 mydomain dnsmasq[25455]: read /etc/hosts - 2 addresses
On Sun, Jun 23, 2013 at 7:44 AM, Karsten Bräckelmann
<gu...@rudersport.de> wrote:
> On Sat, 2013-06-22 at 22:34 +0100, RW wrote:
>> On Sat, 22 Jun 2013 23:18:24 +0200 Karsten Bräckelmann wrote:
>>
>> > > If these things are true then the last question is - is it safe to
>> > > use OpenDNS IP addresses in my resolv.conf (and hence the remainder
>> > > of my small network) or should I stick to the addresses provided by
>> > > my ISP?
>> >
>> > I'd argue the evidence provided in this thread suggests to stick to
>> > the first nameserver currently listed in your resolv.conf -- your own.
>>
>> Except that it shouldn't be dnsmasq, which is just a cache.
>
> True, preferably it shouldn't. It may be, though, if it forwards to a
> resolving DNS that easily flies below the radar and doesn't get blocked
> for abuse by a DNSxL.
>
> I don't recall if the OP is running dnsmasq on his local DNS.
>
> However, when he dropped his ISP's nameservers and his local one became
> the first listed, it started to work. So his local DNS seems not to
> forward to the same nameservers he originally showed.
>
>
> --
> 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;i<l;i++){ i%8? c<<=1:
> (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
>
Re: False negatives/positives on debian
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sat, 2013-06-22 at 22:34 +0100, RW wrote:
> On Sat, 22 Jun 2013 23:18:24 +0200 Karsten Bräckelmann wrote:
>
> > > If these things are true then the last question is - is it safe to
> > > use OpenDNS IP addresses in my resolv.conf (and hence the remainder
> > > of my small network) or should I stick to the addresses provided by
> > > my ISP?
> >
> > I'd argue the evidence provided in this thread suggests to stick to
> > the first nameserver currently listed in your resolv.conf -- your own.
>
> Except that it shouldn't be dnsmasq, which is just a cache.
True, preferably it shouldn't. It may be, though, if it forwards to a
resolving DNS that easily flies below the radar and doesn't get blocked
for abuse by a DNSxL.
I don't recall if the OP is running dnsmasq on his local DNS.
However, when he dropped his ISP's nameservers and his local one became
the first listed, it started to work. So his local DNS seems not to
forward to the same nameservers he originally showed.
--
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: False negatives/positives on debian
Posted by RW <rw...@googlemail.com>.
On Sat, 22 Jun 2013 23:18:24 +0200
Karsten Bräckelmann wrote:
> > If these things are true then the last question is - is it safe to
> > use OpenDNS IP addresses in my resolv.conf (and hence the remainder
> > of my small network) or should I stick to the addresses provided by
> > my ISP?
>
> I'd argue the evidence provided in this thread suggests to stick to
> the first nameserver currently listed in your resolv.conf -- your own.
Except that it shouldn't be dnsmasq, which is just a cache.
Re: False negatives/positives on debian
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2013-06-23 at 06:52 +1000, Robert S wrote:
> The OpenDNS website states "OpenDNS is the largest and most reliable
> _recursive_ DNS service available ...". Presumably this explains why
> my queries are not blocked when I use OpenDNS.
Again, nope. The OpenDNS server will do the query -- thus, if used by
too many clients, it will exceed the limit of "abuse" just like your
ISP's caching (and recursive) DNS does.
Please read my previous explanation (quoted below) about the order of
nameservers again.
> Various discussions on the net state that typo correction causes
> problems on OpenDNS with SURBL/URIBL. However the spamassassin wiki
> at http://wiki.apache.org/spamassassin/OpenDnsAndUribls states that
> OpenDNS do not use typo correction by default.
"Typo correction" does introduce a whole lot of issues -- for the
clients. DNS servers getting blocked by a DNSxL is none of them, though.
> If these things are true then the last question is - is it safe to use
> OpenDNS IP addresses in my resolv.conf (and hence the remainder of my
> small network) or should I stick to the addresses provided by my ISP?
I'd argue the evidence provided in this thread suggests to stick to the
first nameserver currently listed in your resolv.conf -- your own.
> On Sun, Jun 23, 2013 at 5:59 AM, Karsten Bräckelmann wrote:
> > On Sat, 2013-06-22 at 21:16 +1000, Robert S wrote:
> > > I've eliminated this problem by using openDNS servers:
> >
> > Nope. You've eliminated the problem by dropping your ISP's DNS servers.
> >
> > SA uses the first listed nameserver, IIRC, which previously was your
> > ISP's. By removing them, the third listed became the first -- your local
> > nameserver. The additional two nameservers usually are not used.
> >
> > The other piece of the puzzle is, that your own server is not configured
> > to forward DNS queries to your ISP's DNS server. It either resolves, or
> > forwards to another server not blocked for abuse.
> >
> >
> > > # cat /etc/resolv.conf
> > > domain mydomain.net.au
> > > search mydomain.net.au
> > > nameserver 192.168.0.33 #<--- My server IP
> > > nameserver 208.67.220.220
> > > nameserver 208.67.222.222
--
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: False negatives/positives on debian
Posted by Robert S <ro...@gmail.com>.
The OpenDNS website states "OpenDNS is the largest and most reliable
_recursive_ DNS service available ...". Presumably this explains why
my queries are not blocked when I use OpenDNS.
Various discussions on the net state that typo correction causes
problems on OpenDNS with SURBL/URIBL. However the spamassassin wiki
at http://wiki.apache.org/spamassassin/OpenDnsAndUribls states that
OpenDNS do not use typo correction by default.
If these things are true then the last question is - is it safe to use
OpenDNS IP addresses in my resolv.conf (and hence the remainder of my
small network) or should I stick to the addresses provided by my ISP?
On Sun, Jun 23, 2013 at 5:59 AM, Karsten Bräckelmann
<gu...@rudersport.de> wrote:
> On Sat, 2013-06-22 at 21:16 +1000, Robert S wrote:
>> I've eliminated this problem by using openDNS servers:
>
> Nope. You've eliminated the problem by dropping your ISP's DNS servers.
>
> SA uses the first listed nameserver, IIRC, which previously was your
> ISP's. By removing them, the third listed became the first -- your local
> nameserver. The additional two nameservers usually are not used.
>
> The other piece of the puzzle is, that your own server is not configured
> to forward DNS queries to your ISP's DNS server. It either resolves, or
> forwards to another server not blocked for abuse.
>
>
>> # cat /etc/resolv.conf
>> domain mydomain.net.au
>> search mydomain.net.au
>> nameserver 192.168.0.33 #<--- My server IP
>> nameserver 208.67.220.220
>> nameserver 208.67.222.222
>>
>> Is this likely to have untoward consequences? I've also looked at
>> using unbound - which looks quite straightforward.
>
>
> --
> 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;i<l;i++){ i%8? c<<=1:
> (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
>
Re: False negatives/positives on debian
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sat, 2013-06-22 at 21:16 +1000, Robert S wrote:
> I've eliminated this problem by using openDNS servers:
Nope. You've eliminated the problem by dropping your ISP's DNS servers.
SA uses the first listed nameserver, IIRC, which previously was your
ISP's. By removing them, the third listed became the first -- your local
nameserver. The additional two nameservers usually are not used.
The other piece of the puzzle is, that your own server is not configured
to forward DNS queries to your ISP's DNS server. It either resolves, or
forwards to another server not blocked for abuse.
> # cat /etc/resolv.conf
> domain mydomain.net.au
> search mydomain.net.au
> nameserver 192.168.0.33 #<--- My server IP
> nameserver 208.67.220.220
> nameserver 208.67.222.222
>
> Is this likely to have untoward consequences? I've also looked at
> using unbound - which looks quite straightforward.
--
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: False negatives/positives on debian
Posted by Robert S <ro...@gmail.com>.
I've eliminated this problem by using openDNS servers:
# cat /etc/resolv.conf
domain mydomain.net.au
search mydomain.net.au
nameserver 192.168.0.33 #<--- My server IP
nameserver 208.67.220.220
nameserver 208.67.222.222
Is this likely to have untoward consequences? I've also looked at using
unbound - which looks quite straightforward.
On Sat, Jun 22, 2013 at 8:57 PM, Benny Pedersen <me...@junc.eu> wrote:
> John Hardin skrev den 2013-06-22 06:45:
>
>
> If you're running dnsmasq locally, you should list it first so that
>> you take advantage of its local cache and only fall back to direct
>> queries of your ISP's servers if dnsmasq fails for some reason.
>>
>
> that only hold water if /etc/resolv.conf does not contain options rotate,
> its not a question of first :)
>
>
> --
> 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: False negatives/positives on debian
Posted by Benny Pedersen <me...@junc.eu>.
John Hardin skrev den 2013-06-22 06:45:
> If you're running dnsmasq locally, you should list it first so that
> you take advantage of its local cache and only fall back to direct
> queries of your ISP's servers if dnsmasq fails for some reason.
that only hold water if /etc/resolv.conf does not contain options
rotate, its not a question of first :)
--
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: False negatives/positives on debian
Posted by John Hardin <jh...@impsec.org>.
On Sat, 22 Jun 2013, Robert S wrote:
> That wasn't the complete reply - hit the reply button too soon . . .
>
> The two addresses at the top are my ISP's DNS servers and the bottom is the
> IP address of my server. I still get the administrator notice with this
> configuration. Is there an additional step that I need to take? I'm not a
> DNS expert.
Nameservers are generally tried in the order listed. Your BL traffic is
probably being aggregated with a bunch of other clients of your ISP.
If you're running dnsmasq locally, you should list it first so that you
take advantage of its local cache and only fall back to direct queries of
your ISP's servers if dnsmasq fails for some reason.
> I only run a small business and I doubt that we'd be exceeding the URIBL
> quota.
Ok, good.
I'm not extremely familiar with dnsmasq, but I don't think it's capable of
acting as a recursive DNS server on its own.
It's not too difficult to set up a recursive local nameserver if you
aren't hosting any authoritative entries (i.e. if you're not providing the
main DNS for domain(s) that you own). The important thing is to make sure
that third parties can't come in from the internet and use your recursive
DNS server. "open" recursive DNS servers are abused by those performing
DDOS attacks.
> On Sat, Jun 22, 2013 at 2:08 PM, Robert S <ro...@gmail.com> wrote:
>
>>>> This message seems to get blocked in a lot of blocklists (which also
>>>> seem to happen to my users' messages).
>>>
>>> That's the first thing you need to resolve.
>>>
>>>> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
>>>> blocked.
>>>> See
>>>> http://wiki.apache.org/**spamassassin/DnsBlocklists#**dnsbl-block<http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block>
>>>> for more information.
>>>>
>>>
>>> This means your URIBL queries are exceeding the limit for unpaid access.
>>>
>>> How is your SA/MTA DNS set up?
>>>
>>
>> I think we're on the right track. I use dnsmasq with no extra
>> customisations. My resolv.conf looks like this:
>>
>> $ cat /etc/resolv.conf
>> domain mydomain.net.au
>> nameserver 202.136.42.205
>> nameserver 202.136.43.205
>> nameserver 192.168.0.33
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Maxim XXXV: That which does not kill you has made a tactical error.
-----------------------------------------------------------------------
386 days since the first successful private support mission to ISS (SpaceX)
Re: False negatives/positives on debian
Posted by Benny Pedersen <me...@junc.eu>.
Robert S skrev den 2013-06-22 06:14:
> I only run a small business and I doubt that we'd be exceeding the
> URIBL quota.
you need to change /etc/resolv.conf to nameserver 127.0.0.1 and use
bind9 as local dns server that just have NONE forwards in options, and
it must only listen on 127.0.0.1, when this is setup you life is free :)
--
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: False negatives/positives on debian
Posted by Robert S <ro...@gmail.com>.
That wasn't the complete reply - hit the reply button too soon . . .
The two addresses at the top are my ISP's DNS servers and the bottom is the
IP address of my server. I still get the administrator notice with this
configuration. Is there an additional step that I need to take? I'm not a
DNS expert.
I only run a small business and I doubt that we'd be exceeding the URIBL
quota.
On Sat, Jun 22, 2013 at 2:08 PM, Robert S <
robert.spam.me.senseless@gmail.com> wrote:
> This message seems to get blocked in a lot of blocklists (which also
>>> seem to happen to my users' messages).
>>>
>>
>> That's the first thing you need to resolve.
>>
>>
>> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
>>> blocked.
>>> See
>>> http://wiki.apache.org/**spamassassin/DnsBlocklists#**dnsbl-block<http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block>
>>> for more information.
>>>
>>
>> This means your URIBL queries are exceeding the limit for unpaid access.
>>
>> How is your SA/MTA DNS set up?
>>
> Hi.
>
> I think we're on the right track. I use dnsmasq with no extra
> customisations. My resolv.conf looks like this:
>
> $ cat /etc/resolv.conf
> domain mydomain.net.au
> nameserver 202.136.42.205
> nameserver 202.136.43.205
> nameserver 192.168.0.33
>
Re: False negatives/positives on debian
Posted by John Hardin <jh...@impsec.org>.
On Sat, 22 Jun 2013, Robert S wrote:
> This message seems to get blocked in a lot of blocklists (which also
> seem to happen to my users' messages).
That's the first thing you need to resolve.
> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
> blocked.
> See
> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
> for more information.
This means your URIBL queries are exceeding the limit for unpaid access.
How is your SA/MTA DNS set up?
Are you forwarding your MTA/SA DNS requests to a large ISP or to a popular
free DNS service? If so, your URIBL query traffic may be aggregated with
many others and that agregate traffic may be exceeding the unpaid access
limit. The solution to this is to set up a local caching recursive DNS
server for your MTA/SA (and possibly the rest of your local network) to
use, so that your BL DNS query traffic is not aggregated with others'.
Are you a sizeable ISP or other type of service provider yourself? If so,
you might need to investigate paid access to URIBL.
The scored URIBL hits may be a result of this situation - but I thought we
didn't score on "blocked" URIBL queries... You might check to see that
sa-update is actually keeping your rules up-to-date.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Maxim XXXV: That which does not kill you has made a tactical error.
-----------------------------------------------------------------------
386 days since the first successful private support mission to ISS (SpaceX)
Re: False negatives/positives on debian
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Sat, 22 Jun 2013, Robert S wrote:
> I am running spamassassin_3.3.2-5 on debian Wheezy on a small business server (x86). I am getting numerous complaints about mail
> being falely categorised as spam/ham. I also use version 3.3.2 on my home server using gentoo (amd64) and don't have these
> problems. I have removed all customisations and have reinstalled spamassassin on my debian machine. There still seem to be problems
> - here's an example using the provided sample files. Can anybody help?
>
> This message seems to get blocked in a lot of blocklists (which also seem to happen to my users' messages).
>
> Options for SA are:
>
> # ps ax |grep spam
> 22408 ? Ss 0:02 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir -d --pidfile=/var/run/spamd.pid
>
> /etc/procmailrc includes this:
>
> * < 256000
> | /usr/bin/spamc
> $ spamc < sample-nonspam.txt
>
> Received: from localhost by debian.myserver.net.au
> with SpamAssassin (version 3.3.2);
> Sat, 22 Jun 2013 12:06:12 +1000
> From: Keith Dawson <da...@world.std.com>
> To: tbtf@world.std.com
> Subject: TBTF ping for 2001-04-20: Reviving
> Date: Fri, 20 Apr 2001 16:59:58 -0400
> Message-Id: <v0421010eb70653b14e06@[208.192.102.193]>
> X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
> debian.myserver.net.au
> X-Spam-Flag: YES
> X-Spam-Level: ********
> X-Spam-Status: Yes, score=8.5 required=5.0 tests=RP_MATCHES_RCVD,SAGREY,
> URIBL_AB_SURBL,URIBL_BLOCKED,URIBL_GREY,URIBL_MW_SURBL,URIBL_PH_SURBL,
> URIBL_RED,URIBL_WS_SURBL autolearn=no version=3.3.2
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="----------=_51C50694.B9FC2455"
> This is a multi-part message in MIME format.
> ------------=_51C50694.B9FC2455
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
> Spam detection software, running on the system "debian.myserver.net.au", has
> identified this incoming email as possible spam. The original message
> has been attached to this so you can view it (if it isn't spam) or label
> similar future email. If you have any questions, see
> the administrator of that system for details.
> Content preview: -----BEGIN PGP SIGNED MESSAGE----- TBTF ping for 2001-04-20:
> Reviving T a s t y B i t s f r o m t h e T e c h n o l o g y F r o n t [...]
>
> Content analysis details: (8.5 points, 5.0 required)
> pts rule name description
> ---- ---------------------- --------------------------------------------------
> -1.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
> 0.0 URIBL_RED Contains an URL listed in the URIBL redlist
> [URIs: tbtf.com]
> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
> See
> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
> for more information.
> [URIs: tbtf.com]
> 1.1 URIBL_GREY Contains an URL listed in the URIBL greylist
> [URIs: tbtf.com]
> 0.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
> [URIs: tbtf.com]
> 4.5 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
> [URIs: tbtf.com]
> 1.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
> [URIs: tbtf.com]
> 1.7 URIBL_MW_SURBL Contains a Malware Domain or IP listed in the MW SURBL
> blocklist
> [URIs: tbtf.com]
> 1.0 SAGREY Adds 1.0 to spam from first-time senders
>
> ------------=_51C50694.B9FC2455
> Content-Type: message/rfc822; x-spam-type=original
> Content-Description: original message before SpamAssassin
[snip..]
clearly the bulk of those points come from those URI-RBL type rules,
which look like FPs. At least that "tbtf.com" domain isn't listed right
now, it -might- have been when this message was processed. However given
that "URIBL_BLOCKED" rule fired, it looks more like there's something
wrong with your setup which is causing all those URI-RBLs to FP.
Have you looked at the web page that URIBL_BLOCKED rule references?
Have you investigated why it fired? Have you tried taking any
of the advice on that page as to how to deal with this problem?
To go beyond the advice on that page we'd need to know more details about
how your DNS/network is configured on your SA scanner machine (are you
running a local caching DNS server? Are you using some explicit DNS
forwarder? Does your ISP do anything special with DNS queries? ...
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{