You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ed Abbott <we...@gmail.com> on 2012/06/07 12:53:32 UTC
False Positive on Domain Name
My domain name, websiterepairguy.com, is causing
spamassassin to give a false positive.
Here are the tests that all give a false positive for
websiterepairguy.com:
1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
[URIs: websiterepairguy.com]
0.6 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
[URIs: websiterepairguy.com]
4.5 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
[URIs: websiterepairguy.com]
1.6 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
[URIs: websiterepairguy.com]
1.2 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
[URIs: websiterepairguy.com]
0.6 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
[URIs: websiterepairguy.com]
I've checked here to see if my domain is blocked:
https://admin.uribl.com/
When I lookup websiterepairguy,com, I get the
following reply:
NOT Listed on URIBL
I only seem to have this problem under the following
circumstances:
1 -- I reply to an email that someone sends me
2 -- They reply back
It's the reply back that seems to trigger the false
positive. In other words, it is the fact that
websiterepairguy.com is embedded in the body
of the message that seems to trigger the false
positive.
At will, I can trigger a false positive by sending
myself an email that consists of the following:
1 -- Any subject line will do
2 -- One thing only in the body, the domain
name websiterepairguy.com.
I think I've simplified the problem to one thing
only and that is the appearance of my domain,
websiterepairguy.com, in the body of the message.
If websiterepairguy.com appears in the body of the
message, it triggers a false positive. Any ideas?
Sorry if this question has been answered before.
I did a search and did not come up with anything.
However, I'm so puzzled by this problem that I'm
not even sure what to do a search on.
Yesterday, I installed bind9. Not sure if that is
relevant but I thought I'd mention it. Also, I'm
using kmail under Debian Squeeze as my email
client.
Of course, how I invoke spamassassin makes
a difference. If I use the following invocation, I
have no problem:
spamassassin - L
However, if I invoke it this way, I get the false
positives:
spamassassin
Obviously, if I use only local spamassassin rules,
it is not a problem.
Is this a bug? Am I doing something wrong? I'm
baffled by this problem.
I'm attaching a file that demonstrates the problem
in its simplest form. The simplest possible manifestation
of this problem is an email I send to myself that consists
of nothing but websiterepairguy.com in the body.
http://old.nabble.com/file/p33975030/spam.mbox spam.mbox
Thanks in advance to anyone who might care to reply.
My sincere apologies if this is a common problem that
I've not discovered an answer to because of the clumsiness
of my google searches.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33975030.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Ralf Hildebrandt <Ra...@charite.de>.
> I've now refreshed the DNS cache and restarted spamassassin by
> rebooting Linux. No change in result.
Maybe YOUR server is querying an upstream DNS server which has the
data cached.
--
Ralf Hildebrandt Charite Universitätsmedizin Berlin
ralf.hildebrandt@charite.de Campus Benjamin Franklin
http://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Robert Schetterer wrote:
>
>
> perhaps try refreshing your dns caches and/or restart spamassassin
> afterwards
>
>
I've now refreshed the DNS cache and restarted spamassassin by
rebooting Linux. No change in result.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33975169.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-07 19:35, John Hardin skrev:
> /etc/resolv.conf is where you'd start. If that says localhost (which
> it should to use a local nameserver), then look at the configuration
> of your local DNS server (likely BIND, likely /etc/bind/named.conf or
> /etc/named/named.conf).
#/etc/resolv.conf
nameserver 127.0.0.1
search ipv4.google.com
# options .....
maybe some knows more ?
in bind.conf dont use forwards in options section, its ok with forwards
pr zone, eg for zones that blocks you or dont want to fix there
ignorance on how:
dig +trace example.org
works, but using forwards dnssec will break, but there is nameservers
that support dnssec with forwards, but the whole chain must support it
so
Re: False Positive on Domain Name
Posted by John Hardin <jh...@impsec.org>.
On Thu, 7 Jun 2012, Ed Abbott wrote:
>
>
> Axb wrote:
>>
>> Are you forwarding your queries to a third party DNS?
>>
>> Axb
>>
>
> Not intentionally. Am I doing so out of ignorance?
> Maybe.
>
> I'm a lone individual working from a home computer
> and Time-Warner cable is my ISP. Do DNS queries
> normally go to Time-Warner first? I don't know.
>
> I assume that whenever I do an Internet search in
> a web browser that I'm using Time-Warner's DNS
> servers. Therefore it would make sense to me that
> I'm using Time-Warner for other DNS queries too.
>
> Thank you for pointing out the forwarding issue. I'll try
> to figure out a way to look into this.
/etc/resolv.conf is where you'd start. If that says localhost (which it
should to use a local nameserver), then look at the configuration of your
local DNS server (likely BIND, likely /etc/bind/named.conf or
/etc/named/named.conf).
--
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 VI: If violence wasn’t your last resort, you failed to resort
to enough of it.
-----------------------------------------------------------------------
7 days since the first successful private support mission to ISS (SpaceX)
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Axb wrote:
>
> Are you forwarding your queries to a third party DNS?
>
> Axb
>
Not intentionally. Am I doing so out of ignorance?
Maybe.
I'm a lone individual working from a home computer
and Time-Warner cable is my ISP. Do DNS queries
normally go to Time-Warner first? I don't know.
I assume that whenever I do an Internet search in
a web browser that I'm using Time-Warner's DNS
servers. Therefore it would make sense to me that
I'm using Time-Warner for other DNS queries too.
Thank you for pointing out the forwarding issue. I'll try
to figure out a way to look into this.
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33976986.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Ralf Hildebrandt wrote:
>
>> host websitereapirguy.com.multi.uribl.com
>
> websiterepairguy.com.multi.uribl.com
> (note the typo)
>
>
Thank you for correcting my typo! The
corrected domain is, as you state,
websiterepairguy.com
I should have copied and pasted rather
than re-typed. That's my lesson.
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33977016.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Axb <ax...@gmail.com>.
On 06/07/2012 01:37 PM, Ralf Hildebrandt wrote:
> * Axb<ax...@gmail.com>:
>
>> in console check with:
>>
>> host websitereapirguy.com.multi.uribl.com
>
> websiterepairguy.com.multi.uribl.com
> (note the typo)
>
Doh! - copy/paste previous author's error
(rndc flushname websitereapirguy.com)
anyway, still:
Host websiterepairguy.com.multi.uribl.com not found: 3(NXDOMAIN)
Host websiterepairguy.com.multi.surbl.org not found: 3(NXDOMAIN)
etc..
Re: False Positive on Domain Name
Posted by Ralf Hildebrandt <Ra...@charite.de>.
* Axb <ax...@gmail.com>:
> in console check with:
>
> host websitereapirguy.com.multi.uribl.com
websiterepairguy.com.multi.uribl.com
(note the typo)
--
Ralf Hildebrandt Charite Universitätsmedizin Berlin
ralf.hildebrandt@charite.de Campus Benjamin Franklin
http://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: False Positive on Domain Name
Posted by Axb <ax...@gmail.com>.
On 06/07/2012 01:19 PM, Ed Abbott wrote:
>
>
>
> Robert Schetterer wrote:
>>
>> perhaps try refreshing your dns caches and/or restart spamassassin
>> afterwards
>>
>
> I've flushed the cache with this command:
>
> rndc flushname websitereapirguy.com
>
> So far, no change.
>
> I'll restart spamassassin by rebooting my
> machine next. Not sure that I'm running
> a daemon for spamassassin as I'm on a
> single user system.
>
> I assume spamassassin only runs when
> I check email. That's my best guess.
>
> However, I'm going to reboot anyway.
in console check with:
host websitereapirguy.com.multi.uribl.com
anything other than
Host websitereapirguy.com.multi.uribl.com not found: 3(NXDOMAIN)
is bad news.
Are you forwarding your queries to a third party DNS?
If yes, this is probably the reason. That 3rd party DNS rcursor is
probably giving you positive replied to all queries.
(this is reinforced by the fact that it replies you're listed on SUBRL
as well)
Fix: remove query forwarding.
Axb
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Robert Schetterer wrote:
>
> perhaps try refreshing your dns caches and/or restart spamassassin
> afterwards
>
I've flushed the cache with this command:
rndc flushname websitereapirguy.com
So far, no change.
I'll restart spamassassin by rebooting my
machine next. Not sure that I'm running
a daemon for spamassassin as I'm on a
single user system.
I assume spamassassin only runs when
I check email. That's my best guess.
However, I'm going to reboot anyway.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33975130.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Robert Schetterer <ro...@schetterer.org>.
Am 07.06.2012 12:53, schrieb Ed Abbott:
> I've checked here to see if my domain is blocked:
>
> https://admin.uribl.com/
>
> When I lookup websiterepairguy,com, I get the
> following reply:
>
> NOT Listed on URIBL
perhaps try refreshing your dns caches and/or restart spamassassin
afterwards
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
>
> If you're still getting hits on these rules there's a good chance that
> the DNS cache you're using is either modifying the negative results (ie,
> similar to http://www.surbl.org/faqs#opendns) or has been making too
> many requests to SURBL, and is now either receiving "yes it's listed"
> for any request, or is generating that response for some reason.
>
> As a local workaround (since your domain doesn't seem to be listed
> currently), I suggest adding "uridnsbl_skip_domain websiterepairguy.com"
> to your SpamAssassin config - that will skip doing URI blacklist lookups
> altogether on your domain.
>
> -kgd
>
>
Thank you Kris for your detailed response!
I'm thinking this through and I think I'll do the
following:
1 -- Implement "uridnsbl_skip_domain websiterepairguy.com"
immediately in ~/.spamassassin/user_prefs
2 -- Research DNS caching
I don't know enough about DNS caching to make any changes.
For me, bind9 is magic. At present, I have no idea how to ask
bind9 to do things differently.
I'll take your word for it that the DNS queries may be getting
modified somewhere along the way. I just don't know enough
about DNS yet to come up with a way to research this.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33977175.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
> or has been making too
> many requests to SURBL, and is now either receiving "yes it's listed"
> for any request, or is generating that response for some reason.
>
That's entirely possible. It's only through doing research that
I learned that I'm supposed to set up bind9, or something similar.
Many months ago, I was making raw requests to SURBL because
I did not know about the following option:
spamassassin -L
Rather than deal with the problem at that time, I switched to the
-L option. Prior to switching, I'd been using spamassassin without
the -L switch out of ignorance.
More specifically, I'd been doing this:
cat spam.mbox | spamassassin -dt >temp
When I learned a better way, I did this:
cat spam.mbox | spamassassin -dtL >temp
Fortunately, my Linux distro, Debian (or KDE
or whatever) had set the default for incoming
mail to this:
spamassassin -L
However, when I tested new spamassassin rules
that I'd written, I did this initially:
cat spam.mbox | spamassassin -dt >temp
That absence of the -L switch when testing new spamassassin
rules that I personally wrote myself is what may have gotten
me into trouble.
Thanks for your reply! Much appreciated!
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33977081.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Bowie Bailey <Bo...@BUC.com>.
On 6/8/2012 12:57 PM, Ed Abbott wrote:
>
> John Hardin wrote:
>>
>> Ed, you said you've already installed BIND, that covers the "local,
>> caching" part. Now configure it to not forward requests.
>>
>>
> Thank you John!
>
> I think you may have given me the only answer that is going to
> work. I've tried to get my ISP to allow me to opt out of DNS
> redirection. No luck.
>
> What does it mean to not forward requests? Bind has to get
> its information from somewhere.
Not forwarding requests means that your DNS server directly queries the
authoritative servers for each domain. It first queries the root
servers to find the authoritative server and then queries that server to
find the ip.
> Is it possible for me to set up bind9 so that it gets its information
> from my ISP DNS Server via some kind of data feed? I'm guessing
> that is what you are saying.
That is called "forwarding" and is what you do *not* want to do.
> I think you are saying that bind9 is my own DNS server and that
> it will not forward requests to other DNS servers. Is this correct?
>
> If it does not forward requests to other DNS servers, then it must
> be receiving its information in another way. Does it receive it in
> a cron job or something like that?
See my first reply above.
> Sorry to ask so many questions. I'm not really sure what I set up
> when I set up bind9.
>
> As you can see, I'm new to this and don't really know what to ask
> or where to start reading. Is a caching DNS server a huge expense
> in terms of human management and computer hardware resources?
No, a caching DNS server is really fairly simple and once you get it
working properly, you should not have to do much with it.
--
Bowie
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-08 18:57, Ed Abbott skrev:
> I think you may have given me the only answer that is going to
> work. I've tried to get my ISP to allow me to opt out of DNS
> redirection. No luck.
you can modify any files in your own host ?, where is the problem with
your isp delivery you wodka ? :=)
> What does it mean to not forward requests? Bind has to get
> its information from somewhere.
if you use remote nameservers in /etc/resolv.conf then you are forceing
forwards in dns terms
bind have a "." zone hint type :=)
make sure this file is less then 6 monts old !
see the root.cache file where to get it
> Is it possible for me to set up bind9 so that it gets its information
> from my ISP DNS Server via some kind of data feed?
no add forwards in bind help as much as not running bind at all
> I'm guessing that is what you are saying.
nope you showed that rr is not paying for antispam via dns querries
> I think you are saying that bind9 is my own DNS server and that
> it will not forward requests to other DNS servers. Is this correct?
forward is incorrect terms here, fetch is more correct
> If it does not forward requests to other DNS servers, then it must
> be receiving its information in another way.
this starts at the "." root zone in bind, its like dns admins start
reading books before installing bind :=)
> Does it receive it in a cron job or something like that?
root servers dont change each day, even annoumous tryed forcing them
out of service, thay belived we admins would miss our root zone, thay
showed there ignorance on how dns works
> Sorry to ask so many questions. I'm not really sure what I set up
> when I set up bind9.
bind is so simple that you cant make error with it
> As you can see, I'm new to this and don't really know what to ask
> or where to start reading. Is a caching DNS server a huge expense
> in terms of human management and computer hardware resources?
nope it just cost some memory
> I'm a lone individual on a home computer.
you are not alone
Re: False Positive on Domain Name
Posted by John Hardin <jh...@impsec.org>.
On Fri, 8 Jun 2012, Ed Abbott wrote:
> John Hardin wrote:
>
>> Ed, you said you've already installed BIND, that covers the "local,
>> caching" part. Now configure it to not forward requests.
>
> Thank you John!
>
> I think you may have given me the only answer that is going to
> work. I've tried to get my ISP to allow me to opt out of DNS
> redirection. No luck.
>
> What does it mean to not forward requests? Bind has to get
> its information from somewhere.
It does. In very broad strokes:
1. you ask about www.google.com
2. the DNS server asks the .com authoritative TLD DNS servers "who is the
authoritative DNS server for google.com?"
3. it then asks that DNS server "what is the IP address for
www.google.com"?
Forwarding is your DNS server asking some other DNS server to do the hard
work and just return the final result. In the above list, you ask (1) of
your local DNS server, which turns around and asks (1) of your ISP's DNS
server (your "forwarder"), which then does (2) and (3) on your behalf and
returns the result.
That's what you want to do in most cases as caching the results of common
queries at your ISP reduces traffic to the other DNS servers (i.e. your
answer to (1) can be provided to other users at your ISP without doing (2)
and (3) over and over and over again), but DNS BLs are a special case as
many have unpaid-query volume limitations and you're querying a _lot_ of
different "hostnames" in their domain so caching doesn't work well.
With forwarding turned off, _your_ server does (2) and (3), and the
DNSBLs see a small number of queries coming from your IP address rather
than sagans of queries coming from your ISP's.
The _best_ approach is to do direct query of DNSBLs and forward everything
else to your ISP, but that's fairly advanced DNS setup and does require
ongoing awareness of what DNSBLs are being queried and when that list
changes.
> Is it possible for me to set up bind9 so that it gets its information
> from my ISP DNS Server via some kind of data feed? I'm guessing
> that is what you are saying.
There are ways to get feeds of DNS data, and the larger-volume users of
DNSBLs generally do it that way just for the DNSBL data, but general DNS
services are never set up that way, as the dataset would be enormous (i.e.
the entire Internet) and would effectively be immediately stale.
> I think you are saying that bind9 is my own DNS server and that
> it will not forward requests to other DNS servers. Is this correct?
Partially. If forwarding is turned off your DNS server won't ask another
DNS server the (1) question; it will do the (2) and (3) queries itself.
> As you can see, I'm new to this and don't really know what to ask
> or where to start reading. Is a caching DNS server a huge expense
> in terms of human management and computer hardware resources?
>
> I'm a lone individual on a home computer.
There are lots of introductory tutorials for the DNS protocol available if
you want more details.
The greatest amount of work is getting it originally set up and working.
The resources are fairly small, unless you're serving a large and busy
local network, which you aren't.
--
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
-----------------------------------------------------------------------
...in the 2nd amendment the right to arms clause means you have
the right to choose how many arms you want, and the militia clause
means that Congress can punish you if the answer is "none."
-- David Hardy, 2nd Amendment scholar
-----------------------------------------------------------------------
8 days since the first successful private support mission to ISS (SpaceX)
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
John Hardin wrote:
>
>
> Ed, you said you've already installed BIND, that covers the "local,
> caching" part. Now configure it to not forward requests.
>
>
Thank you John!
I think you may have given me the only answer that is going to
work. I've tried to get my ISP to allow me to opt out of DNS
redirection. No luck.
What does it mean to not forward requests? Bind has to get
its information from somewhere.
Is it possible for me to set up bind9 so that it gets its information
from my ISP DNS Server via some kind of data feed? I'm guessing
that is what you are saying.
I think you are saying that bind9 is my own DNS server and that
it will not forward requests to other DNS servers. Is this correct?
If it does not forward requests to other DNS servers, then it must
be receiving its information in another way. Does it receive it in
a cron job or something like that?
Sorry to ask so many questions. I'm not really sure what I set up
when I set up bind9.
As you can see, I'm new to this and don't really know what to ask
or where to start reading. Is a caching DNS server a huge expense
in terms of human management and computer hardware resources?
I'm a lone individual on a home computer.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33982797.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Version control config files (was Re: False Positive on Domain
Name)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 8 Jun 2012 18:30:25 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
> A piece of advice: take a look at the rcs/ci/co commands, and use
> them to "version control" your configuration files.
Or use etckeeper: http://joeyh.name/code/etckeeper/
On Debian and Ubuntu, it's just an apt-get away...
Regards,
David.
Re: False Positive on Domain Name
Posted by John Hardin <jh...@impsec.org>.
On Fri, 8 Jun 2012, Ed Abbott wrote:
> Kris Deugau wrote:
>>
>> Just keep in mind that NetworkManager may meddle with your resolv.conf,
>> so you can either keep a watch and manually fix it, or do as I've taken
>> to doing and setting the immutable bit with "chattr +i" so it can't be
>> changed.
>
> Looks like resolv.conf is overwritten each time I reboot.
> I'll implement your "chattr +i" suggestion after I've convinced
> myself that I have a stable solution that works each and every
> time.
>
> For now, I'm using the "cp file1 file2" to overwrite resolve.conf
> each time I reboot.
A piece of advice: take a look at the rcs/ci/co commands, and use them to
"version control" your configuration files. That makes it easy to keep a
backup copy of a known-working config file, and to keep a history of the
changes you've made to those files.
--
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
-----------------------------------------------------------------------
...the good of having the government prohibited from doing harm
far outweighs the harm of having it obstructed from doing good.
-- Mike@mike-istan
-----------------------------------------------------------------------
8 days since the first successful private support mission to ISS (SpaceX)
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-09 00:21, Ed Abbott skrev:
> Looks like resolv.conf is overwritten each time I reboot.
> I'll implement your "chattr +i" suggestion after I've convinced
> myself that I have a stable solution that works each and every
> time.
chattr is not a gui for dhcp servers
> For now, I'm using the "cp file1 file2" to overwrite resolve.conf
> each time I reboot.
make this computer dns server for all lan including your router that
still suggest you to change resolv.conf to use isp nameservers :=)
if its ubuntu there is a option to use dhcp for ip only and ignore dns,
in that case set dns server in network manager to 127.0.0.1
i know you want to :=)
its just more simple to solve the router, but start make sure that lan
computers have static lan ip first, else it will be more fun learning
why its important
no i dont want to be be hired, i have enough work in soho with my own
servers
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-09 12:53, Martin Gregorie skrev:
> I see little or no advantage in using DHCP.
its nice to see when friends stop by to add there laptops to your lan
:=)
it just take a second
what i have done is to set all my own lan computers with static lan,
and all dynamic get dynamic ip, eg witeless is in another ip pool/vlan,
and its not possible to see samba shares on wireless :=)
and lastly its totaly open wireless here, but it can not get internet
access to other then my soho home network, talk about shorewall'ing ?
:=)
Re: False Positive on Domain Name
Posted by Martin Gregorie <ma...@gregorie.org>.
On Fri, 2012-06-08 at 15:21 -0700, Ed Abbott wrote:
>
> Looks like resolv.conf is overwritten each time I reboot.
> I'll implement your "chattr +i" suggestion after I've convinced
> myself that I have a stable solution that works each and every
> time.
>
In the current Fedora releases (since F15 at least) you're right:
resolv.conf is recreated by NetworkManager during boot from the
information you set up with the Network applet. You can use the applet,
which you'll find as part of the System Settings stuff, to alter these
values. If you're setting these manually (Method='Manual'), select
'wired' from the initial window, click 'Options' and then use the IPV4
or IPV6 settings tab to inspect and change them. If you're getting them
via DHCP, you'll need to change the settings in your DHCP server
(probably part of your ADSL/DSL router.
I'm running a mixture of F15 (this laptop) and F16 (my house server,
which runs bind 9 and is definitive for my house LAN) with both
configured manually: in a small network (3 computers, 1 router, 1
network printer, 1 Squeezebox Touch internet radio tuner) I see little
or no advantage in using DHCP.
Martin
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-27 12:22, Ed Abbott skrev:
>> nearly perfect, remove domain-name-servers in request
> Thanks Benny. I have removed domain-name-servers
> in the request.
would be nice if debian/ubuntu maintainers read it if it can be some
suggestion on spamassassin install notes, since the default was more on
default for desktop users, and the one you now have is needed for server
users, and lastly it does not hurt desktop users doin this in fail :)
knowing how dns works, helps understand problem, and solution better
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Benny Pedersen wrote
>
> nearly perfect, remove domain-name-servers in request
>
Thanks Benny. I have removed domain-name-servers
in the request.
Here's the version of /etc/dhcp/dhclient.conf with
domain-name-servers removed:
http://spamassassin.1065346.n5.nabble.com/file/n100618/dhclient.conf
dhclient.conf
Here's the resultant /etc/resolv.conf file:
http://spamassassin.1065346.n5.nabble.com/file/n100618/resolv.conf
resolv.conf
Hopefully the above files will make it easy for anyone who
happens to have the same problem I had and who happens
to read this thread.
Ed
--
View this message in context: http://spamassassin.1065346.n5.nabble.com/False-Positive-on-Domain-Name-tp67067p100618.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-22 16:20, Ed Abbott skrev:
> Now that I have access to block lists, life is so much easier.
nearly perfect, remove domain-name-servers in request
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Reko Turja wrote
>
>
>> Looks like resolv.conf is overwritten each time I reboot.
>> I'll implement your "chattr +i" suggestion after I've convinced
>> myself that I have a stable solution that works each and every
>> time.
>
> Dont know what flavor of dhclient linux is running, but in freebsd this
> kind
> of unpleasantness can be avoided by editing /etc/dhclient.conf
>
> -Reko
>
Thanks Reko for your suggestion. I've added the following line
to /etc/dhcp/dhclient.conf under Debian Squeeze:
supersede domain-name-servers 127.0.0.1;
I found the supersede command by typing this command:
$ man dhclient.conf
It works! Here's what resolve.conf looked like before I
made this change:
http://spamassassin.1065346.n5.nabble.com/file/n100578/resolv.conf.before
resolv.conf.before
Here's what it looks like after:
http://spamassassin.1065346.n5.nabble.com/file/n100578/resolv.conf.after
resolv.conf.after
Not sure if it matters, but I placed the "supersede" command just
after the request to dhcp:
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;
supersede domain-name-servers 127.0.0.1;
I'm treating the "request" command and the "supersede" commands
as if they were commands on a serial computer. Probably it does
not matter. However, just for extra caution, I have the "supersede"
command placed last just to make sure it has an effect and does
not get canceled out by the "request" command.
Here's my dhclient.conf before I changed it:
http://spamassassin.1065346.n5.nabble.com/file/n100578/dhclient.conf.before
dhclient.conf.before
Here's my dhclient.conf after I changed it:
http://spamassassin.1065346.n5.nabble.com/file/n100578/dhclient.conf.after
dhclient.conf.after
Now that I have access to block lists, life is so much easier.
Ed
--
View this message in context: http://spamassassin.1065346.n5.nabble.com/False-Positive-on-Domain-Name-tp67067p100578.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-13 14:24, Ed Abbott skrev:
> In other words, It would be nice to set my
> nameserver to localhost permanently.
no one stops anyone from changing ones own dhcpd server to say
nameserver is 127.0.0.1, or other ip in rfc1918
its more simple doing it right in the router then fight all clients :=)
Locking down your resolver config (was Re: False Positive on Domain
Name)
Posted by Kris Deugau <kd...@vianet.ca>.
Reko Turja wrote:
> I'm myself bit leery for making stuff immutable that update scripts etc.
> usually assume having preset flags. Immutable in wrong place can make
> stuff fail in pretty interesting ways.
Well, my reason for *setting* the immutable bit was that by definition,
any automated widget changing /etc/resolv.conf was Doing The Wrong
Thing, and as best I could determine, could not be told "Don't change
that file, at all, ever" any other way. >:( Anything that breaks
because it can't change resolv.conf is already broken anyway, by my own
local policies.
I've also been known to "chmod 0" (or the Windows equivalent, more
commonly) executables which are perfectly legitimate and which have
absolutely no business actually executing on my system.
I've yet to actually see any breakage doing either of these.
-kgd
Re: False Positive on Domain Name
Posted by Reko Turja <re...@liukuma.net>.
> Ed Abbott wrote:
>> Reko Turja wrote:
>>
>> Sorry for butting in a bit late...
>>
>> Dont know what flavor of dhclient linux is running, but in freebsd this
>> kind
>> of unpleasantness can be avoided by editing /etc/dhclient.conf as
>> follows:
>>
>> interface "<iface name>" {
>> supersede domain-name "your.internal.tld";
>> supersede domain-name-servers <list of your preferred
>> name
>> servers>;
>> }
>>
>> Of course superseding domain name depends on your internal net
>> configuration.
> I wonder if the syntax for the two files is the same. I'm running Debian
> Squeeze.
It looks like Vixie/ISC dhclient, so the syntax should be the same. Unless
you are running a two homed host like firewall on that machine, I reckon you
could put the supersede-name-servers statement in the file without
specifying the interface at all. If your machine has direct access to rr
network, then it can be a good idea to let dhcp take care of domain names
without superseding.
> Of course, I can always play with the file attributes in some way so as to
> prevent
> overwriting as one person has suggested. However, I think your suggestion
> is more
> ideal.
I'm myself bit leery for making stuff immutable that update scripts etc.
usually assume having preset flags. Immutable in wrong place can make stuff
fail in pretty interesting ways. Of course, my knowledge about linux and its
innards is more than decade old, so your mileage may wary :)
-Reko
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Reko Turja wrote:
>
> Sorry for butting in a bit late...
>
> Dont know what flavor of dhclient linux is running, but in freebsd this
> kind
> of unpleasantness can be avoided by editing /etc/dhclient.conf as follows:
>
> interface "<iface name>" {
> supersede domain-name "your.internal.tld";
> supersede domain-name-servers <list of your preferred name
> servers>;
> }
>
> Of course superseding domain name depends on your internal net
> configuration.
>
> -Reko
>
>
Hi Reko,
I find a similarly named file here:
/etc/dhcp/dhclient.conf
I wonder if the syntax for the two
files is the same. I'm running Debian
Squeeze.
The file is small enough that I thought
I'd upload it as an attachment.
Thanks for replying! You are not at
all too late. I'm still figuring things out
as I go.
Manually overwriting /etc/resolv.conf each
time I boot is definitely working. However, it
would be nice to have a more permanent solution.
In other words, It would be nice to set my
nameserver to localhost permanently.
Of course, I can always play with the file
attributes in some way so as to prevent
overwriting as one person has suggested.
However, I think your suggestion is more
ideal.
Ed Abbott
http://old.nabble.com/file/p34005355/dhclient.conf dhclient.conf
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p34005355.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Reko Turja <re...@liukuma.net>.
Sorry for butting in a bit late...
> Ed Abbott wrote:
>> Kris Deugau wrote:
>>
>>
>> Just keep in mind that NetworkManager may meddle with your resolv.conf,
>> so you can either keep a watch and manually fix it, or do as I've taken
>> to doing and setting the immutable bit with "chattr +i" so it can't be
>> changed.
>
>
> Looks like resolv.conf is overwritten each time I reboot.
> I'll implement your "chattr +i" suggestion after I've convinced
> myself that I have a stable solution that works each and every
> time.
Dont know what flavor of dhclient linux is running, but in freebsd this kind
of unpleasantness can be avoided by editing /etc/dhclient.conf as follows:
interface "<iface name>" {
supersede domain-name "your.internal.tld";
supersede domain-name-servers <list of your preferred name
servers>;
}
Of course superseding domain name depends on your internal net
configuration.
-Reko
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
>
> Just keep in mind that NetworkManager may meddle with your resolv.conf,
> so you can either keep a watch and manually fix it, or do as I've taken
> to doing and setting the immutable bit with "chattr +i" so it can't be
> changed.
>
>
Looks like resolv.conf is overwritten each time I reboot.
I'll implement your "chattr +i" suggestion after I've convinced
myself that I have a stable solution that works each and every
time.
For now, I'm using the "cp file1 file2" to overwrite resolve.conf
each time I reboot.
Ed
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33983805.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Kris Deugau <kd...@vianet.ca>.
Ed Abbott wrote:
> Here's my "new" resolv.conf:
>
> # Generated by NetworkManager
> domain maine.rr.com
> search maine.rr.com
> # nameserver 209.18.47.61
> # nameserver 209.18.47.62
> nameserver 127.0.0.1
>
> It works! The following test works!
>
> $ cat spam.mbox | spamassassin -dt >temp
>
> In other words, websiterepairguy.com is
> passing all the tests and is no longer generating
> false positives.
>
> The 'spam.mbox' email is the one that was causing
> false positives on the domain 'websiterepairguy.com'.
> It is no longer doing so.
>
> Is it really this simple?
It looks like it - from some of your earlier messages it sounded like
you had already been using a local caching BIND install but were still
getting the bad DNS responses. That would indicate a much deeper level
of DNS meddling; as it is it looks like RR is "just" altering responses
for requests actually sent to their own DNS servers.
Just keep in mind that NetworkManager may meddle with your resolv.conf,
so you can either keep a watch and manually fix it, or do as I've taken
to doing and setting the immutable bit with "chattr +i" so it can't be
changed. (Should you ever need to change an immutable file, "chattr -i
<file>" unsets that bit.) Sadly, setting permissions on resolv.conf to
read-only doesn't seem to lock out anything other than you. :/
-kgd
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Benny Pedersen wrote:
>
> Den 2012-06-08 19:30, Ed Abbott skrev:
>
>> Is it really this simple?
>
> can i hire you now ? :=)
>
Thanks for all your help! You
are the one who should be hired.
Ed
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33983802.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Benny Pedersen wrote:
>
> Den 2012-06-08 19:30, Ed Abbott skrev:
>
>> Is it really this simple?
>
> can i hire you now ? :=)
>
I should hire you! Thanks for all your
help!
Ed
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33983800.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Benny Pedersen wrote:
>
> Den 2012-06-08 19:30, Ed Abbott skrev:
>
>> Is it really this simple?
>
> can i hire you now ? :=)
>
I should hire you! Thanks for all your
help!
Ed
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33983799.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Benny Pedersen wrote:
>
> Den 2012-06-08 19:30, Ed Abbott skrev:
>
>> Is it really this simple?
>
> can i hire you now ? :=)
>
Thanks for all your help! You
are the one who should be hired.
Ed
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33983801.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-08 19:30, Ed Abbott skrev:
> Is it really this simple?
can i hire you now ? :=)
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Axb wrote:
>
> now try:
>
> host incek.ru.multi.uribl.com
>
> you should get
>
> incek.ru.multi.uribl.com has address 127.0.0.2
>
>
Thanks! Here's what happened when I tried what
you suggested:
$ host incek.ru.multi.uribl.com
incek.ru.multi.uribl.com has address 127.0.0.2
Thanks for all the help.
Ed
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33983803.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Axb <ax...@gmail.com>.
On 06/08/2012 07:30 PM, Ed Abbott wrote:
> It works! The following test works!
>
> $ cat spam.mbox | spamassassin -dt>temp
>
> In other words, websiterepairguy.com is
> passing all the tests and is no longer generating
> false positives.
>
> The 'spam.mbox' email is the one that was causing
> false positives on the domain 'websiterepairguy.com'.
> It is no longer doing so.
now try:
host incek.ru.multi.uribl.com
you should get
incek.ru.multi.uribl.com has address 127.0.0.2
> Is it really this simple?
if you get the reply above, it works as expected and and yes, it's
really this simple
Axb
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
>
> Remove the current nameserver entries, and add "nameserver 127.0.0.1".
>
>
Here's my "new" resolv.conf:
# Generated by NetworkManager
domain maine.rr.com
search maine.rr.com
# nameserver 209.18.47.61
# nameserver 209.18.47.62
nameserver 127.0.0.1
It works! The following test works!
$ cat spam.mbox | spamassassin -dt >temp
In other words, websiterepairguy.com is
passing all the tests and is no longer generating
false positives.
The 'spam.mbox' email is the one that was causing
false positives on the domain 'websiterepairguy.com'.
It is no longer doing so.
Is it really this simple?
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33982947.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
>
> OK. The first two lines can stay as-is.
>
> Remove the current nameserver entries, and add "nameserver 127.0.0.1".
>
>
Thank you! You are so kind!
You're telling me how to set up a non-forwarding
DNS server right? By using, 127.0.0.1, I'm using
localhost which is the bind9 I installed the other
day.
Is this what you are saying?
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33982867.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Kris Deugau <kd...@vianet.ca>.
Ed Abbott wrote:
> domain maine.rr.com
> search maine.rr.com
> nameserver 209.18.47.61
> nameserver 209.18.47.62
>
> rr stands for Road Runner and Road
> Runner is my ISP, also known as
> Time-Warner Cable.
OK. The first two lines can stay as-is.
Remove the current nameserver entries, and add "nameserver 127.0.0.1".
(optional) ... then "chattr +i /etc/resolv.conf", so that no (un)helpful
little widget can overwrite your settings and break things. From the
very first time I met something that stuck its fingers into this file, I
have never had any such utility do anything other than break things, so
I now routinely set the "immutable" bit so that anything that tries to
modify the file will fail.
-kgd
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-08 18:23, Ed Abbott skrev:
> I'm sure I'm using the DNS servers for
> my ISP as I've never done anything to
> alter the servers I'm using. Here's my
> /etc/resolv.conf:
[snip]
this is what dynamic clients such as dhcp client will use, servers
should have no problem running there own local dns server that only
listen on 127.0.0.1:53 and in resolv.conf used as nameserver 127.0.0.1
do rr still mangle dns trafic with this setup ?
if thay do, ask them to pay for datafeeds so spamassassin is not
limited for your host
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Benny Pedersen wrote:
>
>
> are you using isp dns servers ?
>
> show /etc/resolv.conf if unsure
>
>
Hi Benny,
Thanks for replying!
I'm sure I'm using the DNS servers for
my ISP as I've never done anything to
alter the servers I'm using. Here's my
/etc/resolv.conf:
# Generated by NetworkManager
domain maine.rr.com
search maine.rr.com
nameserver 209.18.47.61
nameserver 209.18.47.62
rr stands for Road Runner and Road
Runner is my ISP, also known as
Time-Warner Cable.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33982622.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-07 20:04, Ed Abbott skrev:
> It looks like uribl.org is ignoring requests for both of these
> domains and letting them time out. Is this a correct assumption?
are you using isp dns servers ?
show /etc/resolv.conf if unsure
uribl and dnsbl have startede to block dns querries from abbusive dns
forwarders such as google public dns servers, it worked if was less then
10 users abused google :)
best dont use dns servers that is NOT in your own lan
Re: DIrty lying cheating DNS replies (was Re: False Positive on
Domain Name)
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-07 21:03, David F. Skoll skrev:
> It makes ISPs money from search and ad referrals. That's a good
> [sic]
> enough reason to lie to your customers, apparently.
counting how many ips is in spamhaus drop, where isp says thay stopped
bgp routíng to such bastards and in the same time claimed there was no
ipv4 left, and started take money pr ip for soho home users
what a wonderfull world
DIrty lying cheating DNS replies (was Re: False Positive on Domain
Name)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Thu, 07 Jun 2012 14:57:27 -0400
Kris Deugau <kd...@vianet.ca> wrote:
> If that seems clean, it's possible that your ISP has gone to the
> effort of silently redirecting all DNS requests to their own
> servers. (I can't think of any good reasons to do this, but some
> major ISPs seem to get bizarre directives from upper management on a
> regular basis.)
It makes ISPs money from search and ad referrals. That's a good [sic]
enough reason to lie to your customers, apparently.
Regards,
David.
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
>
> A few remote rules rely on other remote lookups (eg, Vipul's Razor, DCC,
> pyzor) but the stock DNS-based rules alone can catch somewhere up to
> about 85-90% of the spam all by themselves, in my experience. And the
> non-DNS rules still rely on DNS lookups to be able to connect to the
> right remote system.
>
> -kgd
>
>
Thank you for your comment on the effectiveness of DNS-based rules.
85-90% is a lot of spam to catch!
I've been relying on local rules only, many of which I've written myself.
Local rules work well if there is something specific I can target, such
as an 800 number.
Non-local rules should work particularly well for me as I only check my
email 1-3 times a day. Therefore, an offending IP address will likely
have been reported by the time I check email. That's what I'm thinking.
Of course, you never get 100 percent. However, catching most spam
is very very helpful.
Ed Abbiott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33979059.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Kris Deugau <kd...@vianet.ca>.
Ed Abbott wrote:
> I've contacted Time-Warner via online chat. Technical support responded
> to my request to turn off DNS forwarding by saying "We don't offer DNS
> forwarding." In other words, they had no idea what I was talking about.
>From the blog link you posted, it sounds like there's an account portal
you can log into somewhere to do this yourself. You may have to climb
the tech support management chain a few layers to find out where it is
if the links in that post don't work for you or if you need to find the
right information to use to log in.
Good luck.
> My general sense is that Time-Warner cable is not going to turn off DNS
> forwarding, otherwise known as DNS hijacking. I used both terms in my
> communication with them.
>
> Any foreseeable problem with using Google Public DNS instead?
Well, you'll see a different class of problem.
Google's public cache servers have been blocked by most of the DNSBLs
for sending too many queries for the free access. You won't get *wrong*
responses, but you won't get much benefit from them either.
> Thanks for all your responses so far. I live in a rural area in Maine,
> USA. I'm in a town of about 20,000 people. Looks like I'm going to
> have to keep my ISP.
:/ All too common in a lot of places. The major cable companies in the
US in particular seem to have managed to avoid having to let resellers
onto their networks.
-kgd
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-08 18:17, Ed Abbott skrev:
> The also said they do not support spamassassin. That's
> understandable.
> However, I wasn't asking them to support spamassassin. I just wanted
> DNS to work properly.
if thay dont want to provide dns for your softare, whats more do thay
dont want to provide ?, will it change when thay get no money ?
> My general sense is that Time-Warner cable is not going to turn off
> DNS
> forwarding, otherwise known as DNS hijacking. I used both terms in
> my
> communication with them.
turn off ?, it first have to be on
> Any foreseeable problem with using Google Public DNS instead?
using shared resources makes shared problems
i love that line
> Thanks for all your responses so far. I live in a rural area in
> Maine,
> USA. I'm in a town of about 20,000 people. Looks like I'm going to
> have to keep my ISP.
can you install bind ?
your isp will not pay uribl or dnsbl, thay only give you access or not
access, same holds true for me when i like to see danish net tv outside
of danmark, tos forbids me on this, even i had payed for access, the
real problem in this is that i cant pay political tos from the owners of
whats sent in danish tv
asside from that dns is truely in same problematic problems when host
in middle dont understand anything on internet is based on working dns
servers
when you have a bind dns server in lo interface listen on 127.0.0.1
only, then dig ipv4.google.com it should show that you are using
127.0.0.1 to make querries to, that possible with any linux os
in /etc/resolv.conf line with nameserver 127.0.0.1
stop using dns forwards, its any ennemy on this problem your isp/host
dont know how to handle, but you pay them ?
Re: False Positive on Domain Name
Posted by John Hardin <jh...@impsec.org>.
On Fri, 8 Jun 2012, Ed Abbott wrote:
> Ed Abbott wrote:
>>
>> I've contacted Time-Warner via online chat. Technical support responded
>> to my request to turn off DNS forwarding by saying "We don't offer DNS
>> forwarding." In other words, they had no idea what I was talking about.
>>
>> Ed Abbott
>
> My error. I meant to say DNS redirection.
>
> I'm not sure which term I used when I talked
> to Time-Warner. I may have used the wrong
> term.
The best term to use is "DNS hijacking". There's no ambiguity in THAT. :)
--
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
-----------------------------------------------------------------------
...in the 2nd amendment the right to arms clause means you have
the right to choose how many arms you want, and the militia clause
means that Congress can punish you if the answer is "none."
-- David Hardy, 2nd Amendment scholar
-----------------------------------------------------------------------
8 days since the first successful private support mission to ISS (SpaceX)
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Ed Abbott wrote:
>
>
> I've contacted Time-Warner via online chat. Technical support responded
> to my request to turn off DNS forwarding by saying "We don't offer DNS
> forwarding." In other words, they had no idea what I was talking about.
>
> Ed Abbott
>
My error. I meant to say DNS redirection.
I'm not sure which term I used when I talked
to Time-Warner. I may have used the wrong
term.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33982836.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Fri, 8 Jun 2012, Benny Pedersen wrote:
> Den 2012-06-08 20:29, Kevin A. McGrail skrev:
>
>> I think we can agree that local caching name server is the correct
>> solution in 99.9% of the cases, yes?
>
> is 0.1% the geek people on spamassassin ? :=)
>
> i just tryin to find where forwards is usefull when dig +trace example.org is
> not using forwards
The 0.1% is for people who manage a site that runs multiple smtp-MX servers.
In that case you set up one "big beefy bind" server with no forwarders
(goes directly to roots and any local data-feed provided DNS sources,
such as a purchased feed of spamhaus).
Then on each smtp-MX server you set up a bind that forwards to your
big-beefy-bind(tm).
That way when a spam run tries multiple MXs for your domain, the first
hit goes MX->BBB-> remote-RBL-or-other-source
then when they hit your next MX server, the RBL queries for that message
are answered by BBB cache so no additional off-site RBL queries.
Hopefully by the time you get to the need for this kind of complexity
you have the knowledge & skill-set to handle it. ;)
Bottom line, if you need trustworthy DNS service don't forward to DNS
servers you don't trust. (kinda like setting your trusted networks in SA).
--
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 Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-08 20:29, Kevin A. McGrail skrev:
> I think we can agree that local caching name server is the correct
> solution in 99.9% of the cases, yes?
is 0.1% the geek people on spamassassin ? :=)
i just tryin to find where forwards is usefull when dig +trace
example.org is not using forwards
it only treverse from "." root zone to dns show via all availble
nameserver what result is, putting any forwars in this chain will give
incorrect answer (dnssec is another problem)
hope rbldnsd will start supporting edns0 in /etc/resolv.conf terms, but
this needs tcp support
Re: False Positive on Domain Name
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 6/8/2012 2:12 PM, Benny Pedersen wrote:
> Den 2012-06-08 18:22, Kevin A. McGrail skrev:
>> On 6/8/2012 12:17 PM, Ed Abbott wrote:
>>> Any foreseeable problem with using Google Public DNS instead?
>>
>> Yes. Google Public DNS can get blocked from RBLs because they end up
>> with too many queries. Your best bet with SA is to use your own local
>> caching nameserver.
>
> blocked is just not the right term, gives 127.0.0.255 will not work if
> its blocked
>
Nuance above the level of the poor guy looking to fix his DNS ;-)
But I used blocked to encompass the concept of not getting correct,
unadultered answers.
I think we can agree that local caching name server is the correct
solution in 99.9% of the cases, yes?
regards,
KAM
Re: False Positive on Domain Name
Posted by Benny Pedersen <me...@junc.org>.
Den 2012-06-08 18:22, Kevin A. McGrail skrev:
> On 6/8/2012 12:17 PM, Ed Abbott wrote:
>> Any foreseeable problem with using Google Public DNS instead?
>
> Yes. Google Public DNS can get blocked from RBLs because they end up
> with too many queries. Your best bet with SA is to use your own
> local
> caching nameserver.
blocked is just not the right term, gives 127.0.0.255 will not work if
its blocked
ups :)
Re: False Positive on Domain Name
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 6/8/2012 12:17 PM, Ed Abbott wrote:
> Any foreseeable problem with using Google Public DNS instead?
Yes. Google Public DNS can get blocked from RBLs because they end up
with too many queries. Your best bet with SA is to use your own local
caching nameserver.
Regards,
KAM
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
>
> Based on that blog link you *should* be able to opt-out of this
> nuisance, and if it keeps coming back, take the path one respondent
> noted about a cron job to request the opt-out on a regular basis (I
> think every 5 minutes is probably overkill, but...)
>
>
Thanks Kris.
I've contacted Time-Warner via online chat. Technical support responded
to my request to turn off DNS forwarding by saying "We don't offer DNS
forwarding." In other words, they had no idea what I was talking about.
The also said they do not support spamassassin. That's understandable.
However, I wasn't asking them to support spamassassin. I just wanted
DNS to work properly.
My general sense is that Time-Warner cable is not going to turn off DNS
forwarding, otherwise known as DNS hijacking. I used both terms in my
communication with them.
Any foreseeable problem with using Google Public DNS instead?
Thanks for all your responses so far. I live in a rural area in Maine,
USA. I'm in a town of about 20,000 people. Looks like I'm going to
have to keep my ISP.
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33982567.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Kris Deugau <kd...@vianet.ca>.
Ed Abbott wrote:
> You are helping clear up a lot of confusion. It seems
> that Time-Warner regularly hijacks DNS. Here's a blog
> post that details the experience of one user:
>
> http://blog.jonudell.net/2010/09/13/hijack-my-dns-and-i-will-be-annoyed-blame-me-and-i-will-go-ballistic/
> I assume, but do not know for sure, that this is a common
> experience. This would also affect my use of spamassassin
> for non-local rules, right?
Any rule that relies on DNS lookups, yes. :(
A few remote rules rely on other remote lookups (eg, Vipul's Razor, DCC,
pyzor) but the stock DNS-based rules alone can catch somewhere up to
about 85-90% of the spam all by themselves, in my experience. And the
non-DNS rules still rely on DNS lookups to be able to connect to the
right remote system.
Based on that blog link you *should* be able to opt-out of this
nuisance, and if it keeps coming back, take the path one respondent
noted about a cron job to request the opt-out on a regular basis (I
think every 5 minutes is probably overkill, but...)
If that fails, and if it's at all an option... take your Internet
access business elsewhere.
-kgd
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
Kris Deugau wrote:
>
>
> Checking the IPs returned above in a browser redirects to a Road Runner
> page that indicates they're definitely meddling with DNS responses at
> some level. :( You noted in another message you're on Time-Warner
> cable; I'm not familiar with the reseller agreements US ISPs might have
> but at some level you're getting responses from a Road Runner system. I
> don't know if there's a way you can "opt out" of this.
>
> -kgd
>
>
Thank you Kris!
You are helping clear up a lot of confusion. It seems
that Time-Warner regularly hijacks DNS. Here's a blog
post that details the experience of one user:
http://blog.jonudell.net/2010/09/13/hijack-my-dns-and-i-will-be-annoyed-blame-me-and-i-will-go-ballistic/
Same thing as a tiny URL:
http://tinyurl.com/37cltzk
I assume, but do not know for sure, that this is a common
experience. This would also affect my use of spamassassin
for non-local rules, right?
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33977956.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by Kris Deugau <kd...@vianet.ca>.
Ed Abbott wrote:
> $ host websiterepairguy.com.multi.surbl.org
> websiterepairguy.com.multi.surbl.org has address 184.106.15.239
> websiterepairguy.com.multi.surbl.org has address 69.16.143.110
> Host websiterepairguy.com.multi.surbl.org not found: 3(NXDOMAIN)
The first two responses here indicate something *very* wrong with the
results you're getting on DNS lookups.
URI and IP blacklists, by convention, return an IP in 127.0.0.0/8 - ie,
an IP between 127.0.0.0 and 127.255.255.255. Exactly what is returned
depends on the list and how they combine multiple logical lists into a
single set of DNS data.
John Hardin's advice about checking your resolv.conf and BIND
configuration to make sure it's really doing its own work instead of
just passing the requests to your ISP's DNS cache servers is the next
thing to check.
A caching-only BIND configuration should be pretty bare (apart from
commented-out directives - lines with a leading '//' or ';' ) but in
particular for this problem, there should be no "forwarders" sections.
If that seems clean, it's possible that your ISP has gone to the effort
of silently redirecting all DNS requests to their own servers. (I can't
think of any good reasons to do this, but some major ISPs seem to get
bizarre directives from upper management on a regular basis.)
Checking the IPs returned above in a browser redirects to a Road Runner
page that indicates they're definitely meddling with DNS responses at
some level. :( You noted in another message you're on Time-Warner
cable; I'm not familiar with the reseller agreements US ISPs might have
but at some level you're getting responses from a Road Runner system. I
don't know if there's a way you can "opt out" of this.
-kgd
Re: False Positive on Domain Name
Posted by Ed Abbott <we...@gmail.com>.
John Hardin wrote:
>
>
> It would also be useful if (before changing your config) you provided the
> results of DNSBL lookups at your site for some large known-clean domains
> like google.com, microsoft.com, etc. If they are all FPing, then the
> problem is as I stated above and the fix is straightforward. If not, then
> more investigation is warranted.
>
>
Thank you John!
Not sure if I'm fulfilling your request or not, but here is my best attempt
so far:
$ host google.com.multi.uribl.com
;; connection timed out; no servers could be reached
$ host google.com.multi.surbl.org
Host google.com.multi.surbl.org not found: 3(NXDOMAIN)
$ host microsoft.com.multi.surbl.org
Host microsoft.com.multi.surbl.org not found: 3(NXDOMAIN)
$ host microsoft.com.multi.surbl.org
Host microsoft.com.multi.surbl.org not found: 3(NXDOMAIN)
$ host websiterepairguy.com.multi.uribl.com
;; connection timed out; no servers could be reached
$ host websiterepairguy.com.multi.surbl.org
websiterepairguy.com.multi.surbl.org has address 184.106.15.239
websiterepairguy.com.multi.surbl.org has address 69.16.143.110
Host websiterepairguy.com.multi.surbl.org not found: 3(NXDOMAIN)
It looks like google.com and websiterepairguy.com have something in
common. It looks like uribl.org is ignoring requests for both of these
domains and letting them time out. Is this a correct assumption?
Ed Abbott
--
View this message in context: http://old.nabble.com/False-Positive-on-Domain-Name-tp33975030p33977290.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: False Positive on Domain Name
Posted by John Hardin <jh...@impsec.org>.
On Thu, 7 Jun 2012, Kris Deugau wrote:
> Ed Abbott wrote:
>
>> My domain name, websiterepairguy.com, is causing
>> spamassassin to give a false positive.
>
> Checking from where I'm sitting, I don't see it listed.
>
> If you're still getting hits on these rules there's a good chance that
> the DNS cache you're using is either modifying the negative results (ie,
> similar to http://www.surbl.org/faqs#opendns) or has been making too
> many requests to SURBL, and is now either receiving "yes it's listed"
> for any request, or is generating that response for some reason.
>
> As a local workaround (since your domain doesn't seem to be listed
> currently), I suggest adding "uridnsbl_skip_domain websiterepairguy.com"
> to your SpamAssassin config - that will skip doing URI blacklist lookups
> altogether on your domain.
If Ed's experiencing DNS problems such that his domain is getting FPs,
then likely _all other domains_ are also getting FPs at his site, and that
workaround is only a minimal bandaid for a large problem.
It's considered best practice to set up a local, caching, non-forwarding
DNS server for use with SA and (in general) any MTA doing DNS-based
blocklist lookups. As has been stated, many BL providers set volume limits
on free access to their data, and if you're forwarding to a public DNS
server (e.g. Google DNS) then you're likely relying on a DNS server that
is, in aggregate with all its other users, exceeding those limits and thus
providing inaccurate results.
Set up a local, caching, non-forwarding DNS server on your MTA/SA host and
configure your MTA and SA to use it. This need not necessarily affect the
DNS resolution for other hosts on your local network, which could still
forward DNS requests to your chosen upstream DNS provider.
Ed, you said you've already installed BIND, that covers the "local,
caching" part. Now configure it to not forward requests.
It would also be useful if (before changing your config) you provided the
results of DNSBL lookups at your site for some large known-clean domains
like google.com, microsoft.com, etc. If they are all FPing, then the
problem is as I stated above and the fix is straightforward. If not, then
more investigation is warranted.
--
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
-----------------------------------------------------------------------
...for a nation to tax itself into prosperity is like a man
standing in a bucket and trying to lift himself up by the handle.
-- Winston Churchill
-----------------------------------------------------------------------
7 days since the first successful private support mission to ISS (SpaceX)
Re: False Positive on Domain Name
Posted by Kris Deugau <kd...@vianet.ca>.
Ed Abbott wrote:
>
> My domain name, websiterepairguy.com, is causing
> spamassassin to give a false positive.
>
> Here are the tests that all give a false positive for
> websiterepairguy.com:
>
> 1.5 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
> 0.6 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
> 4.5 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
> 1.6 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
> 1.2 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
> 0.6 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
>
> I've checked here to see if my domain is blocked:
>
> https://admin.uribl.com/
This only applies to the first rule; the rest are part of a different list:
http://www.surbl.org
Checking from where I'm sitting, I don't see it listed.
If you're still getting hits on these rules there's a good chance that
the DNS cache you're using is either modifying the negative results (ie,
similar to http://www.surbl.org/faqs#opendns) or has been making too
many requests to SURBL, and is now either receiving "yes it's listed"
for any request, or is generating that response for some reason.
As a local workaround (since your domain doesn't seem to be listed
currently), I suggest adding "uridnsbl_skip_domain websiterepairguy.com"
to your SpamAssassin config - that will skip doing URI blacklist lookups
altogether on your domain.
-kgd