Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

[Joe Quinn]

On 1/4/2016 3:39 PM, Quanah Gibson-Mount wrote:
--On Monday, January 04, 2016 8:28 PM + Chris J 
 wrote:



Before I raise this on Bugzilla, I just want to run this past people as
I'm quite happy that I've failed to configure something, but can't see
what.

In short, RBL blacklists haven't been working and I've finally, with
tcpdump, traced it to SpamAssassin not requesting recursive queries.

The setup is:
Linux - Debian Jessie 8.2
Bind - 9.9.5-9+deb8u3-Debian
SpamAssassin - installed from CPAN, 3.4.1
Perl - 5.20.2
Net::DNS - 1.01


If you're using Net::DNS 1.01 or later, you must patch SA.  There is 
an entire thread dedicated to this issue.






7265 is only required for 1.03 (not necessary for 1.01, 1.02, or 1.04).

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
By the way, have you considered subscribing to the dev@ list and 
contributing to SA? You ran through this issue pretty much perfectly, 
other than the bad luck with our Bugzilla's results on Google.

DNS lookups - bug with recursive lookups, or shoddy bind config?

[Chris J]

Before I raise this on Bugzilla, I just want to run this past people as 
I'm quite happy that I've failed to configure something, but can't see what.


In short, RBL blacklists haven't been working and I've finally, with 
tcpdump, traced it to SpamAssassin not requesting recursive queries.


The setup is:
Linux - Debian Jessie 8.2
Bind - 9.9.5-9+deb8u3-Debian
SpamAssassin - installed from CPAN, 3.4.1
Perl - 5.20.2
Net::DNS - 1.01

Bind running locally, /etc/resolv.conf pointing to 127.0.0.1.

When running spamassassin -D dns < spam.test > /dev/null, all the DNS 
blacklist queries return 0 results, taking an extract:


Jan  4 20:13:11.853 [21025] dbg: dns: attempt 1/1, trying connect/sendto 
to [127.0.0.1]:53
Jan  4 20:13:11.854 [21025] dbg: dns: providing a callback for id: 
60328/IN/A/123.119.167.104.DnSBl.iNpS.DE

[...]
Jan  4 20:13:11.914 [21025] dbg: dns: dns reply 60328 is OK, 0 answer 
records


However, that entry does have a record:
$ host 123.119.167.104.DnSBl.iNpS.DE
123.119.167.104.dnsbl.inps.de has address 127.0.0.2
$

Looking at tcpdump, it shows me this from SpamAssassin:

20:17:28.932550 IP localhost.20171 > localhost.domain: 51533 [1au] A? 
123.119.167.104.dNsbL.InPS.de. (58)

20:17:28.932622 IP localhost.domain > localhost.20171: 51533 0/2/3 (150)

But with host, I get:

20:18:16.828275 IP localhost.56176 > localhost.domain: 16674+ A? 
123.119.167.104.DnSBl.iNpS.DE. (47)
20:18:16.845783 IP localhost.domain > localhost.56176: 16674 1/2/2 A 
127.0.0.2 (179)


I've done some poking, and the '+' after the query number marks it as 
recursive. I can confirm this with "dig +norecurse".


Looking through the code, and looking at things from Google, it appears 
Net::DNS should be doing recursive queries by default, but the code 
that's doing the query is Net::DNS::Packet. I've made a change to 
DnsResolver.pm (line 578) as below, and now SpamAssassin is doing 
recursive queries, and my DNS blacklists work:


$domain =~ s{ ( [\000-\037\177-\377\\] ) }
{ $1 eq '\\' ? "\\$1" : sprintf("\\%03d",ord($1)) }xgse;

$packet = Net::DNS::Packet->new($domain, $type, $class);
#CEJ: set RD bit to force recursion
$packet->header->rd(1);

With this, the DNS debug log now says:

Jan  4 20:24:14.250 [21122] dbg: dns: providing a callback for id: 
53008/IN/A/123.119.167.104.dNSBl.iNps.dE
Jan  4 20:24:14.309 [21122] dbg: dns: dns reply 53008 is OK, 1 answer 
records
Jan  4 20:24:14.309 [21122] dbg: dns: hit 
 127.0.0.2


Now I'm doubtful I've found a bug as I'm sure I'd see more problems 
having spent a while searching interwebs. It could be my Bind config? 
But the SA wiki just says the default config of Bind from the Debian 
releases should be good 
(https://wiki.apache.org/spamassassin/CachingNameserver ).


Let me know if any more information (config files, etc) are needed and I 
can supply.


Regards,

Chris

sa-update not updating the rules

[Muthu N.C]

I am using the version 3.4.1 spamassassin. I am running sa-update to update
the rules. The rules stopped updating after Dec 21st. Below is the output
when running with debug mode..Any help on getting the latest update of the
rulls will be helpful.

Jan  4 13:55:47.210 [8531] dbg: util: secure_tmpfile created a temporary
file /tmp/.spamassassin85313z6Z0mtmp
Jan  4 13:55:47.210 [8531] dbg: channel: attempting channel
updates.spamassassin.org
Jan  4 13:55:47.210 [8531] dbg: channel: using existing directory
/var/lib/spamassassin/3.004001/updates_spamassassin_org
Jan  4 13:55:47.210 [8531] dbg: channel: channel cf file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Jan  4 13:55:47.211 [8531] dbg: channel: channel pre file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
Jan  4 13:55:47.211 [8531] dbg: channel: metadata version = 1720996, from
file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Jan  4 13:55:47.225 [8531] dbg: dns: 1.4.3.updates.spamassassin.org =>
1720996, parsed as 1720996
Jan  4 13:55:47.226 [8531] dbg: channel: current version is 1720996, new
version is 1720996, skipping channel
Jan  4 13:55:47.226 [8531] dbg: diag: updates complete, exiting with code 1


Thanks,
Muthu.

Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

[Quanah Gibson-Mount]

--On Monday, January 04, 2016 8:28 PM + Chris J  
wrote:



Before I raise this on Bugzilla, I just want to run this past people as
I'm quite happy that I've failed to configure something, but can't see
what.

In short, RBL blacklists haven't been working and I've finally, with
tcpdump, traced it to SpamAssassin not requesting recursive queries.

The setup is:
Linux - Debian Jessie 8.2
Bind - 9.9.5-9+deb8u3-Debian
SpamAssassin - installed from CPAN, 3.4.1
Perl - 5.20.2
Net::DNS - 1.01


If you're using Net::DNS 1.01 or later, you must patch SA.  There is an 
entire thread dedicated to this issue.






7265 is only required for 1.03 (not necessary for 1.01, 1.02, or 1.04).

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

[Chris J]

On 04/01/2016 20:39, Quanah Gibson-Mount wrote:


If you're using Net::DNS 1.01 or later, you must patch SA.  There is an
entire thread dedicated to this issue.





7265 is only required for 1.03 (not necessary for 1.01, 1.02, or 1.04).



Magic - thanks. Google wouldn't spit out that Bugzilla issue - only 
found old threads about DNSBL not working, and couldn't see anything on 
the SA wiki about it.


http://wiki.apache.org/spamassassin/DnsBlocklists only makes reference 
to "make sure Net::DNS is installed".


Thanks for the pointer to the right bug :-)

Cheers,

Chris

Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

[Chris J]

On 04/01/2016 20:48, Joe Quinn wrote:

By the way, have you considered subscribing to the dev@ list and
contributing to SA? You ran through this issue pretty much perfectly,
other than the bad luck with our Bugzilla's results on Google.


Time is my main issue (that and being a rather rusty with perl) :-) 
Although looking at the archives, it's fairly low traffic so yes, I'll 
throw a subscription in and see how it goes.


Cheers,

Chris

Re: RDNS_NONE always being triggered

[RW]

On Mon, 04 Jan 2016 11:40:23 +0100
a.sm...@ldexgroup.co.uk wrote:

>  
> 
> Hi, 
> 
>   I'm using Spamassassin 3.4.1 on FreeBSD 9.3, called via a pipe from
> Exim. Today I created a meta rule to give additional points to
> FREEMAIL where also there is no RDNS. What I've noticed is that many
> emails are triggering RDNS_NONE when I don't think they should. DNS
> lookups are working normally on the host server. 
> 
> ...
> Can anyone help me out? I'd have thought the rule should just check
> 98.138.229.47 and trigger if there is no PTR but that doesn't seem to
> be the case,

No look-up is done. RDNS_NONE tests whether rdns is recorded in the
received header. You need either to turn it on or turn the rule off. 

RDNS_NONE always being triggered

[a . smith]

 

Hi, 

  I'm using Spamassassin 3.4.1 on FreeBSD 9.3, called via a pipe from
Exim. Today I created a meta rule to give additional points to FREEMAIL
where also there is no RDNS. What I've noticed is that many emails are
triggering RDNS_NONE when I don't think they should. DNS lookups are
working normally on the host server. 

Here is the header from a sample I sent from Yahoo webmail: 

X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
mx0.ldex.co.uk
X-Spam-Level: ***
X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_20,
FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_NORDNS,
   
FREEMAIL_REPLYTO_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,
RDNS_NONE autolearn=no autolearn_force=no version=3.4.1
Received: from [98.138.229.47] (port=49947
helo=nm31-vm7.bullet.mail.ne1.yahoo.com)
by mx0.ldex.co.uk with esmtps (Exim 4.86; FreeBSD;
TLSv1:RC4-SHA:128)
envelope-from smithacs99-9 at yahoo.co.uk
envelope-to a.smith at ldexgroup.co.uk
id 1aG2l0-000H3E-5O; Mon, 04 Jan 2016 10:52:58 +
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk;
s=s2048; t=1451904781; bh=ymt+hiijroygXfLWWaa7Na6ZpWmHmnAPJBYOj95L728=;
h=Date:From:Reply-To:To:Subject:References:From:Subject;
b=uHu+ErCJz+GJMm7uXkp654a16FdZgN2LOPzHDZc0epf/3OLIbr7T4V+Cj3dq7m6PrOTrWqzElwpZIk23RiRYWCRiTRqsNaPkZZlbm4304KejMFtYlByzhpNwsIzqsgZjYJTFJQEONnxtnGmcdgcqTMuCF7yECp+7Tch6GWjyg4e3uLrqEcmPOI04qSM3HAI9zFS692RPESBiaS2OrWjXksVYrHh4owP6mNp9B0+gXCeEdktJbtO1RauzaQrtPlDaVFeqnoPviEOZeqflZmYGFVECu5LFAL/ssuOHK+ZblnaREQqX0Rs6CG5IwOu0m8mVGsWgVlIbV66EZb9lhNBcUA==
Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP;
04 Jan 2016 10:53:01 -
Received: from [98.138.100.112] by nm31.bullet.mail.ne1.yahoo.com with
NNFMP; 04 Jan 2016 10:50:05 -
Received: from [212.82.98.51] by tm103.bullet.mail.ne1.yahoo.com with
NNFMP; 04 Jan 2016 10:50:05 -
Received: from [212.82.98.97] by tm4.bullet.mail.ir2.yahoo.com with
NNFMP; 04 Jan 2016 10:50:05 -
Received: from [127.0.0.1] by omp1034.mail.ir2.yahoo.com with NNFMP; 04
Jan 2016 10:50:05 -
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 458845.8640...@omp1034.mail.ir2.yahoo.com
X-YMail-OSG:
E532nb8VM1kuGdNbXrO1mJ0SAzE4q8uo1Lukth0Oa3aA1qIIv0xC2yizI0YcBuE

EtOhtZaC2qlek5XbEL1zIvmGFdFh1ulVa1i3Y_jpLYHtBu4VBoCzFJipWgggAHGh3GzFu7F.MRp.

RwP_vkFEYW8_ku9C_Zi_IcA6cYSHbto2ANs2h2t9wTfb3kFQ5MMq3rXAMMfAZHAqCalp_hJD45Xu

8Mc2vi.X.AlYiprxQ4hNrfbKM5KmL.FU3IYo5aQhaPo7l.q3uilngZ8Lo3xkD6PRtS9PrnXn33tV

ZCRrZZ_lw7ceYd0mzeFe3pi8MfLK_L5QGi65WmPRBtPo8lE6cupVI1fch4fA1rTZ2hhlU2n22r0y

.yGjd2KbxLKJFLbVzz0kN8DKmUBU5hVWY3U4gC_ubNJBFPjRfBosPeISgsQpV7A1Slv49SYWgId1

_OFz1h_rIFQSenGakPUzVt3lYhzixUBo6zRWjpyq8nQF6fA6U1S4tpmd_2HI5gsQKs4ZUhIhrsIR
 SXlFZ.gW7iWWqIEvpj0CBvjs-
Received: by 217.12.9.10; Mon, 04 Jan 2016 10:50:04 + 

Can anyone help me out? I'd have thought the rule should just check
98.138.229.47 and trigger if there is no PTR but that doesn't seem to be
the case,

thanks in advance, Andy. 

  

Re: sa-update not updating the rules

[Kevin A. McGrail]

On 1/4/2016 4:37 PM, Muthu N.C wrote:
It looks there are latest version of rules available greater than 
1720996. But I am not getting that rules. I am seeing now lot of spam 
emails comes through.


I see on the below link there are latest version of rules exist.

http://ruleqa.spamassassin.org/?longdatelist=1=99#r20160104_r1722797_n

Do I need to subscribed to any other channels to get the update?
Sorry but the rule sets aren't published to the world if they don't pass 
QA.


regards,
KAM

Re: sa-update not updating the rules

[Muthu N.C]

It looks there are latest version of rules available greater than 1720996.
But I am not getting that rules. I am seeing now lot of spam emails comes
through.

I see on the below link there are latest version of rules exist.

http://ruleqa.spamassassin.org/?longdatelist=1=99#r20160104_r1722797_n

Do I need to subscribed to any other channels to get the update?

Thanks,
Muthu.

On Mon, Jan 4, 2016 at 2:24 PM, Kevin A. McGrail  wrote:

> On 1/4/2016 4:18 PM, Muthu N.C wrote:
>
> I am using the version 3.4.1 spamassassin. I am running sa-update to
> update the rules. The rules stopped updating after Dec 21st. Below is the
> output when running with debug mode..Any help on getting the latest update
> of the rulls will be helpful.
>
> Jan  4 13:55:47.210 [8531] dbg: util: secure_tmpfile created a temporary
> file /tmp/.spamassassin85313z6Z0mtmp
> Jan  4 13:55:47.210 [8531] dbg: channel: attempting channel
> updates.spamassassin.org
> Jan  4 13:55:47.210 [8531] dbg: channel: using existing directory
> /var/lib/spamassassin/3.004001/updates_spamassassin_org
> Jan  4 13:55:47.210 [8531] dbg: channel: channel cf file
> /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
> Jan  4 13:55:47.211 [8531] dbg: channel: channel pre file
> /var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
> Jan  4 13:55:47.211 [8531] dbg: channel: metadata version = 1720996, from
> file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
> Jan  4 13:55:47.225 [8531] dbg: dns: 1.4.3.updates.spamassassin.org =>
> 1720996, parsed as 1720996
> Jan  4 13:55:47.226 [8531] dbg: channel: current version is 1720996, new
> version is 1720996, skipping channel
> Jan  4 13:55:47.226 [8531] dbg: diag: updates complete, exiting with code 1
>
> The system that provides QA for the rules has been starved for corpora
> stopping updates from about that time.  There is nothing wrong with your
> setup.
>
> Regards,
> KAM
>

Re: sa-update not updating the rules

[Reindl Harald]

Am 04.01.2016 um 22:18 schrieb Muthu N.C:

I am using the version 3.4.1 spamassassin. I am running sa-update to
update the rules. The rules stopped updating after Dec 21st. Below is
the output when running with debug mode..Any help on getting the latest
update of the rulls will be helpful.


when there is nothing then you get nothing

02-Dez-2015 01:02:53: SpamAssassin: Update processed successfully
03-Dez-2015 00:37:51: SpamAssassin: Update processed successfully
04-Dez-2015 00:56:46: SpamAssassin: Update processed successfully
05-Dez-2015 00:00:16: SpamAssassin: Update processed successfully
06-Dez-2015 00:45:06: SpamAssassin: No update available
07-Dez-2015 00:19:04: SpamAssassin: No update available
08-Dez-2015 00:14:33: SpamAssassin: No update available
09-Dez-2015 00:15:58: SpamAssassin: No update available
10-Dez-2015 01:09:43: SpamAssassin: No update available
11-Dez-2015 01:20:40: SpamAssassin: No update available
12-Dez-2015 01:13:00: SpamAssassin: No update available
13-Dez-2015 00:49:06: SpamAssassin: No update available
14-Dez-2015 01:04:57: SpamAssassin: No update available
15-Dez-2015 01:09:07: SpamAssassin: No update available
16-Dez-2015 00:37:36: SpamAssassin: No update available
17-Dez-2015 00:27:17: SpamAssassin: No update available
18-Dez-2015 00:38:14: SpamAssassin: No update available
19-Dez-2015 01:12:45: SpamAssassin: No update available
20-Dez-2015 00:21:46: SpamAssassin: No update available
21-Dez-2015 00:28:33: SpamAssassin: No update available
22-Dez-2015 00:10:51: SpamAssassin: Update processed successfully
23-Dez-2015 00:59:08: SpamAssassin: No update available
24-Dez-2015 00:17:03: SpamAssassin: No update available
25-Dez-2015 00:50:35: SpamAssassin: No update available
26-Dez-2015 00:20:16: SpamAssassin: No update available
27-Dez-2015 00:52:26: SpamAssassin: No update available
28-Dez-2015 00:25:01: SpamAssassin: No update available
29-Dez-2015 01:51:52: SpamAssassin: No update available
30-Dez-2015 00:29:27: SpamAssassin: No update available
31-Dez-2015 01:11:06: SpamAssassin: No update available
01-Jan-2016 00:24:50: SpamAssassin: No update available
02-Jan-2016 00:22:49: SpamAssassin: No update available
03-Jan-2016 00:32:25: SpamAssassin: No update available
04-Jan-2016 00:03:32: SpamAssassin: No update available



signature.asc
Description: OpenPGP digital signature

Re: sa-update not updating the rules

[Jeremy McSpadden]

current version is 1720996
new version is 1720996, skipping channel

1720996 == 1720996

--
Jeremy McSpadden | Flux Labs
Local - 850-250-5590x501 | Mobile - 
850-890-2543
Fax - 850-254-2955 | Toll Free - 
877-699-FLUX
Web - http://www.fluxlabs.net


On Jan 4, 2016, at 3:19 PM, Muthu N.C 
> wrote:

Jan  4 13:55:47.226 [8531] dbg: channel: current version is 1720996, new 
version is 1720996, skipping channel
Jan  4 13:55:47.226 [8531] dbg: dia

Re: sa-update not updating the rules

[Reindl Harald]

Am 04.01.2016 um 22:37 schrieb Muthu N.C:

It looks there are latest version of rules available greater than
1720996. But I am not getting that rules. I am seeing now lot of spam
emails comes through.

I see on the below link there are latest version of rules exist.

http://ruleqa.spamassassin.org/?longdatelist=1=99#r20160104_r1722797_n

Do I need to subscribed to any other channels to get the update?


when one of the core developers tell you there is nothing wrong than 
there is nothing wrong, especially when you see "bb-kmcgrail" in the 
page you linked which is the person you replied to



On Mon, Jan 4, 2016 at 2:24 PM, Kevin A. McGrail > wrote:

On 1/4/2016 4:18 PM, Muthu N.C wrote:

I am using the version 3.4.1 spamassassin. I am running sa-update
to update the rules. The rules stopped updating after Dec 21st.
Below is the output when running with debug mode..Any help on
getting the latest update of the rulls will be helpful.

Jan  4 13:55:47.210 [8531] dbg: util: secure_tmpfile created a
temporary file /tmp/.spamassassin85313z6Z0mtmp
Jan  4 13:55:47.210 [8531] dbg: channel: attempting channel
updates.spamassassin.org 
Jan  4 13:55:47.210 [8531] dbg: channel: using existing directory
/var/lib/spamassassin/3.004001/updates_spamassassin_org
Jan  4 13:55:47.210 [8531] dbg: channel: channel cf file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.cf

Jan  4 13:55:47.211 [8531] dbg: channel: channel pre file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
Jan  4 13:55:47.211 [8531] dbg: channel: metadata version =
1720996, from file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.cf

Jan  4 13:55:47.225 [8531] dbg: dns:
1.4.3.updates.spamassassin.org
 => 1720996, parsed as 1720996
Jan  4 13:55:47.226 [8531] dbg: channel: current version is
1720996, new version is 1720996, skipping channel
Jan  4 13:55:47.226 [8531] dbg: diag: updates complete, exiting
with code 1

The system that provides QA for the rules has been starved for
corpora stopping updates from about that time.  There is nothing
wrong with your setup




signature.asc
Description: OpenPGP digital signature

Re: sa-update not updating the rules

[Muthu N.C]

Thank you Kevin and all for the update. We are started receiving spam
e-mails from "*.eu" domain in more numbers.May be the latest rules might
catch those. Any rough estimation on when would the latest rules be
available?

Thanks,
Chollamuthu N.

On Tue, Jan 5, 2016 at 3:32 AM, Kevin A. McGrail  wrote:

> On 1/4/2016 4:37 PM, Muthu N.C wrote:
>
> It looks there are latest version of rules available greater than 1720996.
> But I am not getting that rules. I am seeing now lot of spam emails comes
> through.
>
> I see on the below link there are latest version of rules exist.
>
>
> 
> http://ruleqa.spamassassin.org/?longdatelist=1=99#r20160104_r1722797_n
>
> Do I need to subscribed to any other channels to get the update?
>
> Sorry but the rule sets aren't published to the world if they don't pass
> QA.
>
> regards,
> KAM
>
>
>
>
>
>
>

Re: RDNS_NONE always being triggered

[a . smith]

 

On Jan 4, 2016, 3:42 AM, rwmaillists at googlemail wrote: 

> No look-up is done. RDNS_NONE tests whether rdns is recorded in the 
> received header. You need either to turn it on or turn the rule off.

Hi, Thanks for the reply. Ok so I assume you mean its a header that has
to haven been put in the mail by the receiving MTA (ie my Exim server)?
Would you mind elaborating, I've googled for RDNS header but haven't
worked out what exactly you are referring to. 

thanks again, Andy. 
  

Re: RDNS_NONE always being triggered

[Reindl Harald]

Am 04.01.2016 um 13:53 schrieb a.sm...@ldexgroup.co.uk:

On Jan 4, 2016, 3:42 AM, rwmaillists at googlemail wrote:


No look-up is done. RDNS_NONE tests whether rdns is recorded in the
received header. You need either to turn it on or turn the rule off.


Hi, Thanks for the reply. Ok so I assume you mean its a header that has
to haven been put in the mail by the receiving MTA (ie my Exim server)?
Would you mind elaborating, I've googled for RDNS header but haven't
worked out what exactly you are referring to.


Postfix does the right thing by default

Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3pYyM21T4fz28
for ; Mon,  4 Jan 2016 14:23:10 +0100 (CET)
___

this sounds like Exim has unuseable defaults for SA

https://www.ssisg.com/galaxy/knowledgebase.php?action=displayarticle=24

To enable reverse DNS lookups in Exim, you would edit your exim
configuration file (usually /etc/exim.conf) and add the following
towards the top of the file:

host_lookup = 0.0.0.0/0



signature.asc
Description: OpenPGP digital signature

Re: RDNS_NONE always being triggered

[Kevin A. McGrail]

On 1/4/2016 7:53 AM, a.sm...@ldexgroup.co.uk wrote:


On Jan 4, 2016, 3:42 AM, rwmaillists at googlemail wrote:



No look-up is done. RDNS_NONE tests whether rdns is recorded in the
received header. You need either to turn it on or turn the rule off.

Hi, Thanks for the reply. Ok so I assume you mean its a header that 
has to haven been put in the mail by the receiving MTA (ie my Exim 
server)? Would you mind elaborating, I've googled for RDNS header but 
haven't worked out what exactly you are referring to.




I'm guessing this might be the trick you need: 
https://www.ssisg.com/galaxy/knowledgebase.php?action=displayarticle=24

Re: RDNS_NONE always being triggered

[a . smith]

 

On 2016-01-04 14:31, Kevin A. McGrail wrote: 

> I'm guessing this might be the trick you need: 
> https://www.ssisg.com/galaxy/knowledgebase.php?action=displayarticle=24

 Thanks Kevin, I'd taken a look at this already but I'd misunderstood
the original reply, I thought I was looking for something that would add
an additional header with some info about having a valid PTR. 

Now scoring correctly for these emails! 

thanks both! Andy. 
  

News at dnswl.org - Self Service Portal

[Matthias Leisi]

Hello SA list, 

I believe that this list reaches quite a few active users of dnswl.org:

— Announcement — 

News from the dnswl.org  team:

For the past years we used an e-mail based approach for user requests to add, 
change or remove data. This was rather time-consuming and we decided that we 
need a better process to handle such requests.

That new process is in the new dnswl.org Self Service Portal. Users can use it 
to “claim” a DNSWL Id (or create a new DNSWL Id and claim this one right away), 
to request changes to the meta-data associated with such a DNSWL Id, and most 
important to add/remove IP addresses.

It should be noted that merely “adding a domain” is pointless. You need to add 
IP addresses, since the reputation that dnswl.org publishes relies only on IP 
addresses. No IP address, no reputation data.

Users who successfully claimed a DNSWL Id will get regular reports about 
changes observed that may negatively impact the reputation of “their” IP 
addresses, eg DNS becoming inconsistent, and about the approval (or rejection) 
of change requests. While users can request certain changes, the dnswl.org 
admin team reserves full editorial independence on any and all changes.

We intend to add further features and functions to the Self Service Portal over 
time, so stay tuned 

You can give the Self Service Portal a try here: 
https://www.dnswl.org/selfservice/  

— End Announcement — 

Of course, we can still be reached at admins /at/ dnswl.org for requests that 
can not be solved through the Self Service Portal.


— Matthias, for the dnswl.org project

-- 
Matthias Leisi
Katzenrütistrasse 68, 8153 Rümlang
Mobile +41 79 377 04 43
matth...@leisi.net
Skype matthias.leisi



smime.p7s
Description: S/MIME cryptographic signature

Re: RDNS_NONE always being triggered

[Richard Doyle]

On 01/04/2016 05:46 AM, Reindl Harald wrote:
>
>
> Am 04.01.2016 um 13:53 schrieb a.sm...@ldexgroup.co.uk:
>> On Jan 4, 2016, 3:42 AM, rwmaillists at googlemail wrote:
>>>
>>> No look-up is done. RDNS_NONE tests whether rdns is recorded in the
>>> received header. You need either to turn it on or turn the rule off.
>>>
>> Hi, Thanks for the reply. Ok so I assume you mean its a header that has
>> to haven been put in the mail by the receiving MTA (ie my Exim server)?
>> Would you mind elaborating, I've googled for RDNS header but haven't
>> worked out what exactly you are referring to.
>
> Postfix does the right thing by default
>
> Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
> by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3pYyM21T4fz28
> for ; Mon,  4 Jan 2016 14:23:10 +0100 (CET)
> ___
>
> this sounds like Exim has unuseable defaults for SA
>
> https://www.ssisg.com/galaxy/knowledgebase.php?action=displayarticle=24
>
>
> To enable reverse DNS lookups in Exim, you would edit your exim
> configuration file (usually /etc/exim.conf) and add the following
> towards the top of the file:
>
> host_lookup = 0.0.0.0/0
>
Exim's default configuration file contains:

host_lookup = *

Re: sa-update not updating the rules

[Kevin A. McGrail]

On 1/4/2016 4:18 PM, Muthu N.C wrote:
I am using the version 3.4.1 spamassassin. I am running sa-update to 
update the rules. The rules stopped updating after Dec 21st. Below is 
the output when running with debug mode..Any help on getting the 
latest update of the rulls will be helpful.


Jan  4 13:55:47.210 [8531] dbg: util: secure_tmpfile created a 
temporary file /tmp/.spamassassin85313z6Z0mtmp
Jan  4 13:55:47.210 [8531] dbg: channel: attempting channel 
updates.spamassassin.org 
Jan  4 13:55:47.210 [8531] dbg: channel: using existing directory 
/var/lib/spamassassin/3.004001/updates_spamassassin_org
Jan  4 13:55:47.210 [8531] dbg: channel: channel cf file 
/var/lib/spamassassin/3.004001/updates_spamassassin_org.cf 

Jan  4 13:55:47.211 [8531] dbg: channel: channel pre file 
/var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
Jan  4 13:55:47.211 [8531] dbg: channel: metadata version = 1720996, 
from file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf 

Jan  4 13:55:47.225 [8531] dbg: dns: 1.4.3.updates.spamassassin.org 
 => 1720996, parsed as 1720996
Jan  4 13:55:47.226 [8531] dbg: channel: current version is 1720996, 
new version is 1720996, skipping channel
Jan  4 13:55:47.226 [8531] dbg: diag: updates complete, exiting with 
code 1
The system that provides QA for the rules has been starved for corpora 
stopping updates from about that time.  There is nothing wrong with your 
setup.


Regards,
KAM