You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by fr...@ofb.net on 2017/01/23 19:19:03 UTC
how to tell when DNS is not working
Hi Spamassassin Developers,
I think I have a problem where my ISP DNS servers are being blocked by
various DNSBLs, and when that happens Spamassassin starts letting
through a lot of obvious spam messages.
However, it was somewhat difficult to debug this. I had to ask the
Spamassassin Users mailing list for help and they pointed me to the
likely problem. From the point of view of someone who hasn't written
to the mailing list yet, unless I'm missing something, a user has some
very long documentation and a very uninformative header:
X-Spam-Status: No, score=2.7 required=5.0 tests=BAYES_60,
HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MIME_HTML_MOSTLY,RDNS_NONE, T_SPF_HELO_TEMPERROR,T_SPF_TEMPERROR
autolearn=no autolearn_force=no version=3.4.1
They can also run 'spamassassin -D' and read the copious output, but
unless they know what they're looking for it's difficult to find and
understand the lines which (I think) are relevant:
Jan 20 14:27:45.623 [9273] dbg: async: aborting after 10.581 s, past original deadline: DNSBL-A, dns:A:132.249.155.179.bl.score.senderscore.com
Jan 20 14:27:45.623 [9273] dbg: async: aborting after 11.535 s, past original deadline: URI-A, A:gallery.mailchimp.com
Jan 20 14:27:45.623 [9273] dbg: async: aborting after 12.954 s, past original deadline: URIBL_RHS_DOB, URI-DNSBL, DNSBL:mailchimp.com:dob.sibl.support-intelligence.net
Jan 20 14:27:45.623 [9273] dbg: async: aborting after 10.016 s, past original deadline: DNSBL-TXT, dns:TXT:132.249.155.179.sa-trusted.bondedsender.org
Jan 20 14:27:45.623 [9273] dbg: async: aborting after 10.018 s, past original deadline: DNSBL-A, dns:A:132.249.155.179.list.dnswl.org
Jan 20 14:27:45.624 [9273] dbg: async: aborting after 12.949 s, past original deadline: URIBL_DBL_ABUSE_MALW, URI-DNSBL, DNSBL:mailchimp.com:dbl.spamhaus.org
Can we do something to make it clearer to users when the DNSBL checks
(which form the backbone of Spamassassin AIUI) have suddenly stopped
working? Should I submit a feature request for this in Bugzilla? I
think that it would make sense to add a rule with zero score to
indicate when a DNS query has timed out, and/or a header explaining
the situation. That way, someone perusing their X-Spam-Status headers
will know what the problem is...
Thanks,
Frederick
Re: how to tell when DNS is not working
Posted by John Hardin <jh...@impsec.org>.
On Tue, 24 Jan 2017, RW wrote:
> On Tue, 24 Jan 2017 08:38:44 -0800 (PST)
> John Hardin wrote:
>
>> On Tue, 24 Jan 2017, RW wrote:
>>
>>> On Tue, 24 Jan 2017 00:04:16 -0800
>>> frederik@ofb.net wrote:
>>>
>>>> Thanks for the replies.
>>>>
>>>> Should I open a bugzilla bug for this?
>>>>
>>>> I remember seeing URIBL_BLOCKED once.
>>>>
>>>> But lately it doesn't appear. I'm not sure what would go in "||
>>>> etc."
>>>
>>> The others misunderstood what you are asking for,
>>
>> I understood what he was asking.
>
> I was giving you benefit of the doubt.
>
>> The "etc" in my (humorous) proposed
>> solution was a test for DNS timeouts, which I haven't looked into.
>>
>>> it can't be done that way,
>>
>> Because DNS timeout errors aren't exposed to an eval?
>
> I meant that there's nothing that can currently complete the meta rule.
Not surprising.
>>> and it's not sensible anyway.
>>
>> Why not? Informational rules could help troubleshooting, especially
>> if you don't have access to the server logs.
>
> It's not sensible to have an informational rule that's triggered by
> URIBL_BLOCKED or packet loss and have it tell the user not to use a
> public cache.
Given the queries that regularly pop up on the users list, I would suggest
that such a rule for URIBL_BLOCKED at least *would* be helpful. I agree
that it may be a stretch to assume DNS timeouts are due to using an
inappropriate forwarded.
--
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
-----------------------------------------------------------------------
USMC Rules of Gunfighting #2: Anything worth shooting is worth
shooting twice. Ammo is cheap. Your life is expensive.
-----------------------------------------------------------------------
3 days until the 50th anniversary of the loss of Apollo 1
Re: how to tell when DNS is not working
Posted by fr...@ofb.net.
Hi Marc,
No I've already done that. The confusing part for me about RW's email
was that he criticized my proposed solution without acknowledging the
problem it was trying to solve. Simply saying "it's not sensible"
doesn't tell us where to go from here. Usually people propose an
alternative solution, or explain why the problem is not important, or
explain in more detail what the proposed solution would entail. The
main point was that there is a problem, and RW did not acknowledge
this. He didn't even explain why he thought the solution was not
sensible. That's not facilitative.
John Hardin (last email on thread) acknowledged one of RW's points and
re-explained the existence of a problem, but I felt this to be
overgenerous. I felt that if RW wanted to say something, he should try
again. Not that there didn't seem to be glimmers of something useful -
how did he know that most of the look-ups were successful? But on the
whole his emails failed to demonstrate an understanding of what *I*
was saying. Rather than wasting everyone's time re-explaining myself I
just told him I wasn't getting it.
I don't know who RW is or what relationship any of the people I've
been in communication with have to the maintainer of this project.
FWIW, nobody has answered my question of whether I should submit a bug
report on Bugzilla.
Thanks.
On Mon, Jan 30, 2017 at 03:17:11AM -0800, Marc Perkel wrote:
> I think that they are suggesting is that you set up your own DNS server. and
> it's a good suggestion. I use PowerDNS.
>
> On 01/24/17 15:31, frederik@ofb.net wrote:
> > RW, I'm not really understanding you either. You seem to enjoy keeping
> > people guessing...
> >
> > On Tue, Jan 24, 2017 at 06:46:16PM +0000, RW wrote:
> > > On Tue, 24 Jan 2017 08:38:44 -0800 (PST)
> > > John Hardin wrote:
> > >
> > > > On Tue, 24 Jan 2017, RW wrote:
> > > >
> > > > > On Tue, 24 Jan 2017 00:04:16 -0800
> > > > > frederik@ofb.net wrote:
> > > > > > Thanks for the replies.
> > > > > >
> > > > > > Should I open a bugzilla bug for this?
> > > > > >
> > > > > > I remember seeing URIBL_BLOCKED once.
> > > > > >
> > > > > > But lately it doesn't appear. I'm not sure what would go in "||
> > > > > > etc."
> > > > > The others misunderstood what you are asking for,
> > > > I understood what he was asking.
> > > I was giving you benefit of the doubt.
> > >
> > > > The "etc" in my (humorous) proposed
> > > > solution was a test for DNS timeouts, which I haven't looked into.
> > > >
> > > > > it can't be done that way,
> > > > Because DNS timeout errors aren't exposed to an eval?
> > >
> > > I meant that there's nothing that can currently complete the meta rule.
> > >
> > >
> > > > > and it's not sensible anyway.
> > > > Why not? Informational rules could help troubleshooting, especially
> > > > if you don't have access to the server logs.
> > > It's not sensible to have an informational rule that's triggered by
> > > URIBL_BLOCKED or packet loss and have it tell the user not to use a
> > > public cache.
> > >
> >
>
> --
> Marc Perkel - Sales/Support
> support@junkemailfilter.com
> http://www.junkemailfilter.com
> Junk Email Filter dot com
> 415-992-3400
>
Re: how to tell when DNS is not working
Posted by fr...@ofb.net.
RW, I'm not really understanding you either. You seem to enjoy keeping
people guessing...
On Tue, Jan 24, 2017 at 06:46:16PM +0000, RW wrote:
> On Tue, 24 Jan 2017 08:38:44 -0800 (PST)
> John Hardin wrote:
>
> > On Tue, 24 Jan 2017, RW wrote:
> >
> > > On Tue, 24 Jan 2017 00:04:16 -0800
> > > frederik@ofb.net wrote:
> > >
> > >> Thanks for the replies.
> > >>
> > >> Should I open a bugzilla bug for this?
> > >>
> > >> I remember seeing URIBL_BLOCKED once.
> > >>
> > >> But lately it doesn't appear. I'm not sure what would go in "||
> > >> etc."
> > >
> > > The others misunderstood what you are asking for,
> >
> > I understood what he was asking.
>
> I was giving you benefit of the doubt.
>
> > The "etc" in my (humorous) proposed
> > solution was a test for DNS timeouts, which I haven't looked into.
> >
> > > it can't be done that way,
> >
> > Because DNS timeout errors aren't exposed to an eval?
>
>
> I meant that there's nothing that can currently complete the meta rule.
>
>
> > > and it's not sensible anyway.
> >
> > Why not? Informational rules could help troubleshooting, especially
> > if you don't have access to the server logs.
>
> It's not sensible to have an informational rule that's triggered by
> URIBL_BLOCKED or packet loss and have it tell the user not to use a
> public cache.
>
Re: how to tell when DNS is not working
Posted by RW <rw...@googlemail.com>.
On Tue, 24 Jan 2017 08:38:44 -0800 (PST)
John Hardin wrote:
> On Tue, 24 Jan 2017, RW wrote:
>
> > On Tue, 24 Jan 2017 00:04:16 -0800
> > frederik@ofb.net wrote:
> >
> >> Thanks for the replies.
> >>
> >> Should I open a bugzilla bug for this?
> >>
> >> I remember seeing URIBL_BLOCKED once.
> >>
> >> But lately it doesn't appear. I'm not sure what would go in "||
> >> etc."
> >
> > The others misunderstood what you are asking for,
>
> I understood what he was asking.
I was giving you benefit of the doubt.
> The "etc" in my (humorous) proposed
> solution was a test for DNS timeouts, which I haven't looked into.
>
> > it can't be done that way,
>
> Because DNS timeout errors aren't exposed to an eval?
I meant that there's nothing that can currently complete the meta rule.
> > and it's not sensible anyway.
>
> Why not? Informational rules could help troubleshooting, especially
> if you don't have access to the server logs.
It's not sensible to have an informational rule that's triggered by
URIBL_BLOCKED or packet loss and have it tell the user not to use a
public cache.
Re: how to tell when DNS is not working
Posted by John Hardin <jh...@impsec.org>.
On Tue, 24 Jan 2017, RW wrote:
> On Tue, 24 Jan 2017 00:04:16 -0800
> frederik@ofb.net wrote:
>
>> Thanks for the replies.
>>
>> Should I open a bugzilla bug for this?
>>
>> I remember seeing URIBL_BLOCKED once.
>>
>> But lately it doesn't appear. I'm not sure what would go in "|| etc."
>
> The others misunderstood what you are asking for,
I understood what he was asking. The "etc" in my (humorous) proposed
solution was a test for DNS timeouts, which I haven't looked into.
> it can't be done that way,
Because DNS timeout errors aren't exposed to an eval?
> and it's not sensible anyway.
Why not? Informational rules could help troubleshooting, especially if you
don't have access to the server logs.
> What you saw was probably just
> some packet loss, most of the look-ups were successful.
Which suggests any such rule should trigger on > 50% DNS failures, rather
than just *any* DNS failures...
--
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 IV: Close air support covereth a multitude of sins.
-----------------------------------------------------------------------
3 days until the 50th anniversary of the loss of Apollo 1
Re: how to tell when DNS is not working
Posted by RW <rw...@googlemail.com>.
On Tue, 24 Jan 2017 00:04:16 -0800
frederik@ofb.net wrote:
> Thanks for the replies.
>
> Should I open a bugzilla bug for this?
>
> I remember seeing URIBL_BLOCKED once.
>
> But lately it doesn't appear. I'm not sure what would go in "|| etc."
The others misunderstood what you are asking for, it can't be done that
way, and it's not sensible anyway. What you saw was probably just
some packet loss, most of the look-ups were successful.
Just setup a local resolver such as unbound, powerdns etc, and let it do
its look-ups directly, without setting-up forwarding to a DNS cache.
Re: how to tell when DNS is not working
Posted by fr...@ofb.net.
Thanks for the replies.
Should I open a bugzilla bug for this?
I remember seeing URIBL_BLOCKED once.
But lately it doesn't appear. I'm not sure what would go in "|| etc."
----------------
By the way I have a question on Stack Exchange about the correct bind
configuration etc., with no answers yet:
http://unix.stackexchange.com/questions/339009/how-to-configure-bind-for-spamassassin
I'm not sure if I should delete the question or what. I was hoping to
inspire someone to improve upon
https://wiki.apache.org/spamassassin/CachingNameserver ... I tried to
follow those instructions but just got bogged down reading
documentation for programs I never use, like resolvconf.
On Mon, Jan 23, 2017 at 03:02:36PM -0500, Kevin A. McGrail wrote:
> On 1/23/2017 2:49 PM, John Hardin wrote:
> > Ooo, I like it.
> >
> > meta STOP_USING_PUBLIC_OR_ISP_DNS_SERVERS URIBL_BLOCKED || etc.
> > score STOP_USING_PUBLIC_OR_ISP_DNS_SERVERS 0.0001 # informative
>
> +0.00001 for me as well ;-)
>
>
Re: how to tell when DNS is not working
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 1/23/2017 2:49 PM, John Hardin wrote:
> Ooo, I like it.
>
> meta STOP_USING_PUBLIC_OR_ISP_DNS_SERVERS URIBL_BLOCKED || etc.
> score STOP_USING_PUBLIC_OR_ISP_DNS_SERVERS 0.0001 # informative
+0.00001 for me as well ;-)
Re: how to tell when DNS is not working
Posted by John Hardin <jh...@impsec.org>.
On Mon, 23 Jan 2017, frederik@ofb.net wrote:
> Can we do something to make it clearer to users when the DNSBL checks
> (which form the backbone of Spamassassin AIUI) have suddenly stopped
> working?
> I think that it would make sense to add a rule with zero score to
> indicate when a DNS query has timed out, and/or a header explaining
> the situation. That way, someone perusing their X-Spam-Status headers
> will know what the problem is...
Ooo, I like it.
meta STOP_USING_PUBLIC_OR_ISP_DNS_SERVERS URIBL_BLOCKED || etc.
score STOP_USING_PUBLIC_OR_ISP_DNS_SERVERS 0.0001 # informative
:)
--
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
-----------------------------------------------------------------------
Teach a man to fish, and he'll eat for life.
Give him someone else's fish, and he'll vote for you.
-----------------------------------------------------------------------
Today: John Moses Browning's 162nd Birthday