Re: RDNS_NONE hit, but no RDNS queries actually done?

[Dan Malm]

Thanks :)

That makes a lot of sense. And gives me a lot more reason to do a
feature request to my MTA on the missing PTR in the headers that's been
bugging me.

BR/Mvh. Dan Malm, Systems Engineer, One.com

On 2018-09-26 15:03, Kevin A. McGrail wrote:
> I think you are making an assumption it's doing a lookup.  To me, it
> appears to be looking at information parsed from the received headers:
> 
> header __RDNS_NONE  X-Spam-Relays-External =~ /^[^\]]+ rdns= /
> meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD)
> 
> That appears to be parsed out of the received headers not using a lookup.
> 
> Regards,
> KAM
> 
> 
> --
> Kevin A. McGrail
> VP Fundraising, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
> 
> 
> On Wed, Sep 26, 2018 at 3:35 AM Dan Malm  wrote:
> 
>> Hi,
>>
>> I've been getting some complaints from users about mails received being
>> flagged with the HDR_ORDER_FTSDMCXX_NORDNS rule where the sender appears
>> to have correct RDNS. While trying to figure this out I found that it
>> seems like the SpamAssassin version I have doesn't actually do any PTR
>> check, and thus all mails will hit the RDNS_NONE rule.
>>
>> To verify I've installed a clean version of SpamAssassin 3.4.1 on a VPS
>> running Ubuntu 18.04. I sent myself an email from gmail, who definitely
>> does have correct RDNS, and then ran the source
>> (https://pastebin.com/gE0qauf1) through SpamAssassin with a user_prefs
>> score set for RDNS_NONE
>>
>> The debug info show no RDNS for any relay:
>>
>> Sep 26 07:16:07.890 [21117] dbg: metadata: X-Spam-Relays-Internal: [
>> ip=10.27.26.11 rdns= helo=mx1.pub.mailpod3-cph3.one.com
>> by=mailstorage0.cst.mailpod3-cph3.one.com ident= envfrom= intl=1
>> id=SNkcMEAqq1uBjAAAhMrzvA auth= msa=0 ]
>> Sep 26 07:16:07.891 [21117] dbg: metadata: X-Spam-Relays-External: [
>> ip=209.85.166.170 rdns= helo=mail-it1-f170.google.com
>> by=mx1.pub.mailpod3-cph3.one.com ident= envfrom= intl=0
>> id=49846d91-c157-11e8-afca-e0d84894a001 auth= msa=0 ]
>>
>> A tcpdump (udp port 53) shows no attempt to do a query for PTR:
>> https://pastebin.com/DDwdW9gu
>> As a reference, if I do a dig -x 209.85.166.170 I get this while doing
>> the same tcpdump:
>> IP 188.166.16.195.54095 > 67.207.67.3.53: 17606+ [1au] PTR?
>> 170.166.85.209.in-addr.arpa. (56)
>> IP 188.166.16.195.48750 > 67.207.67.2.53: 23774+ [1au] PTR?
>> 170.166.85.209.in-addr.arpa. (56)
>> IP 67.207.67.2.53 > 188.166.16.195.48750: 23774 1/0/1 PTR
>> mail-it1-f170.google.com. (94)
>> IP 67.207.67.3.53 > 188.166.16.195.54095: 17606 1/0/1 PTR
>> mail-it1-f170.google.com. (94)
>>
>> And it does hit the RDNS_NONE rule
>>
>> Is anyone else seeing the same, or have I missed something?
>>
>> --
>> BR/Mvh. Dan Malm, Systems Engineer, One.com
>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: RDNS_NONE hit, but no RDNS queries actually done?

[Kevin A. McGrail]

I think you are making an assumption it's doing a lookup.  To me, it
appears to be looking at information parsed from the received headers:

header __RDNS_NONE  X-Spam-Relays-External =~ /^[^\]]+ rdns= /
meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD)

That appears to be parsed out of the received headers not using a lookup.

Regards,
KAM


--
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Wed, Sep 26, 2018 at 3:35 AM Dan Malm  wrote:

> Hi,
>
> I've been getting some complaints from users about mails received being
> flagged with the HDR_ORDER_FTSDMCXX_NORDNS rule where the sender appears
> to have correct RDNS. While trying to figure this out I found that it
> seems like the SpamAssassin version I have doesn't actually do any PTR
> check, and thus all mails will hit the RDNS_NONE rule.
>
> To verify I've installed a clean version of SpamAssassin 3.4.1 on a VPS
> running Ubuntu 18.04. I sent myself an email from gmail, who definitely
> does have correct RDNS, and then ran the source
> (https://pastebin.com/gE0qauf1) through SpamAssassin with a user_prefs
> score set for RDNS_NONE
>
> The debug info show no RDNS for any relay:
>
> Sep 26 07:16:07.890 [21117] dbg: metadata: X-Spam-Relays-Internal: [
> ip=10.27.26.11 rdns= helo=mx1.pub.mailpod3-cph3.one.com
> by=mailstorage0.cst.mailpod3-cph3.one.com ident= envfrom= intl=1
> id=SNkcMEAqq1uBjAAAhMrzvA auth= msa=0 ]
> Sep 26 07:16:07.891 [21117] dbg: metadata: X-Spam-Relays-External: [
> ip=209.85.166.170 rdns= helo=mail-it1-f170.google.com
> by=mx1.pub.mailpod3-cph3.one.com ident= envfrom= intl=0
> id=49846d91-c157-11e8-afca-e0d84894a001 auth= msa=0 ]
>
> A tcpdump (udp port 53) shows no attempt to do a query for PTR:
> https://pastebin.com/DDwdW9gu
> As a reference, if I do a dig -x 209.85.166.170 I get this while doing
> the same tcpdump:
> IP 188.166.16.195.54095 > 67.207.67.3.53: 17606+ [1au] PTR?
> 170.166.85.209.in-addr.arpa. (56)
> IP 188.166.16.195.48750 > 67.207.67.2.53: 23774+ [1au] PTR?
> 170.166.85.209.in-addr.arpa. (56)
> IP 67.207.67.2.53 > 188.166.16.195.48750: 23774 1/0/1 PTR
> mail-it1-f170.google.com. (94)
> IP 67.207.67.3.53 > 188.166.16.195.54095: 17606 1/0/1 PTR
> mail-it1-f170.google.com. (94)
>
> And it does hit the RDNS_NONE rule
>
> Is anyone else seeing the same, or have I missed something?
>
> --
> BR/Mvh. Dan Malm, Systems Engineer, One.com
>
>

RDNS_NONE hit, but no RDNS queries actually done?

[Dan Malm]

Hi,

I've been getting some complaints from users about mails received being
flagged with the HDR_ORDER_FTSDMCXX_NORDNS rule where the sender appears
to have correct RDNS. While trying to figure this out I found that it
seems like the SpamAssassin version I have doesn't actually do any PTR
check, and thus all mails will hit the RDNS_NONE rule.

To verify I've installed a clean version of SpamAssassin 3.4.1 on a VPS
running Ubuntu 18.04. I sent myself an email from gmail, who definitely
does have correct RDNS, and then ran the source
(https://pastebin.com/gE0qauf1) through SpamAssassin with a user_prefs
score set for RDNS_NONE

The debug info show no RDNS for any relay:

Sep 26 07:16:07.890 [21117] dbg: metadata: X-Spam-Relays-Internal: [
ip=10.27.26.11 rdns= helo=mx1.pub.mailpod3-cph3.one.com
by=mailstorage0.cst.mailpod3-cph3.one.com ident= envfrom= intl=1
id=SNkcMEAqq1uBjAAAhMrzvA auth= msa=0 ]
Sep 26 07:16:07.891 [21117] dbg: metadata: X-Spam-Relays-External: [
ip=209.85.166.170 rdns= helo=mail-it1-f170.google.com
by=mx1.pub.mailpod3-cph3.one.com ident= envfrom= intl=0
id=49846d91-c157-11e8-afca-e0d84894a001 auth= msa=0 ]

A tcpdump (udp port 53) shows no attempt to do a query for PTR:
https://pastebin.com/DDwdW9gu
As a reference, if I do a dig -x 209.85.166.170 I get this while doing
the same tcpdump:
IP 188.166.16.195.54095 > 67.207.67.3.53: 17606+ [1au] PTR?
170.166.85.209.in-addr.arpa. (56)
IP 188.166.16.195.48750 > 67.207.67.2.53: 23774+ [1au] PTR?
170.166.85.209.in-addr.arpa. (56)
IP 67.207.67.2.53 > 188.166.16.195.48750: 23774 1/0/1 PTR
mail-it1-f170.google.com. (94)
IP 67.207.67.3.53 > 188.166.16.195.54095: 17606 1/0/1 PTR
mail-it1-f170.google.com. (94)

And it does hit the RDNS_NONE rule

Is anyone else seeing the same, or have I missed something?

-- 
BR/Mvh. Dan Malm, Systems Engineer, One.com



signature.asc
Description: OpenPGP digital signature

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: 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 <h.rei...@thelounge.net>; 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. 
  

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 <h.rei...@thelounge.net>; 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: question re/ RDNS_NONE

[Edda]

Am 25.11.15 um 15:56 schrieb RW:.

3. You have no test for dynamic rDNS

why that when SA makes the dns request and so have a rDNS?

Because, as far as I can see, the patch doesn't make the rDNS available
to SA's other tests, it just supplies  a stand-alone test for no-rDNS.


Correct.


I don't know how easy it would be to fix that *properly*  because the
relay information is expected to be complete very early in the scan,
before any DNS results return. It should be possible to shift some of
the header tests so they can identify dynamic rDNS, but until then
BOTNET will do it.

I thought on doing the check in Received.pm, i.e. exactly one rdns 
lookup, if the header of the last external lacks rdns. That would add 
the rdns information to the pseudo headers (like Relays-External, and 
Untrusted), where the SpamAssassin rules are based on. But this would 
also result in waiting for this request, if it must be done, before all 
received headers were parsed. I don't see another way, maybe someone 
else...?


Then, I saw that all dns lookups were deleted from Received.pm in 
version 3.2.x, see


https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054

Reasons cited:

- (a) it's slow
- (b) it's the wrong place to do that; header-parsing should not incur network
  accesses
- (c) it results in differing results, depending on if local_tests_only is on
  or not.

Remark: 3.1.x retrieved every rDNS for all Untrusted Relays, even if 
they were retrieved from the headers already. They didn't trust the 
headers at all.


Because dns checks are "not allowed" in Received.pm, I built a patch for 
the single check. The actually patch (in DNSEval.pm) could make the 
result (rdns exists or not) available for further checks, but that would 
result in more work on the rules ... and looks like an ugly workaround...


.. I would prefer to do this ONE rdns lookup in Received.pm, and 
only if necessary. Opinions?


Edda

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 25.11.2015 um 20:16 schrieb Bill Cole:

On 24 Nov 2015, at 14:27, Edda wrote:


Older versions performed rdns lookups for every IP in relay-untrusted
directly in Received.pm, this was deleted:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054


I think Justin's rationale there isn't even the whole case for NOT doing
DNS checks on the client IPs in Received headers written by "trusted"
relays absent some special motivation. DNS is ephemeral and results can
be a function of where a query comes from. It seems to me that the
relevant DNS mapping is whatever can be resolved by the MTA that acts as
the MX for the recipient's domain when it is being offered the message.
It is NOT the DNS mapping that is discernible a few seconds (or days))
later on some final destination machine.


while that may be true (but in most cases won't matter even if it 
happens) - you can *never* know what "unknown" in the MTA header means - 
try it out - in case of a dns timeout on the MTA you get the same 
"unknown" and fire RDNS_NONE because you just have no other information 
because you can only verify that by doing the DNS lookup at your own and 
distinct between NXDOMAIN and errors


i had real world samples flagged with RDNS_NONE noticed in "tail -f" of 
the maillog and a "dig IP" had a correct answer 2 seconds later and 
there are good chances that SA would have been able to resolve it in the 
milter-stage




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Bill Cole]

On 24 Nov 2015, at 17:20, David Jones wrote:
[...]


NOTE: I have just now tested that I can give Postfix (with
reject_unknown_helo_hostname not enabled) a fully-qualified HELO name
that has no A or one with an A resolving to 192.0.2.1 (and therefore: 
no

PTR) and in both cases Postfix neither logs anything about the "bad"
name nor indicates any DNS discrepancy in its Received header.
SpamAssassin's hits on the messages I sent myself that way include no
rules involving DNS or HELO names.


You don't see 'unknown' in the Received: header?


No. See: http://www.scconsult.com/bogushelo.png (redacted screenshot of 
the 2 test delivered messages) There's a real name (mostly redacted, but 
you can see it's there) in those Received headers Postfix recorded the 
name it got for the client via DNS at that time. The PTR for the client 
IP resolved to a name which had an A record that resolved to the client 
IP.


My point (probably obscured by verbosity...) is that whether Postfix 
deems the client hostname to be "unknown" is not influenced in any way 
by the HELO name. As a result, SA's RDNS_NONE is also not influenced by 
the HELO name.



Pretty sure that
mine would.  I am running Postfix 2.10.2 on a Redhat-based variant.


My tests were on my QA instance running unmodified Postfix 3.0.2 with a 
relatively simple commonplace config. Based on the docs, this general 
area of Postfix hasn't seen much change since 2.3, so I doubt your 
system behaves differently.


I'd bet against you seeing "unknown" in a Postfix Received header just 
because a HELO name was wrong.



Apart from whether Postfix or SA actually can be made to compare the
result of a client IP  PTR resolution to the HELO name or of a HELO A
result to the client IP, such verification is operationally 
worthless.

There are far too many innocently misconfigured MTAs claiming to be
localhost.localdomain or exchange01.local or whatever other default 
name
is the flavor of the month to arbitrarily ignore RFC5321 and send 
them
away. It generally IS safe to require that a HELO name be 
syntactically

valid and not match a few patterns chronically used by spambots but
unless you're fond of maintaining whitelists or of teaching users and 
a

particularly dense sub-population of admins about wise DNS hygiene,
validating HELO names tightly is wasted effort.


If I enable reject_unknown_helo_hostname, then I start blocking
a lot of legit email from poorly configured servers.


Precisely. Nothing has ever broken due to a HELO name being wrong but 
valid (i.e. a string that COULD be a hostname) so there's nothing 
working against persistent widespread wrongness.


Examining HELO arguments is generally worthless for generic rules, i.e. 
ones that don't use key off the specific server (e.g. using a local 
identity) or to particular bad actors/agents (e.g. 'EHLO ylmf-pc' is 
ALWAYS a Cutwail spambot.) The only generic HELO test I've seen which 
doesn't have a false positive rate over 1% is Postfix's 
'reject_invalid_helo_hostname' which catches very little but is never 
wrong.

Re: question re/ RDNS_NONE

[John Hardin]

On Wed, 25 Nov 2015, Bill Cole wrote:


On 24 Nov 2015, at 14:27, Edda wrote:


 Older versions performed rdns lookups for every IP in relay-untrusted
 directly in Received.pm, this was deleted:

 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054


It seems to me like the entirety of the problem in this case is that a 
"trusted" MTA is writing a Received header with true but incomplete 
information *by design*.


...or by misconfiguration. It remains to be seen whether the OP's ISP is 
willing to *fix* that configuration. If not, then yes, it's returning 
incomplete information by design. (I didn't follow the discussion closely 
enough to register whether they've already said "there's no way for us to 
fix it", sorry if I missed that...)


The host is "trusted" in the sense that it is known to not intentionally 
create false Received headers but it cannot be actually trusted to write 
complete Received headers meeting modern best practice.


I'd suggest that the header-parsing-time rDNS correction of just the 
last-untrusted is a good idea, but that it should be behind a 
configuration option that defaults to disabled so that you only have to 
suffer the delay if you (1) have a broken ISP who doesn't provide that 
information and (2) choose to accept the delay.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79

Re: question re/ RDNS_NONE

[Bill Cole]

On 24 Nov 2015, at 14:27, Edda wrote:

Older versions performed rdns lookups for every IP in relay-untrusted 
directly in Received.pm, this was deleted:


https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054


I think Justin's rationale there isn't even the whole case for NOT doing 
DNS checks on the client IPs in Received headers written by "trusted" 
relays absent some special motivation. DNS is ephemeral and results can 
be a function of where a query comes from. It seems to me that the 
relevant DNS mapping is whatever can be resolved by the MTA that acts as 
the MX for the recipient's domain when it is being offered the message. 
It is NOT the DNS mapping that is discernible a few seconds (or days)) 
later on some final destination machine.


The "trusted networks" model in SA is an imperfect one for figuring out 
where that MX-based handoff occurs and that the label "trusted" is a bit 
misleading, but it's tough to see how to make it operationally better. 
It seems to me like the entirety of the problem in this case is that a 
"trusted" MTA is writing a Received header with true but incomplete 
information *by design*. The host is "trusted" in the sense that it is 
known to not intentionally create false Received headers but it cannot 
be actually trusted to write complete Received headers meeting modern 
best practice.


Maybe there needs to be a new bucket for inbound MTAs in SpamAssassin: 
innocent_moron_networks


(or perhaps no one should let me name things :)

Re: question re/ RDNS_NONE

[RW]

On Wed, 25 Nov 2015 14:54:46 +0100
Reindl Harald wrote:

> Am 25.11.2015 um 14:41 schrieb RW:
> > On Wed, 25 Nov 2015 12:32:59 +0100
> > Matthias Apitz wrote:
> >  
> >> I think we can close this thread now :-)  
> >
> > IIWY I'd still use the Botnet plugin.
> >
> > The absence of reverse DNS gives you three problem:
> >
> >1. You have no test for the absence of rDNS  
> 
> why that when SA makes the dns request itself?

As it says above I was listing the  problems that come from not having
rDNS available, I did go on to say that the patch fixes this.
 
> in fact in that case you *really* have the capability to distinct 
> between absence (NXDOMAIN) or dns-error which you don#t have by
> parsing headers with no clue where the "unknown" is coming from
> 
> >2. You have no test for the absence of full-circle DNS  
> 
> should be possible

It is but this patch doesn't do it, which is why I still recommended the
use of BOTNET (at least for small-scale setups).
 
> >3. You have no test for dynamic rDNS  
> 
> why that when SA makes the dns request and so have a rDNS?

Because, as far as I can see, the patch doesn't make the rDNS available
to SA's other tests, it just supplies  a stand-alone test for no-rDNS. 

I don't know how easy it would be to fix that *properly*  because the
relay information is expected to be complete very early in the scan,
before any DNS results return. It should be possible to shift some of
the header tests so they can identify dynamic rDNS, but until then
BOTNET will do it.

BOTNET is a more flexible as well.


Seems to me it would be better for large scale SA users if Postfix could
be configured always to add rDNS or "unavailable", and leave users of
fetchmail, getmail etc with BOTNET.

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Tuesday, November 24, 2015 a las 08:27:45PM +0100, Edda escribió:


I have found the bug in your patch, just a spelling issue:

> 
> pop:Mail eh$ diff -u SpamAssassin/Plugin/DNSEval.pm.ORG 
> SpamAssassin/Plugin/DNSEval.pm
> --- SpamAssassin/Plugin/DNSEval.pm.ORG2015-11-24 19:02:58.0 
> +0100
> +++ SpamAssassin/Plugin/DNSEval.pm2015-11-24 19:25:59.0 +0100
> @@ -58,6 +58,7 @@
>   'check_rbl_from_host',
>   'check_rbl_from_domain',
>   'check_rbl_envfrom',
> +'check_dsn_rdns',
^^
>   'check_dns_sender',
> ];
> 
> @@ -373,6 +374,25 @@
> }
>   }
> 
> +sub check_dns_rdns {
   ^^


-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Wednesday, November 25, 2015 a las 12:07:12PM +0100, Edda escribió:

> >>'check_rbl_envfrom',
> >> +'check_dsn_rdns',
> >  ^^
> >>'check_dns_sender',
> >>  ];
> >>
> >> @@ -373,6 +374,25 @@
> >>  }
> >>}
> >>
> >> +sub check_dns_rdns {
> > ^^
> >
> >
> Ouch, sorry, i tested it on 3.3.1 and "re-typed" that line in 3.4.1

Note: for 3.4.0 one must change as well:

+  } elsif ($question->qtype =~ /^(PTR)$/ &&
+  $packet->header->rcode =~ /^(?:NXDOMAIN|SERVFAIL)$/)

to:

+   } elsif ($question->qtype =~ /^(PTR)$/ &&
+   $pkt->header->rcode =~ /^(?:NXDOMAIN|SERVFAIL)$/)


> Does the patch work for you?

Seems so. I invalidated the IP addr in the Received: line in question
to:

  Received: from [12.82.97.1] (helo=nm33-vm3.bullet.mail.ir2.yahoo.com)
by ms-10.1blu.de with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16)
(Exim 4.76)

This gives:

Content analysis details:   (-2.2 points, 3.0 required)

 pts rule name  description
 -- --
 1.0 NO_RDNS_FOR_LAST_EXTERNAL DNS: Last External really has no rdns
-4.0 BAYES_00   BODY: Bayes spam probability is 0 to 1%
[score: 0.]
 0.8 RDNS_NONE  Delivered to internal network by a host with no rDNS

I think we can close this thread now :-)

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Edda]

Am 25.11.15 um 09:55 schrieb Matthias Apitz:

El día Tuesday, November 24, 2015 a las 08:27:45PM +0100, Edda escribió:


I have found the bug in your patch, just a spelling issue:


pop:Mail eh$ diff -u SpamAssassin/Plugin/DNSEval.pm.ORG
SpamAssassin/Plugin/DNSEval.pm
--- SpamAssassin/Plugin/DNSEval.pm.ORG2015-11-24 19:02:58.0
+0100
+++ SpamAssassin/Plugin/DNSEval.pm2015-11-24 19:25:59.0 +0100
@@ -58,6 +58,7 @@
   'check_rbl_from_host',
   'check_rbl_from_domain',
   'check_rbl_envfrom',
+'check_dsn_rdns',

 ^^

   'check_dns_sender',
 ];

@@ -373,6 +374,25 @@
 }
   }

+sub check_dns_rdns {

^^



Ouch, sorry, i tested it on 3.3.1 and "re-typed" that line in 3.4.1

Does the patch work for you?

Edda

Re: question re/ RDNS_NONE

[RW]

On Wed, 25 Nov 2015 12:32:59 +0100
Matthias Apitz wrote:


> I think we can close this thread now :-)

IIWY I'd still use the Botnet plugin.

The absence of reverse DNS gives you three problem:

  1. You have no test for the absence of rDNS

  2. You have no test for the absence of full-circle DNS

  3. You have no test for dynamic rDNS

If I'm understanding it correctly, the patch only fixes 1, Botnet fixes
all three.


The same problem exists more generally with Postfix. Presumably it
suppresses non-full-circle rDNS because it's easily forged - the
trouble is that this also suppresses incriminating rDNS. 

I think this is probably a more significant problem than the inability
to distinguish between no rDNS and bad rDNS. It's common that ISP
dynamic rDNS isn't full-circle.

Re: question re/ RDNS_NONE

[Joe Quinn]

On 11/25/2015 6:07 AM, Edda wrote:

Ouch, sorry, i tested it on 3.3.1 and "re-typed" that line in 3.4.1

Does the patch work for you?
Since we're currently developing in both 3.4.2 and 4.0 and now you have 
bumped into the same problem, I might as well share this:


repatch() {
  (cd $1 && svn diff) | (cd $2 && patch -p0)
}

Put that in your .bashrc - usage is "repatch ~/sa/trunk ~/sa/3.4.2" or 
whatever your directory structure is.

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 25.11.2015 um 14:41 schrieb RW:

On Wed, 25 Nov 2015 12:32:59 +0100
Matthias Apitz wrote:


I think we can close this thread now :-)


IIWY I'd still use the Botnet plugin.

The absence of reverse DNS gives you three problem:

   1. You have no test for the absence of rDNS


why that when SA makes the dns request itself?

in fact in that case you *really* have the capability to distinct 
between absence (NXDOMAIN) or dns-error which you don#t have by parsing 
headers with no clue where the "unknown" is coming from



   2. You have no test for the absence of full-circle DNS


should be possible


   3. You have no test for dynamic rDNS


why that when SA makes the dns request and so have a rDNS?


If I'm understanding it correctly, the patch only fixes 1, Botnet fixes
all three


honestly SA should by making the rDNS request itself be able to just act 
identically as if it was error prone parsed out of headers which did not 
contain the information what is why it's done directly




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Edda]

Am 24.11.15 um 21:03 schrieb John Hardin:

On Tue, 24 Nov 2015, Reindl Harald wrote:


i would suggest when the Received header for the *first* untrusted hop


Just so we're clear on first vs. last: the host that submitted the
mail to the most-remote MTA whose headers you trust.


don't contain a reverse dns information *and only then* do that
lookup directly in SA if network tests are enabled


This seems to me a reasonable approach. There's no need to check RDNS
on hops prior to the final untrusted hop (chronologically speaking).

Thank you both for your clarification. I agree and this is exactly what 
my patch does.


Edda

Re: question re/ RDNS_NONE

[RW]

On Tue, 24 Nov 2015 12:03:12 -0800 (PST)
John Hardin wrote:

> On Tue, 24 Nov 2015, Reindl Harald wrote:
> 
> > i would suggest when the Received header for the *first* untrusted
> > hop  
> 
> Just so we're clear on first vs. last: the host that submitted the
> mail to the most-remote MTA whose headers you trust.
> 
> > don't contain a reverse dns information *and only then* do that
> > lookup directly in SA if network tests are enabled  
> 
> This seems to me a reasonable approach. There's no need to check RDNS
> on hops prior to the final untrusted hop (chronologically speaking).

It would  be the last relay into the internal network, if it's from an
untrusted server. The edge of the trusted network may be a submission
server.

Re: question re/ RDNS_NONE

[John Hardin]

On Tue, 24 Nov 2015, RW wrote:


On Tue, 24 Nov 2015 12:03:12 -0800 (PST)
John Hardin wrote:


On Tue, 24 Nov 2015, Reindl Harald wrote:


i would suggest when the Received header for the *first* untrusted
hop


Just so we're clear on first vs. last: the host that submitted the
mail to the most-remote MTA whose headers you trust.


don't contain a reverse dns information *and only then* do that
lookup directly in SA if network tests are enabled


This seems to me a reasonable approach. There's no need to check RDNS
on hops prior to the final untrusted hop (chronologically speaking).


It would  be the last relay into the internal network, if it's from an
untrusted server. The edge of the trusted network may be a submission
server.


You don't trust the headers your submission server generates?

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  USMC Rules of Gunfighting #4: If your shooting stance is good,
  you're probably not moving fast enough nor using cover correctly.
---

Re: question re/ RDNS_NONE

[RW]

On Tue, 24 Nov 2015 20:29:40 +0100
Reindl Harald wrote:

> Am 24.11.2015 um 20:24 schrieb Matthias Apitz:
> > El día Tuesday, November 24, 2015 a las 05:08:20PM +0100, Reindl
> > Harald escribió: 
> >> i dunno why the OP is fetching his mail from his ISP and then feed
> >> spamassassin with the mails local,  
> >
> > WHy you dunno this? My mail must arrive somewhere, from where I can
> > fetch it with fetchmail+imap when I'm online again with my FreeBSD
> > netbook or my Ubuntu mobile phone  
> 
> normally a sane ISP *should* have proper spamfilters and provide IMAP 
> directly, so no need for fetchmail and a local filter - but your 
> decision,

In my experience you can get much better results if you do it yourself.

> if i would be you i would rop the ISP, point the MX to a
> cheap VPS and install my own MTA + Postscreen + SpamAssassin + IMAP
> there

This has problems of its own. And why pay money to do the donkey work?

Re: question re/ RDNS_NONE

[Martin Gregorie]

On Tue, 2015-11-24 at 17:08 +0100, Reindl Harald wrote:
> 
> why not read the thread from thje first beginning?
> 
What makes you think I didn't? Though I rather wish I hadn't.
 
> i dunno why the OP is fetching his mail from his ISP and then feed 
> spamassassin with the mails local, *but* he does and the received
> header 
> of the ISP is the reason RDNS_NONE is triggered for *every* mail
> 
I may well be doing something similar. My mail collects my POP3 mailbox
on my ISP's smart host. I use getmail to fetch it from there and run
spamc in the getmail MDA script. This pipes the spamc output through a
filter which quarantines the spam and uses the sendmail utility to pass
ham to Postfix for distribution via Dovecot. 

I think this is a sensible approach for a low volume/household mail
system because it avoids the need to punch any holes in the firewall
guarding the house LAN because the house system originates all
connections to the ISP's smarthost. Putting SA in the incoming mail
stream means that there is no need to do anything special to stop
outbound mail going through SA.
 
> most likely because "fairly tightly constrained firewalls" is simply
> wrong for most ISP setups because they don't invest much energy to 
> train filters and try to avoid FP's to minimize support calls
> 
OK.


Martin

Re: question re/ RDNS_NONE

[RW]

On Tue, 24 Nov 2015 15:15:17 -0800 (PST)
John Hardin wrote:

> On Tue, 24 Nov 2015, RW wrote:
> 
> > On Tue, 24 Nov 2015 12:03:12 -0800 (PST)
> > John Hardin wrote:
> >  
> >> On Tue, 24 Nov 2015, Reindl Harald wrote:
> >>  
> >>> i would suggest when the Received header for the *first* untrusted
> >>> hop  
> >>
> >> Just so we're clear on first vs. last: the host that submitted the
> >> mail to the most-remote MTA whose headers you trust.
> >>  
> >>> don't contain a reverse dns information *and only then* do that
> >>> lookup directly in SA if network tests are enabled  
> >>
> >> This seems to me a reasonable approach. There's no need to check
> >> RDNS on hops prior to the final untrusted hop (chronologically
> >> speaking).  
> >
> > It would  be the last relay into the internal network, if it's from
> > an untrusted server. The edge of the trusted network may be a
> > submission server.  
> 
> You don't trust the headers your submission server generates?

It's more a question of why you would want to lookup the reverse dns of
a mail client. It's only the handover into the internal network from an
untrusted server where reverse dns matters.

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 20:40 schrieb Matthias Apitz:

El día Tuesday, November 24, 2015 a las 08:29:40PM +0100, Reindl Harald 
escribió:


WHy you dunno this? My mail must arrive somewhere, from where I can
fetch it with fetchmail+imap when I'm online again with my FreeBSD netbook or
my Ubuntu mobile phone


normally a sane ISP *should* have proper spamfilters


yes, it *should* but does not;


why then use this one?


and provide IMAP
directly, so no need for fetchmail and a local filter - but your
decision,


I could use IMAP directly with, for example, mutt -f imaps://imap.1blu.de
and mutt can to SMTP upstream directly; but this would mean to be online
all the time while reading; in situations where you pay by time of
connection (for example in hotels in Havana), it is better to fetch all mails 
in a
few seconds, drop the Internet connection (and stop paying), read and
answer offline, open Internet again and send all answers out upstream at
once; do you get my point?


there are mail clients with offline caching, but that's off-topic


if i would be you i would rop the ISP, point the MX to a cheap
VPS and install my own MTA + Postscreen + SpamAssassin + IMAP there


what is a VPS?


https://en.wikipedia.org/wiki/Virtual_private_server



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[David Jones]

>From: Bill Cole <sausers-20150...@billmail.scconsult.com>
>Sent: Tuesday, November 24, 2015 1:41 PM
>To: users@spamassassin.apache.org
>Subject: Re: question re/ RDNS_NONE

>On 24 Nov 2015, at 13:47, David Jones wrote:

>> Could this be dependent on the MTA used?  I am using Postfix
>> which puts in Received headers like this:
>>
>> Received: from econnect.dmsgs.com (unknown [8.224.216.57])
>>
>> That IP has a PTR record but it doesn't match the SMTP HELO of
>> econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
>> the RDNS_NONE hit on more than just no rDNS.

>Incorrect. The HELO name (econnect.dmsgs.com) is not involved at all in
>why Postfix puts 'unknown' inside the parentheses.

Thank you for that clarification.  However what you describe below
is one part of FCrDNS (a.k.a full circle DNS) check.  The second part
would be the PTR record matching the SMTP HELO.  So this still means
that the RDNS_NONE check is more than just a missing PTR record
when using Postfix.

>Postfix puts "unknown" there because the PTR resolves to
>smtp-55-unassigned.dmsgs.com but smtp-55-unassigned.dmsgs.com has no A
>record resolving back to 8.224.216.57. It appears that the people
>running DNS for 216.224.8.in-addr.arpa and dmsgs.com (apparently Digital
>Messaging Solutions, Inc. of Tuscon AZ, USA) have screwed up. Many
>nearby IPs also allocated to them have PTRs that resolve to names that
>have As resolving back to the IP, so presumably they aren't entirely
>incompetent...

Re: question re/ RDNS_NONE

[Bill Cole]

On 24 Nov 2015, at 14:54, David Jones wrote:


From: Bill Cole <sausers-20150...@billmail.scconsult.com>
Sent: Tuesday, November 24, 2015 1:41 PM
To: users@spamassassin.apache.org
Subject: Re: question re/ RDNS_NONE



On 24 Nov 2015, at 13:47, David Jones wrote:



Could this be dependent on the MTA used?  I am using Postfix
which puts in Received headers like this:

Received: from econnect.dmsgs.com (unknown [8.224.216.57])

That IP has a PTR record but it doesn't match the SMTP HELO of
econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
the RDNS_NONE hit on more than just no rDNS.


Incorrect. The HELO name (econnect.dmsgs.com) is not involved at all 
in

why Postfix puts 'unknown' inside the parentheses.


Thank you for that clarification.  However what you describe below
is one part of FCrDNS (a.k.a full circle DNS) check.  The second part
would be the PTR record matching the SMTP HELO.


Where is the code or rule in SpamAssassin which performs that check?

In Postfix there is no such check that I am aware of, either by default 
or with any of the optional smtpd_helo_restrictions settings. Can you 
point to it in the Postfix docs? What you describe is NOT part of the 
optional "reject_unknown_helo_hostname", which only requires a resolving 
HELO name.



So this still means
that the RDNS_NONE check is more than just a missing PTR record
when using Postfix.


No PTR at all OR (as in the case you cited) a PTR to a name which 
doesn't resolve back to the IP will (if you allow Postfix to accept mail 
from such mismanaged machines) result in "unknown" being used where 
otherwise a correct hostname would go: inside parentheses, before the 
brackets-enclosed IP.  The HELO name, *WHATEVER IT IS* is put right 
after the word 'from' before the parentheses.


NOTE: I have just now tested that I can give Postfix (with 
reject_unknown_helo_hostname not enabled) a fully-qualified HELO name 
that has no A or one with an A resolving to 192.0.2.1 (and therefore: no 
PTR) and in both cases Postfix neither logs anything about the "bad" 
name nor indicates any DNS discrepancy in its Received header. 
SpamAssassin's hits on the messages I sent myself that way include no 
rules involving DNS or HELO names.


Apart from whether Postfix or SA actually can be made to compare the 
result of a client IP  PTR resolution to the HELO name or of a HELO A 
result to the client IP, such verification is operationally worthless. 
There are far too many innocently misconfigured MTAs claiming to be 
localhost.localdomain or exchange01.local or whatever other default name 
is the flavor of the month to arbitrarily ignore RFC5321 and send them 
away. It generally IS safe to require that a HELO name be syntactically 
valid and not match a few patterns chronically used by spambots but 
unless you're fond of maintaining whitelists or of teaching users and a 
particularly dense sub-population of admins about wise DNS hygiene, 
validating HELO names tightly is wasted effort.

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 20:36 schrieb David Jones:

From: Reindl Harald <h.rei...@thelounge.net>
Sent: Tuesday, November 24, 2015 1:20 PM
To: users@spamassassin.apache.org
Subject: Re: question re/ RDNS_NONE



Am 24.11.2015 um 20:16 schrieb David Jones:

From: Reindl Harald <h.rei...@thelounge.net>
and that is why i call it harmful to completly rely on the Received
header instead doing the DNS lookup based on the IP which would have a
lot of advantages:



* less error prone
* even when the MTA had a timeout a chance that this
DNS rqeuest get answered properly, the MTA treats
a timeout *completty* different and would *not*
reject a mail if the answer is not an NXDOMAIN even
if it is configured for reject clients without a PTR
* SpamAssassin has *no clue* what the "unknown" means
   it could have been a timeout or a NXDOMAIN



disadvantages - zero - there is no overhead for a chached DNS query


I agree with you if the SA server is configured with a local caching
DNS server that is not forwarding and the /etc/resolv.conf is
pointing to 127.0.0.1.

We have seen a number of people ask for help on this mailing
list because their DNS was not setup like this which means SA
would generate a lot more queries to the ISP or Internet DNS
servers compounding the problem with free usage limits on
some RBLs



not true at all - the ISP server would cache anyways while at the same
time you mix different things - what has the PTR query to do with any RBL?


Good grief you are too literal about everything.  Relax a little.
I was only talking cached DNS queries in general.  Someone else
on the list earlier mentioned that SA uses pseudo headers to keep
the DNS queries down so if the MTA did a PTR lookup, then SA did
the same PTR lookup, that would be multiple queries to the ISP
DNS server of which you have no control over the configuration.
It could be caching things too short or to long ignoring the record
TTLs or it could be returning altered responses.  You never know
for sure


i am relaxed

if you want have control -> install a local resolver

the price which is currently paied for save a single dns query for the 
PTR lookup is that you also have no control *what* that "unkonwn" means, 
it can be anything from


* bad MTA header
* DNS timeout to the resolver (which you have no control)
* connectivity issues on the ISP resolver
* timeouts on the autoritative nameserver for the reverse zone
* network issues on the autoritative nameserver for the reverse zone
* FCrDNS failure
* a *real* NXDOMAIN which is the only valid RDNS_NONE trigger

and they are all scored identical while a NXDOMAIn deserves a very high 
score, a DNS timeout a very low one because you have no clue at that 
moment and a no-FCrDNS deserves something between





signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[John Hardin]

On Tue, 24 Nov 2015, Reindl Harald wrote:


i would suggest when the Received header for the *first* untrusted hop


Just so we're clear on first vs. last: the host that submitted the mail to 
the most-remote MTA whose headers you trust.


don't contain a reverse dns information *and only then* do that lookup 
directly in SA if network tests are enabled


This seems to me a reasonable approach. There's no need to check RDNS on 
hops prior to the final untrusted hop (chronologically speaking).


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  To be civilized is to restrain the ability to commit mayhem.
  To be incapable of committing mayhem is not the mark of the
  civilized, merely the domesticated.-- Trefor Thomas
---

Re: question re/ RDNS_NONE

[Benny Pedersen]

On November 25, 2015 12:15:45 AM John Hardin <jhar...@impsec.org> wrote:


It would  be the last relay into the internal network, if it's from an
untrusted server. The edge of the trusted network may be a submission
server.


You don't trust the headers your submission server generates?


rdns_none possible missing exceptions for getmail / fetchmail,  see sample 
headers in this now very long thread :(

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Tuesday, November 24, 2015 a las 08:27:45PM +0100, Edda escribió:

> Anyway, for the moment, here's the patch, diff is on version 3.4.1:
> 
> Rule (I tested it as a simple rule in local.cf, sure one can combine it 
> with RDNS_NONE):
> 
> ifplugin Mail::SpamAssassin::Plugin::DNSEval
> 
> header NO_RDNS_FOR_LAST_EXTERNAL  eval:check_dns_rdns()
> describe NO_RDNS_FOR_LAST_EXTERNALLast External really has no rdns
> tflags NO_RDNS_FOR_LAST_EXTERNAL  net
> score NO_RDNS_FOR_LAST_EXTERNAL  1.00
> 
> endif
> 
> pop:Mail eh$ diff -u SpamAssassin/Plugin/DNSEval.pm.ORG 
> SpamAssassin/Plugin/DNSEval.pm
> --- SpamAssassin/Plugin/DNSEval.pm.ORG2015-11-24 19:02:58.0 
> +0100
> +++ SpamAssassin/Plugin/DNSEval.pm2015-11-24 19:25:59.0 +0100
> @@ -58,6 +58,7 @@
>   'check_rbl_from_host',
>   'check_rbl_from_domain',
>   'check_rbl_envfrom',
> +'check_dsn_rdns',
>   'check_dns_sender',
> ];
> 
> @@ -373,6 +374,25 @@
> }
>   }
> 
> +sub check_dns_rdns {
> +  my ($self, $pms, $rule) = @_;
> +
> +  my $lasthop = $pms->{relays_external}->[0];
> +  return 0 unless defined $lasthop;
> +
> +  # Perform reverse lookup only, if empty and mta is known to not 
> always insert rdns
> +  return 0 unless (! $lasthop->{rdns} && $lasthop->{rdns_not_in_headers});
> +
> +  return 0 unless $pms->is_dns_available();
> +  $pms->load_resolver();
> +
> +  dbg("dns: checking rDNS for last external ip $lasthop->{ip}");
> +
> +  $pms->do_dns_lookup($rule, 'PTR', $lasthop->{ip});
> +
> +  return 0;
> +}
> +
>   sub check_dns_sender {
> my ($self, $pms, $rule) = @_;
> 
> 
> pop:Mail eh$ diff -u SpamAssassin/Dns.pm.ORG SpamAssassin/Dns.pm
> --- SpamAssassin/Dns.pm.ORG2015-11-24 19:01:59.0 +0100
> +++ SpamAssassin/Dns.pm2015-11-24 19:02:39.0 +0100
> @@ -257,6 +257,12 @@
>   for my $rule (@{$rules}) {
> $self->got_hit($rule, "DNS: ", ruletype => "dns");
>   }
> +  } elsif ($question->qtype =~ /^(PTR)$/ &&
> +  $packet->header->rcode =~ /^(?:NXDOMAIN|SERVFAIL)$/)
> +  {
> +for my $ptr_rule (@{$rules}) {
> +  $self->got_hit($ptr_rule, "DNS: ", ruletype => "dns");
> +}
> }
> 
> # DNSBL tests are here


Hello,

I have applied your patch by hand (had to change $packet->... by $pkt-> ...)
but it gives the following warning when I run it through -tD:

nov 25 08:12:51.207 [2017] warn: rules: failed to run NO_RDNS_FOR_LAST_EXTERNAL 
RBL test, skipping:
nov 25 08:12:51.207 [2017] warn:  (Can't locate object method "check_dns_rdns" 
via package "Mail: [...]:SpamAssassin::PerMsgStatus" at 
/usr/local/lib/perl5/site_perl/5.16/Mail/SpamAssassin/Plugin/Check.pm line 271.)

Why I do miss?

Thanks

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[David Jones]

>From: RW <rwmailli...@googlemail.com>
>Sent: Sunday, November 22, 2015 3:23 PM
>To: users@spamassassin.apache.org
>Subject: Re: question re/ RDNS_NONE

>On Sun, 22 Nov 2015 13:39:49 +
>David Jones wrote:

>> https://wiki.apache.org/spamassassin/Rules/RDNS_NONE
>>
>> RDNS_NONE checks more than just the PTR (reverse) DNS record.
>> It really should be named FCRDNS_NONE

>Then the wiki is wrong.

Could this be dependent on the MTA used?  I am using Postfix
which puts in Received headers like this:

Received: from econnect.dmsgs.com (unknown [8.224.216.57])

That IP has a PTR record but it doesn't match the SMTP HELO of
econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
the RDNS_NONE hit on more than just no rDNS.

This has been true for years in my SpamAssassin platform
filtering about 95K mailboxes so in my case, the RDNS_NONE
does mean a FCrDNS (full circle DNS) check failed and the wiki
is correct.

Maybe this SA rule works differently on other MTAs.

Dave

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 17:03 schrieb Martin Gregorie:

On Tue, 2015-11-24 at 14:59 +0100, Reindl Harald wrote:


the topic is about the IP vom the Received-header of the trusted IP,
in
other words about the non-trusted machine delivered the message to
the ISP


I'm curious: if you're willing to trust an ISP's MTA, what reasons
would you have for not trusting its MXs? Presumably they are either
running fairly tightly constrained firewalls or are inside one


why not read the thread from thje first beginning?

i dunno why the OP is fetching his mail from his ISP and then feed 
spamassassin with the mails local, *but* he does and the received header 
of the ISP is the reason RDNS_NONE is triggered for *every* mail


most likely because "fairly tightly constrained firewalls" is simply 
wrong for most ISP setups because they don't invest much energy to train 
filters and try to avoid FP's to minimize support calls




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 19:47 schrieb David Jones:

Could this be dependent on the MTA used?  I am using Postfix
which puts in Received headers like this:

Received: from econnect.dmsgs.com (unknown [8.224.216.57])

That IP has a PTR record but it doesn't match the SMTP HELO of
econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
the RDNS_NONE hit on more than just no rDNS.

This has been true for years in my SpamAssassin platform
filtering about 95K mailboxes so in my case, the RDNS_NONE
does mean a FCrDNS (full circle DNS) check failed and the wiki
is correct.

Maybe this SA rule works differently on other MTAs


and that is why i call it harmful to completly rely on the Received 
header instead doing the DNS lookup based on the IP which would have a 
lot of advantages:


* less error prone
* even when the MTA had a timeout a chance that this
  DNS rqeuest get answered properly, the MTA treats
  a timeout *completty* different and would *not*
  reject a mail if the answer is not an NXDOMAIN even
  if it is configured for reject clients without a PTR
* SpamAssassin has *no clue* what the "unknown" means
  it could have been a timeout or a NXDOMAIN

disadvantages - zero - there is no overhead for a chached DNS query



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[David Jones]

>From: Reindl Harald <h.rei...@thelounge.net>
>Sent: Tuesday, November 24, 2015 1:01 PM
>To: users@spamassassin.apache.org
>Subject: Re: question re/ RDNS_NONE

>Am 24.11.2015 um 19:47 schrieb David Jones:
>> Could this be dependent on the MTA used?  I am using Postfix
>> which puts in Received headers like this:
>>
>> Received: from econnect.dmsgs.com (unknown [8.224.216.57])
>>
>> That IP has a PTR record but it doesn't match the SMTP HELO of
>> econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
>> the RDNS_NONE hit on more than just no rDNS.
>>
>> This has been true for years in my SpamAssassin platform
>> filtering about 95K mailboxes so in my case, the RDNS_NONE
>> does mean a FCrDNS (full circle DNS) check failed and the wiki
>> is correct.
>>
>> Maybe this SA rule works differently on other MTAs

>and that is why i call it harmful to completly rely on the Received
>header instead doing the DNS lookup based on the IP which would have a
>lot of advantages:

>* less error prone
>* even when the MTA had a timeout a chance that this
>   DNS rqeuest get answered properly, the MTA treats
>   a timeout *completty* different and would *not*
>   reject a mail if the answer is not an NXDOMAIN even
>   if it is configured for reject clients without a PTR
>* SpamAssassin has *no clue* what the "unknown" means
>  it could have been a timeout or a NXDOMAIN

>disadvantages - zero - there is no overhead for a chached DNS query

I agree with you if the SA server is configured with a local caching
DNS server that is not forwarding and the /etc/resolv.conf is
pointing to 127.0.0.1.

We have seen a number of people ask for help on this mailing
list because their DNS was not setup like this which means SA
would generate a lot more queries to the ISP or Internet DNS
servers compounding the problem with free usage limits on
some RBLs.

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 20:16 schrieb David Jones:

From: Reindl Harald 
and that is why i call it harmful to completly rely on the Received
header instead doing the DNS lookup based on the IP which would have a
lot of advantages:



* less error prone
* even when the MTA had a timeout a chance that this
   DNS rqeuest get answered properly, the MTA treats
   a timeout *completty* different and would *not*
   reject a mail if the answer is not an NXDOMAIN even
   if it is configured for reject clients without a PTR
* SpamAssassin has *no clue* what the "unknown" means
  it could have been a timeout or a NXDOMAIN



disadvantages - zero - there is no overhead for a chached DNS query


I agree with you if the SA server is configured with a local caching
DNS server that is not forwarding and the /etc/resolv.conf is
pointing to 127.0.0.1.

We have seen a number of people ask for help on this mailing
list because their DNS was not setup like this which means SA
would generate a lot more queries to the ISP or Internet DNS
servers compounding the problem with free usage limits on
some RBLs


not true at all - the ISP server would cache anyways while at the same 
time you mix different things - what has the PTR query to do with any RBL?




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Tuesday, November 24, 2015 a las 05:08:20PM +0100, Reindl Harald 
escribió:

> i dunno why the OP is fetching his mail from his ISP and then feed 
> spamassassin with the mails local,

WHy you dunno this? My mail must arrive somewhere, from where I can
fetch it with fetchmail+imap when I'm online  again with my FreeBSD netbook or
my Ubuntu mobile phone. Fetchmail feeds the mail locally to sendmail,
and this via procmail to spamd; and at the end it arrives in
/var/mail/guru from where I read it with the MUA mutt. What is wrong
with this procedure? This is doing fine for years now. The spamd in the
above pipeline is new, because I'm tired of SPAM. We used spamassassin
years ago in my company and I just set it now up on my netbook. It
filters away nearly all SPAM since bayes is trained enough now.

> *but* he does and the received header 
> of the ISP is the reason RDNS_NONE is triggered for *every* mail

Exactly. I was asking me (and the list) why all got RDNS_NONE fired, and
now we know it: ISP's fault.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Edda]

Am 24.11.15 um 14:40 schrieb Matthias Apitz:

El día Tuesday, November 24, 2015 a las 01:47:23PM +0100, Reindl Harald 
escribió:


On 24.11.15 13:24, Reindl Harald wrote:

on the other hand why can't SA not do the lookup for the IP of
"Received: from [140.211.11.3]" given that it does a lot of dns
lookups anyway?

just because of that - to limit the number of outgoing DNS requests and
focus on that haven't been done before.  That's why SA uses existing
headers
like Received: and Received-SPF:

[...]

If someone would have a patch for this, I'd be happy to help testing.



Older versions performed rdns lookups for every IP in relay-untrusted 
directly in Received.pm, this was deleted:


https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054

The attached patch adds one dns request, in fact that rdns is empty and 
the mta is known (via Received.pm) to not always add one.


I added the check as another eval in DNSEval.pm. This seems 
straightforward.
Then I realized, that Spamassassin doesn't catch the DNS responses from 
its Resolver in a very generic way. It catches only RBL returns and, as 
a hack for a specific rule, a special MX/A record.

Therefore I had to change Dns.pm as well, which I'm not happy with it ;)
Btw. I think it works also for __CGATE_RCVD and __DOMINO_RCVD, i.e. for 
all mtas, that decline to add rdns themselves.


The BOTNET plugin performs it's reverse lookup in a primitive way on 
it's own. IMO it's better to use the Spamassassin Resolver, but more 
generic, for the existing NO_DNS_FOR_FROM rule and for the RDNS_NONE one.


Any suggestions are welcome.

Edda


Anyway, for the moment, here's the patch, diff is on version 3.4.1:

Rule (I tested it as a simple rule in local.cf, sure one can combine it 
with RDNS_NONE):


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header NO_RDNS_FOR_LAST_EXTERNAL  eval:check_dns_rdns()
describe NO_RDNS_FOR_LAST_EXTERNALLast External really has no rdns
tflags NO_RDNS_FOR_LAST_EXTERNAL  net
score NO_RDNS_FOR_LAST_EXTERNAL  1.00

endif

pop:Mail eh$ diff -u SpamAssassin/Plugin/DNSEval.pm.ORG 
SpamAssassin/Plugin/DNSEval.pm
--- SpamAssassin/Plugin/DNSEval.pm.ORG2015-11-24 19:02:58.0 
+0100

+++ SpamAssassin/Plugin/DNSEval.pm2015-11-24 19:25:59.0 +0100
@@ -58,6 +58,7 @@
 'check_rbl_from_host',
 'check_rbl_from_domain',
 'check_rbl_envfrom',
+'check_dsn_rdns',
 'check_dns_sender',
   ];

@@ -373,6 +374,25 @@
   }
 }

+sub check_dns_rdns {
+  my ($self, $pms, $rule) = @_;
+
+  my $lasthop = $pms->{relays_external}->[0];
+  return 0 unless defined $lasthop;
+
+  # Perform reverse lookup only, if empty and mta is known to not 
always insert rdns

+  return 0 unless (! $lasthop->{rdns} && $lasthop->{rdns_not_in_headers});
+
+  return 0 unless $pms->is_dns_available();
+  $pms->load_resolver();
+
+  dbg("dns: checking rDNS for last external ip $lasthop->{ip}");
+
+  $pms->do_dns_lookup($rule, 'PTR', $lasthop->{ip});
+
+  return 0;
+}
+
 sub check_dns_sender {
   my ($self, $pms, $rule) = @_;


pop:Mail eh$ diff -u SpamAssassin/Dns.pm.ORG SpamAssassin/Dns.pm
--- SpamAssassin/Dns.pm.ORG2015-11-24 19:01:59.0 +0100
+++ SpamAssassin/Dns.pm2015-11-24 19:02:39.0 +0100
@@ -257,6 +257,12 @@
 for my $rule (@{$rules}) {
   $self->got_hit($rule, "DNS: ", ruletype => "dns");
 }
+  } elsif ($question->qtype =~ /^(PTR)$/ &&
+  $packet->header->rcode =~ /^(?:NXDOMAIN|SERVFAIL)$/)
+  {
+for my $ptr_rule (@{$rules}) {
+  $self->got_hit($ptr_rule, "DNS: ", ruletype => "dns");
+}
   }

   # DNSBL tests are here

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 20:24 schrieb Matthias Apitz:

El día Tuesday, November 24, 2015 a las 05:08:20PM +0100, Reindl Harald 
escribió:


i dunno why the OP is fetching his mail from his ISP and then feed
spamassassin with the mails local,


WHy you dunno this? My mail must arrive somewhere, from where I can
fetch it with fetchmail+imap when I'm online again with my FreeBSD netbook or
my Ubuntu mobile phone


normally a sane ISP *should* have proper spamfilters and provide IMAP 
directly, so no need for fetchmail and a local filter - but your 
decision, if i would be you i would rop the ISP, point the MX to a cheap 
VPS and install my own MTA + Postscreen + SpamAssassin + IMAP there



*but* he does and the received header
of the ISP is the reason RDNS_NONE is triggered for *every* mail


Exactly. I was asking me (and the list) why all got RDNS_NONE fired, and
now we know it: ISP's fault


and a fragile rely with no but and if on a Recieved header



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[David Jones]

>From: Reindl Harald <h.rei...@thelounge.net>
>Sent: Tuesday, November 24, 2015 1:20 PM
>To: users@spamassassin.apache.org
>Subject: Re: question re/ RDNS_NONE

>Am 24.11.2015 um 20:16 schrieb David Jones:
>>> From: Reindl Harald <h.rei...@thelounge.net>
>>> and that is why i call it harmful to completly rely on the Received
>>> header instead doing the DNS lookup based on the IP which would have a
>>> lot of advantages:
>>
>>> * less error prone
>>> * even when the MTA had a timeout a chance that this
>>>DNS rqeuest get answered properly, the MTA treats
>>>a timeout *completty* different and would *not*
>>>reject a mail if the answer is not an NXDOMAIN even
>>>if it is configured for reject clients without a PTR
>>> * SpamAssassin has *no clue* what the "unknown" means
>>>   it could have been a timeout or a NXDOMAIN
>>
>>> disadvantages - zero - there is no overhead for a chached DNS query
>>
>> I agree with you if the SA server is configured with a local caching
>> DNS server that is not forwarding and the /etc/resolv.conf is
>> pointing to 127.0.0.1.
>>
>> We have seen a number of people ask for help on this mailing
>> list because their DNS was not setup like this which means SA
>> would generate a lot more queries to the ISP or Internet DNS
>> servers compounding the problem with free usage limits on
>> some RBLs

>not true at all - the ISP server would cache anyways while at the same
>time you mix different things - what has the PTR query to do with any RBL?

Good grief you are too literal about everything.  Relax a little.
I was only talking cached DNS queries in general.  Someone else
on the list earlier mentioned that SA uses pseudo headers to keep
the DNS queries down so if the MTA did a PTR lookup, then SA did
the same PTR lookup, that would be multiple queries to the ISP
DNS server of which you have no control over the configuration.
It could be caching things too short or to long ignoring the record
TTLs or it could be returning altered responses.  You never know
for sure.

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 20:27 schrieb Edda:

Am 24.11.15 um 14:40 schrieb Matthias Apitz:

El día Tuesday, November 24, 2015 a las 01:47:23PM +0100, Reindl
Harald escribió:


On 24.11.15 13:24, Reindl Harald wrote:

on the other hand why can't SA not do the lookup for the IP of
"Received: from [140.211.11.3]" given that it does a lot of dns
lookups anyway?

just because of that - to limit the number of outgoing DNS requests and
focus on that haven't been done before.  That's why SA uses existing
headers
like Received: and Received-SPF:

[...]

If someone would have a patch for this, I'd be happy to help testing.


Older versions performed rdns lookups for every IP in relay-untrusted
directly in Received.pm, this was deleted:


well, perform a rdns lookup is nonsense - the only interesting one is 
the first untrusted which tried to deliver the mail



https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054

The attached patch adds one dns request, in fact that rdns is empty and
the mta is known (via Received.pm) to not always add one.

I added the check as another eval in DNSEval.pm. This seems
straightforward.
Then I realized, that Spamassassin doesn't catch the DNS responses from
its Resolver in a very generic way. It catches only RBL returns and, as
a hack for a specific rule, a special MX/A record.
Therefore I had to change Dns.pm as well, which I'm not happy with it ;)
Btw. I think it works also for __CGATE_RCVD and __DOMINO_RCVD, i.e. for
all mtas, that decline to add rdns themselves.

The BOTNET plugin performs it's reverse lookup in a primitive way on
it's own. IMO it's better to use the Spamassassin Resolver, but more
generic, for the existing NO_DNS_FOR_FROM rule and for the RDNS_NONE one.

Any suggestions are welcome


i would suggest when the Received header for the *first* untrusted hop 
don't contain a reverse dns information *and only then* do that lookup 
directly in SA if network tests are enabled


that would catch the OP's problem as well as *wrong* results when the 
"unknown" was the result of a DNS timeout on the MTA


i faced random RDNS_NONE which where clearly timeouts and SA has no 
chance to realize this


http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname

"The reply is always 450 in case the address->name lookup failed due to 
a temporary problem" but SA would still fire RDNS_NONE because the 
missing information


RDNS_NONE / FCrDNS / DNS timeout needs to be handeled and scored different




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Tuesday, November 24, 2015 a las 08:29:40PM +0100, Reindl Harald 
escribió:

> > WHy you dunno this? My mail must arrive somewhere, from where I can
> > fetch it with fetchmail+imap when I'm online again with my FreeBSD netbook 
> > or
> > my Ubuntu mobile phone
> 
> normally a sane ISP *should* have proper spamfilters 

yes, it *should* but does not;

> and provide IMAP 
> directly, so no need for fetchmail and a local filter - but your 
> decision,

I could use IMAP directly with, for example, mutt -f imaps://imap.1blu.de
and mutt can to SMTP upstream directly; but this would mean to be online
all the time while reading; in situations where you pay by time of
connection (for example in hotels in Havana), it is better to fetch all mails 
in a
few seconds, drop the Internet connection (and stop paying), read and
answer offline, open Internet again and send all answers out upstream at
once; do you get my point?

> if i would be you i would rop the ISP, point the MX to a cheap 
> VPS and install my own MTA + Postscreen + SpamAssassin + IMAP there

what is a VPS?

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Bill Cole]

On 24 Nov 2015, at 13:47, David Jones wrote:


Could this be dependent on the MTA used?  I am using Postfix
which puts in Received headers like this:

Received: from econnect.dmsgs.com (unknown [8.224.216.57])

That IP has a PTR record but it doesn't match the SMTP HELO of
econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
the RDNS_NONE hit on more than just no rDNS.


Incorrect. The HELO name (econnect.dmsgs.com) is not involved at all in 
why Postfix puts 'unknown' inside the parentheses.


Postfix puts "unknown" there because the PTR resolves to 
smtp-55-unassigned.dmsgs.com but smtp-55-unassigned.dmsgs.com has no A 
record resolving back to 8.224.216.57. It appears that the people 
running DNS for 216.224.8.in-addr.arpa and dmsgs.com (apparently Digital 
Messaging Solutions, Inc. of Tuscon AZ, USA) have screwed up. Many 
nearby IPs also allocated to them have PTRs that resolve to names that 
have As resolving back to the IP, so presumably they aren't entirely 
incompetent...

Re: question re/ RDNS_NONE

[David Jones]

>From: Bill Cole <sausers-20150...@billmail.scconsult.com>
>Sent: Tuesday, November 24, 2015 3:31 PM
>To: users@spamassassin.apache.org
>Subject: Re: question re/ RDNS_NONE

>On 24 Nov 2015, at 14:54, David Jones wrote:

>>> From: Bill Cole <sausers-20150...@billmail.scconsult.com>
>>> Sent: Tuesday, November 24, 2015 1:41 PM
>>> To: users@spamassassin.apache.org
>>> Subject: Re: question re/ RDNS_NONE
>>
>>> On 24 Nov 2015, at 13:47, David Jones wrote:
>>
>>>> Could this be dependent on the MTA used?  I am using Postfix
>>>> which puts in Received headers like this:
>>>>
>>>> Received: from econnect.dmsgs.com (unknown [8.224.216.57])
>>>>
>>>> That IP has a PTR record but it doesn't match the SMTP HELO of
>>>> econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
>>>> the RDNS_NONE hit on more than just no rDNS.
>>
>>> Incorrect. The HELO name (econnect.dmsgs.com) is not involved at all
>>> in
>>> why Postfix puts 'unknown' inside the parentheses.
>>
>> Thank you for that clarification.  However what you describe below
>> is one part of FCrDNS (a.k.a full circle DNS) check.  The second part
>> would be the PTR record matching the SMTP HELO.

>Where is the code or rule in SpamAssassin which performs that check?

I didn't mean to imply that this check is being done in SA.  Just meant
to show the parts of a FCrDNS check and that one of those checks
is effectively being done by Postfix putting in the 'unknown' when
the PTR lookup doesn't have a matching A record.  SA seems to be
seeing this 'unknown' in the Received header and hitting the
RDNS_NONE rule on my 8 mail filters.

>In Postfix there is no such check that I am aware of, either by default
>or with any of the optional smtpd_helo_restrictions settings. Can you
>point to it in the Postfix docs? What you describe is NOT part of the
>optional "reject_unknown_helo_hostname", which only requires a resolving
>HELO name.

I do not have any setting in my Postfix main.cf that would do that.
Just the standard smtpd_recipient_restrictions entries:
...
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_non_fqdn_hostname,
  reject_invalid_hostname,
  reject_unauth_destination,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unknown_reverse_client_hostname,
  reject_unlisted_sender,
  reject_unlisted_recipient,
...

>> So this still means
>> that the RDNS_NONE check is more than just a missing PTR record
>> when using Postfix.

>No PTR at all OR (as in the case you cited) a PTR to a name which
>doesn't resolve back to the IP will (if you allow Postfix to accept mail
>from such mismanaged machines) result in "unknown" being used where
>otherwise a correct hostname would go: inside parentheses, before the
>brackets-enclosed IP.  The HELO name, *WHATEVER IT IS* is put right
>after the word 'from' before the parentheses.

I do see these often and they do not hit RDNS_NONE in SA.

>NOTE: I have just now tested that I can give Postfix (with
>reject_unknown_helo_hostname not enabled) a fully-qualified HELO name
>that has no A or one with an A resolving to 192.0.2.1 (and therefore: no
>PTR) and in both cases Postfix neither logs anything about the "bad"
>name nor indicates any DNS discrepancy in its Received header.
>SpamAssassin's hits on the messages I sent myself that way include no
>rules involving DNS or HELO names.

You don't see 'unknown' in the Received: header?  Pretty sure that
mine would.  I am running Postfix 2.10.2 on a Redhat-based variant.

>Apart from whether Postfix or SA actually can be made to compare the
>result of a client IP  PTR resolution to the HELO name or of a HELO A
>result to the client IP, such verification is operationally worthless.
>There are far too many innocently misconfigured MTAs claiming to be
>localhost.localdomain or exchange01.local or whatever other default name
>is the flavor of the month to arbitrarily ignore RFC5321 and send them
>away. It generally IS safe to require that a HELO name be syntactically
>valid and not match a few patterns chronically used by spambots but
>unless you're fond of maintaining whitelists or of teaching users and a
>particularly dense sub-population of admins about wise DNS hygiene,
>validating HELO names tightly is wasted effort.

If I enable reject_unknown_helo_hostname, then I start blocking
a lot of legit email from poorly configured servers.

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 11:30 schrieb Benny Pedersen:

Matthias Apitz skrev den 2015-11-24 11:22:


As I get all my mails with this missing rDNS symbol in the Received:
line, I have only two options: unconfigure the RDNS_NONE test or change
the ISP.


two options:

1: make spamassassin exceptions for the faulty isp headers so rdns_none
does not fire, is it s non default exim compile ?


it's the exim of the ISP


2: change from exim to postfix, problem solved


it's the exim of the ISP


again disable of rdns_none is not the solution, so why fokus on that?


because *it is* the solution damned when "make spamassassin exceptions 
for the faulty isp headers" would do exactly the same, not fire the rule 
and since it affects *every* mail, well disable it



spamassasssin is not a single rule spam scanner / tagger


and hence you disable the rules which don't match your environment



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Tuesday, November 24, 2015 a las 11:30:31AM +0100, Benny Pedersen 
escribió:

> Matthias Apitz skrev den 2015-11-24 11:22:
> 
> > As I get all my mails with this missing rDNS symbol in the Received:
> > line, I have only two options: unconfigure the RDNS_NONE test or change
> > the ISP.
> 
> two options:
> 
> 1: make spamassassin exceptions for the faulty isp headers so rdns_none 
> does not fire, is it s non default exim compile ?
> 
> 2: change from exim to postfix, problem solved

Do you really understood that the Exim in question runs on a server of
my ISP which is not under my control?

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Benny Pedersen]

Matthias Apitz skrev den 2015-11-24 11:22:


As I get all my mails with this missing rDNS symbol in the Received:
line, I have only two options: unconfigure the RDNS_NONE test or change
the ISP.


two options:

1: make spamassassin exceptions for the faulty isp headers so rdns_none 
does not fire, is it s non default exim compile ?


2: change from exim to postfix, problem solved

again disable of rdns_none is not the solution, so why fokus on that ?

spamassasssin is not a single rule spam scanner / tagger

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 11:51 schrieb Benny Pedersen:

Matthias Apitz skrev den 2015-11-24 11:36:


Do you really understood that the Exim in question runs on a server of
my ISP which is not under my control?


if i was a isp, would never have used exim for a mta with so many users


how does that help the OP?


so option 1 is still left :=)


disable RDNS_NONE does the same


just not worth to solve in spamassassin if isp fixes there own problem


how does that help the OP?


but if this is not solved its possible to solve in a good way in
spamassassin local.cf, if it worth shareing it it could be added to
default spamassassin rules (exim 4.76) ?


local.cf and disable rules which don't work on a environment for 
whatever reason is the purpose "local.cf" exists


there are exactly 3 other rules with a dependency which *anyways* can't 
fire when RDNS_NONE don't fire for *whatever* reason


Nov 24 12:00:19 testserver.rhsoft.net spamd[30153]: rules: meta test 
GOOG_REDIR_NORDNS has dependency 'RDNS_NONE' with a zero score
Nov 24 12:00:19 testserver.rhsoft.net spamd[30153]: rules: meta test 
TO_NO_BRKTS_HTML_ONLY has dependency 'RDNS_NONE' with a zero score
Nov 24 12:00:19 testserver.rhsoft.net spamd[30153]: rules: meta test 
__TO_NO_BRKTS_NORDNS_HTML has dependency 'RDNS_NONE' with a zero score





signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Saturday, November 21, 2015 a las 06:57:41PM +, RW escribió:

> RDNS_NONE simply means that the received header on the edge of your
> internal network  (i.e. the MX header) didn't record the rDNS of the
> connecting host. 
> 
> Typically this means there it has no RDNS, but it can also mean that
> that server never records it, or the lookup timed-out due to networking
> problems. This ambiguity is why the rule has a relatively low
> default score.
> 
> When I ran it through spamassassin -D, this was identifed as the MX
> header and generated RDNS_NONE
> 
>   Received: from ms-10.1blu.de ([178.254.4.101])
> by mb-19.1blu.de (Dovecot) with LMTP id hf3FGWyHUFa9UgAAYCFinw
> for <w51246_0-g...@mb-19.1blu.de>; Sat, 21 Nov 2015 16:03:00
> +0100
> 
> Probably you need to setup your internal and/or trusted networks.

I have contacted the support of my ISP and phoned them today: the hotline
guy said, that the technican not even understood the problem and why there
should be together with the IP a rDNS, and why I can't do the lookup by
my own,  :-(

As I get all my mails with this missing rDNS symbol in the Received:
line, I have only two options: unconfigure the RDNS_NONE test or change
the ISP.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Benny Pedersen]

Matthias Apitz skrev den 2015-11-24 11:36:


Do you really understood that the Exim in question runs on a server of
my ISP which is not under my control?


if i was a isp, would never have used exim for a mta with so many users, 
so option 1 is still left :=)


just not worth to solve in spamassassin if isp fixes there own problem, 
but if this is not solved its possible to solve in a good way in 
spamassassin local.cf, if it worth shareing it it could be added to 
default spamassassin rules (exim 4.76) ?


https://www.google.dk/search?q=exim+4.76+headers

http://www.exim.org/ latest version is now 4.86

small isp ?

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 12:29 schrieb Benny Pedersen:

Reindl Harald skrev den 2015-11-24 11:56:


it's the exim of the ISP


with old version of exim


it's still the exim of the ISP


it's the exim of the ISP


with old version of exim


it's still the exim of the ISP


again disable of rdns_none is not the solution, so why fokus on that?


because *it is* the solution damned when "make spamassassin exceptions
for the faulty isp headers" would do exactly the same, not fire the
rule and since it affects *every* mail, well disable it


no isp might recieve mail from more then one single ip / domains, so
solve rdns_none with disable is incorrect with score 0


you really don't understand it - it don't matter from where the ISP 
receives mail when the Received-header don't contain the reverse DNS in 
general



if the 3 header exeption is added it would still work on other isps spam
sources breaking rfc rules on how headers should be


and how does that matter for a local setup using fetchmail from *that* ISP?


spamassasssin is not a single rule spam scanner / tagger

and hence you disable the rules which don't match your environment


bah, upgrade exim is not that hard is it ?


it's still the exim of the ISP - DAMNED - go out and update it, i wish 
you success




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[RW]

On Tue, 24 Nov 2015 11:22:20 +0100
Matthias Apitz wrote:


> I have contacted the support of my ISP and phoned them today: the
> hotline guy said, that the technican not even understood the problem
> and why there should be together with the IP a rDNS, and why I can't
> do the lookup by my own,  :-(

You can by running the BOTNET plugin.

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 13:00 schrieb RW:

On Tue, 24 Nov 2015 11:22:20 +0100
Matthias Apitz wrote:


I have contacted the support of my ISP and phoned them today: the
hotline guy said, that the technican not even understood the problem
and why there should be together with the IP a rDNS, and why I can't
do the lookup by my own,  :-(


You can by running the BOTNET plugin


on the other hand why can't SA not do the lookup for the IP of 
"Received: from [140.211.11.3]" given that it does a lot of dns lookups 
anyway?




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Benny Pedersen]

Reindl Harald skrev den 2015-11-24 11:56:


it's the exim of the ISP


with old version of exim


it's the exim of the ISP


with old version of exim


again disable of rdns_none is not the solution, so why fokus on that?


because *it is* the solution damned when "make spamassassin exceptions
for the faulty isp headers" would do exactly the same, not fire the
rule and since it affects *every* mail, well disable it


no isp might recieve mail from more then one single ip / domains, so 
solve rdns_none with disable is incorrect with score 0


if the 3 header exeption is added it would still work on other isps spam 
sources breaking rfc rules on how headers should be



spamassasssin is not a single rule spam scanner / tagger

and hence you disable the rules which don't match your environment


bah, upgrade exim is not that hard is it ?

Re: question re/ RDNS_NONE

[Tom Hendrikx]

Thank you both, please stop this pissing contest.

On 24-11-15 12:35, Reindl Harald wrote:
> 
> 
> Am 24.11.2015 um 12:29 schrieb Benny Pedersen:
>> Reindl Harald skrev den 2015-11-24 11:56:
>>
>>> it's the exim of the ISP
>>
>> with old version of exim
> 
> it's still the exim of the ISP
> 
>>> it's the exim of the ISP
>>
>> with old version of exim
> 
> it's still the exim of the ISP
> 
>>>> again disable of rdns_none is not the solution, so why fokus on that?
>>>
>>> because *it is* the solution damned when "make spamassassin exceptions
>>> for the faulty isp headers" would do exactly the same, not fire the
>>> rule and since it affects *every* mail, well disable it
>>
>> no isp might recieve mail from more then one single ip / domains, so
>> solve rdns_none with disable is incorrect with score 0
> 
> you really don't understand it - it don't matter from where the ISP
> receives mail when the Received-header don't contain the reverse DNS in
> general
> 
>> if the 3 header exeption is added it would still work on other isps spam
>> sources breaking rfc rules on how headers should be
> 
> and how does that matter for a local setup using fetchmail from *that* ISP?
> 
>>>> spamassasssin is not a single rule spam scanner / tagger
>>> and hence you disable the rules which don't match your environment
>>
>> bah, upgrade exim is not that hard is it ?
> 
> it's still the exim of the ISP - DAMNED - go out and update it, i wish
> you success
> 

Re: question re/ RDNS_NONE

[Matus UHLAR - fantomas]

On Tue, 24 Nov 2015 11:22:20 +0100
Matthias Apitz wrote:

I have contacted the support of my ISP and phoned them today: the
hotline guy said, that the technican not even understood the problem
and why there should be together with the IP a rDNS, and why I can't
do the lookup by my own,  :-(



Am 24.11.2015 um 13:00 schrieb RW:

You can by running the BOTNET plugin


On 24.11.15 13:24, Reindl Harald wrote:
on the other hand why can't SA not do the lookup for the IP of 
"Received: from [140.211.11.3]" given that it does a lot of dns 
lookups anyway?


just because of that - to limit the number of outgoing DNS requests and
focus on that haven't been done before.  That's why SA uses existing headers
like Received: and Received-SPF:

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
You have the right to remain silent. Anything you say will be misquoted,
then used against you. 

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 13:38 schrieb Matus UHLAR - fantomas:

On Tue, 24 Nov 2015 11:22:20 +0100
Matthias Apitz wrote:

I have contacted the support of my ISP and phoned them today: the
hotline guy said, that the technican not even understood the problem
and why there should be together with the IP a rDNS, and why I can't
do the lookup by my own,  :-(



Am 24.11.2015 um 13:00 schrieb RW:

You can by running the BOTNET plugin


On 24.11.15 13:24, Reindl Harald wrote:

on the other hand why can't SA not do the lookup for the IP of
"Received: from [140.211.11.3]" given that it does a lot of dns
lookups anyway?


just because of that - to limit the number of outgoing DNS requests and
focus on that haven't been done before.  That's why SA uses existing
headers
like Received: and Received-SPF:


in reality it would be not a "outgoing DNS request" because it's cached

it's obvious that the info is missing in the header, otherwise for a 
remote IP with no PTR on that place would appear "unknown" so you can 
even fire that DNS request only when it is needed




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Tuesday, November 24, 2015 a las 01:47:23PM +0100, Reindl Harald 
escribió:

> > On 24.11.15 13:24, Reindl Harald wrote:
> >> on the other hand why can't SA not do the lookup for the IP of
> >> "Received: from [140.211.11.3]" given that it does a lot of dns
> >> lookups anyway?
> >
> > just because of that - to limit the number of outgoing DNS requests and
> > focus on that haven't been done before.  That's why SA uses existing
> > headers
> > like Received: and Received-SPF:
> 
> in reality it would be not a "outgoing DNS request" because it's cached
> 
> it's obvious that the info is missing in the header, otherwise for a 
> remote IP with no PTR on that place would appear "unknown" so you can 
> even fire that DNS request only when it is needed
> 

If someone would have a patch for this, I'd be happy to help testing.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Axb]

On 11/24/2015 02:40 PM, Matthias Apitz wrote:

El día Tuesday, November 24, 2015 a las 01:47:23PM +0100, Reindl Harald 
escribió:


On 24.11.15 13:24, Reindl Harald wrote:

on the other hand why can't SA not do the lookup for the IP of
"Received: from [140.211.11.3]" given that it does a lot of dns
lookups anyway?


just because of that - to limit the number of outgoing DNS requests and
focus on that haven't been done before.  That's why SA uses existing
headers
like Received: and Received-SPF:


in reality it would be not a "outgoing DNS request" because it's cached

it's obvious that the info is missing in the header, otherwise for a
remote IP with no PTR on that place would appear "unknown" so you can
even fire that DNS request only when it is needed



If someone would have a patch for this, I'd be happy to help testing.



Take a look at the AskDNS plugin.

You may be able to make a rule for your need.
(or find a victim willing to help you with it)

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 24.11.2015 um 14:57 schrieb Martin Gregorie:

On Tue, 2015-11-24 at 12:00 +, RW wrote:

On Tue, 24 Nov 2015 11:22:20 +0100
Matthias Apitz wrote:



I have contacted the support of my ISP and phoned them today: the
hotline guy said, that the technican not even understood the
problem
and why there should be together with the IP a rDNS, and why I
can't
do the lookup by my own,  :-(


You can by running the BOTNET plugin.


Since you probably trust your ISP, why not add its MX(s) and MTA to
your trusted_networks list in local.cf?

This will stop SA from doing rDNS lookups on them


the topic is about the IP vom the Received-header of the trusted IP, in 
other words about the non-trusted machine delivered the message to the ISP




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Axb]

On 11/24/2015 02:46 PM, Axb wrote:

On 11/24/2015 02:40 PM, Matthias Apitz wrote:

El día Tuesday, November 24, 2015 a las 01:47:23PM +0100, Reindl
Harald escribió:


On 24.11.15 13:24, Reindl Harald wrote:

on the other hand why can't SA not do the lookup for the IP of
"Received: from [140.211.11.3]" given that it does a lot of dns
lookups anyway?


just because of that - to limit the number of outgoing DNS requests and
focus on that haven't been done before.  That's why SA uses existing
headers
like Received: and Received-SPF:


in reality it would be not a "outgoing DNS request" because it's cached

it's obvious that the info is missing in the header, otherwise for a
remote IP with no PTR on that place would appear "unknown" so you can
even fire that DNS request only when it is needed



If someone would have a patch for this, I'd be happy to help testing.



Take a look at the AskDNS plugin.

You may be able to make a rule for your need.
(or find a victim willing to help you with it)


forget it - wrong tool.. sorry

Re: question re/ RDNS_NONE

[Martin Gregorie]

On Tue, 2015-11-24 at 12:00 +, RW wrote:
> On Tue, 24 Nov 2015 11:22:20 +0100
> Matthias Apitz wrote:
> 
> 
> > I have contacted the support of my ISP and phoned them today: the
> > hotline guy said, that the technican not even understood the
> > problem
> > and why there should be together with the IP a rDNS, and why I
> > can't
> > do the lookup by my own,  :-(
> 
> You can by running the BOTNET plugin.

Since you probably trust your ISP, why not add its MX(s) and MTA to
your trusted_networks list in local.cf? 

This will stop SA from doing rDNS lookups on them.

Martin

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 10:46:42AM +0200, Jari Fredriksson 
escribió:

> >>> $ host 140.211.11.3
> >>> 3.11.211.140.in-addr.arpa domain name pointer hermes.apache.org.
> >>>
> >>>   matthias
> >>>
> >>
> >> Blah. That is NOT normal.
> >
> > What do you want to say exactly with 'Blah. That is NOT normal.'?
> >
> 
> Just that I do not see RDNS_NONE usually. Nearly all my incoming has a rDNS.

And what does this help in my case? Your mail through apache.org comes
again with

*  0.8 RDNS_NONE Delivered to internal network by a host with no rDNS

Maybe it's the SA version, mine is 3.4.0, yours 3.4.1?

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 09:57 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 10:46:42AM +0200, Jari Fredriksson 
escribió:

$ host 140.211.11.3
3.11.211.140.in-addr.arpa domain name pointer hermes.apache.org.

matthias



Blah. That is NOT normal.


What do you want to say exactly with 'Blah. That is NOT normal.'?



Just that I do not see RDNS_NONE usually. Nearly all my incoming has a rDNS.


And what does this help in my case?


nothing but "It really should be named FCRDNS_NONE" is wrong


Your mail through apache.org comes
again with

    *  0.8 RDNS_NONE Delivered to internal network by a host with no rDNS

Maybe it's the SA version, mine is 3.4.0, yours 3.4.1?


what about fix your internal_networks / trusted_networks settings?



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 10:20:37AM +0100, Reindl Harald escribió:

> > Your mail through apache.org comes
> > again with
> >
> > *  0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
> >
> > Maybe it's the SA version, mine is 3.4.0, yours 3.4.1?
> 
> what about fix your internal_networks / trusted_networks settings?

What should I fix exactly if apache.org triggers this RDNS_NONE:

$ fgrep RDNS_NONE /tmp/apache.d
nov 23 08:30:06.666 [2204] dbg: rules: ran header rule __RDNS_NONE ==> got 
hit: "[ ip=140.211.11.3 rdns= "

you can find the full -D output of such a mail here:

http://www.unixarea.de/apache.d.txt

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 10:38:20AM +0100, Reindl Harald escribió:

> > $ fgrep RDNS_NONE /tmp/apache.d
> > nov 23 08:30:06.666 [2204] dbg: rules: ran header rule __RDNS_NONE ==> 
> > got hit: "[ ip=140.211.11.3 rdns= "
> >
> > you can find the full -D output of such a mail here:
> >
> > http://www.unixarea.de/apache.d.txt
> 
> post the full headers of that message
> 

Here it is:


>From users-return-110371-guru=unixarea...@spamassassin.apache.org Mon Nov 23 
>07:12:54 2015
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on c720-r276659
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN,
FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RDNS_NONE autolearn=no
autolearn_force=no version=3.4.0
X-Spam-Report: +
*  0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail 
provider
*  (rwmaillists[at]googlemail.com)
*  0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level 
mail
*  domains are different
*  0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
*  EnvelopeFrom freemail headers are different
*  1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
Received: from c720-r276659 (c720-r276659 [127.0.0.1])
by localhost.unixarea.de (8.14.9/8.14.9) with ESMTP id tAN6CrU3001029
for <guru@localhost>; Mon, 23 Nov 2015 07:12:54 +0100 (CET)
(envelope-from 
users-return-110371-guru=unixarea...@spamassassin.apache.org)
Delivered-To: <w51246_0-g...@mb-19.1blu.de>
Received: from imap.1blu.de [178.254.4.78]
by c720-r276659 with IMAP (fetchmail-6.3.26)
for <guru@localhost> (single-drop); Mon, 23 Nov 2015 07:12:54 +0100 
(CET)
Received: from ms-10.1blu.de ([178.254.4.101])
by mb-19.1blu.de (Dovecot) with LMTP id WZG0HMExUlZlagAAYCFinw
for <w51246_0-g...@mb-19.1blu.de>; Sun, 22 Nov 2015 22:24:11 +0100
Received: from [140.211.11.3] (helo=mail.apache.org)
by ms-10.1blu.de with smtp (Exim 4.76)
(envelope-from 

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 10:43 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 10:38:20AM +0100, Reindl Harald escribió:


$ fgrep RDNS_NONE /tmp/apache.d
nov 23 08:30:06.666 [2204] dbg: rules: ran header rule __RDNS_NONE ==> got hit: 
"[ ip=140.211.11.3 rdns= "

you can find the full -D output of such a mail here:

http://www.unixarea.de/apache.d.txt


post the full headers of that message



Here it is:


blame your MTA our your MTA configuration for the way it adds received 
headers without name resolving, look at my recceived header and yours 
for 140.211.11.3



Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3p43V61hHXz28
for <h.rei...@thelounge.net>; Mon, 23 Nov 2015 10:44:30 +0100 (CET)


Received: from [140.211.11.3] (helo=mail.apache.org)
by ms-10.1blu.de with smtp (Exim 4.76)
	(envelope-from 

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 10:50:54AM +0100, Reindl Harald escribió:

> blame your MTA our your MTA configuration for the way it adds received 
> headers without name resolving, look at my recceived header and yours 
> for 140.211.11.3

Thanks. It is not my MTA, but the one of my ISP running on
ms-10.1blu.de. I will contact them.

> 
> Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
> by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3p43V61hHXz28
> for ; Mon, 23 Nov 2015 10:44:30 +0100 (CET)
> 
> 
> Received: from [140.211.11.3] (helo=mail.apache.org)
>   by ms-10.1blu.de with smtp (Exim 4.76)
>   (envelope-from 
> 

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 09:30 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 10:23:26AM +0200, Jari Fredriksson 
escribió:

This is exactly what I said in my first mail: the description of
RDNS_NONE is just wrong; nearly all my incoming mails are flagged by
RDNS_NONE; for example the mail I'm right now replying to which came
from apache.org says this when I run it through 'spamassassin -D':

$ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
$ fgrep RDNS_NONE /tmp/apache.d
nov 23 07:46:38.098 [1927] dbg: rules: ran header rule __RDNS_NONE ==> got hit: 
"[ ip=140.211.11.3 rdns= "
nov 23 07:46:39.203 [1927] dbg: check: 
tests=FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE

and 140.211.11.3 has a rDNS:

$ host 140.211.11.3
3.11.211.140.in-addr.arpa domain name pointer hermes.apache.org.


Blah. That is NOT normal.


What do you want to say exactly with 'Blah. That is NOT normal.'?


likely that it's not normal "nearly all my incoming mails are flagged by 
RDNS_NONE" nor that this list-messages get flagged


cat maillog | grep RDNS_NONE | wc -l
169

cat maillog | grep "spamd: result" | wc -l
45920

Nov 23 10:14:19 mail-gw spamd[20141]: spamd: result: . -102 - 
CUST_DNSWL_10,CUST_DNSWL_8,RCVD_IN_MSPIKE_H3,SHORTCIRCUIT,SHORTCIRCUIT_NET_HAM,USER_IN_SPF_WHITELIST 
scantime=0.2,size=92304,user=sa-milt,uid=189,required_score=5.5,rhost=localhost,raddr=127.0.0.1,rport=/run/spamassassin/spamassassin.sock,mid=<5652d8dec828b_e3c57c38c8651...@hermes-10.mail>,autolearn=disabled,shortcircuit=ham




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 01:04:07PM +0100, Benny Pedersen 
escribió:

> Matthias Apitz skrev den 2015-11-23 10:43:
> 
> >   meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD)
> 
> meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))
> 
> current rule will not work since both mta recieved must be negative not 
> matching, with my meta it is possible still the same but more readelble

What are CGATE_RCVD and DOMINO_RCVD? I do not see them in
https://wiki.apache.org/spamassassin/Rules/DOMINO_RCVD

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 13:18 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 01:04:07PM +0100, Benny Pedersen 
escribió:


Matthias Apitz skrev den 2015-11-23 10:43:


   meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD)


meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

current rule will not work since both mta recieved must be negative not
matching, with my meta it is possible still the same but more readelble


What are CGATE_RCVD and DOMINO_RCVD? I do not see them in
https://wiki.apache.org/spamassassin/Rules/DOMINO_RCVD


not every single tag has a wiki page

find.sh DOMINO_RCVD cf
/var/lib/spamassassin/3.004001/updates_spamassassin_org/20_dynrdns.cf

find.sh CGATE_RCVD cf
/var/lib/spamassassin/3.004001/updates_spamassassin_org/20_dynrdns.cf



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Benny Pedersen]

Matthias Apitz skrev den 2015-11-23 13:34:


#
meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

but it still gives always RDNS_NONE



it misses the 3dr header test for your isp to be added to the meta

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 13:55 schrieb Benny Pedersen:

Reindl Harald skrev den 2015-11-23 13:38:


score RDNS_NONE 0


why using spamassassin anyway?


what the hell are you talking about?

what do you child believe does "the 3dr header test for your isp to be 
added to the meta" different then just disable the rule?!


 Weitergeleitete Nachricht 
Betreff: Re: question re/ RDNS_NONE
Datum: Mon, 23 Nov 2015 13:51:05 +0100
Von: Benny Pedersen <m...@junc.eu>
Organisation: Jersore Underground Network Center
An: users@spamassassin.apache.org

it misses the 3dr header test for your isp to be added to the meta



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 01:48:58PM +0100, Reindl Harald escribió:

> >>> I set in my file .spamassassin/user_prefs
> >>>
> >>> meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))
> >>>
> >>> but it still gives always RDNS_NONE
> >>
> >> because it does the same as the original rule, Bennys post don't make
> >
> > I do not see any affect of the above:
> >
> > $ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
> > $ egrep -i 'DOMIN|GATE' /tmp/apache.d
> 
> honestly *what* do you expect?

Honestly, I wanted to see if the above 'meta ...' statement has any
effect, it has no visible effect;

the same is true, when I set

meta RDNS_NONE 0

when I set 'score RDNS_NONE 0', then RDNS_NONE is switched off.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Benny Pedersen]

Matthias Apitz skrev den 2015-11-23 10:43:


  meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD)


meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

current rule will not work since both mta recieved must be negative not 
matching, with my meta it is possible still the same but more readelble

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 13:04 schrieb Benny Pedersen:

Matthias Apitz skrev den 2015-11-23 10:43:


  meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD)


meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

current rule will not work since both mta recieved must be negative
not matching


and why would it not work?

(a > 1 && !b && !c)

as soon as not b *OR* not c the condition is untrue
the intention is *NOT* fire RDNS_NONE when one of the other hits
that's exactly what happens


with my meta it is possible still the same but more readelble


*lol* instead 2 simple and-conditions combine and/or with brackets more 
readable?




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Benny Pedersen]

Matthias Apitz skrev den 2015-11-23 13:18:

  meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && 
!__DOMINO_RCVD)

meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

current rule will not work since both mta recieved must be negative 
not
matching, with my meta it is possible still the same but more 
readelble


What are CGATE_RCVD and DOMINO_RCVD? I do not see them in
https://wiki.apache.org/spamassassin/Rules/DOMINO_RCVD


its known 2 mta that makes incorrect headers so RDNS cant be used from 
them, is your isp using another mta that also breaks headers like domino 
and commicate pro


the spamassamssin rule is correct but maybe missing a 3rd exception, i 
have not read all headers yet you have posted, but so far i think this 
is the case for your problem to get solved

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 13:34 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 01:26:25PM +0100, Benny Pedersen 
escribió:


its known 2 mta that makes incorrect headers so RDNS cant be used from
them, is your isp using another mta that also breaks headers like domino
and commicate pro

the spamassamssin rule is correct but maybe missing a 3rd exception, i
have not read all headers yet you have posted, but so far i think this
is the case for your problem to get solved


I set in my file .spamassassin/user_prefs

meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

but it still gives always RDNS_NONE


because it does the same as the original rule, Bennys post don't make 
any sense - why do you not just disable the rule when you know it don#t 
work on your environment?


meta RDNS_NONE 0

or

score RDNS_NONE 0




signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Benny Pedersen]

Reindl Harald skrev den 2015-11-23 13:38:


score RDNS_NONE 0


why using spamassassin anyway ?

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 01:26:25PM +0100, Benny Pedersen 
escribió:

> its known 2 mta that makes incorrect headers so RDNS cant be used from 
> them, is your isp using another mta that also breaks headers like domino 
> and commicate pro
> 
> the spamassamssin rule is correct but maybe missing a 3rd exception, i 
> have not read all headers yet you have posted, but so far i think this 
> is the case for your problem to get solved

I set in my file .spamassassin/user_prefs

#
meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

but it still gives always RDNS_NONE

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 01:38:12PM +0100, Reindl Harald escribió:

> Am 23.11.2015 um 13:34 schrieb Matthias Apitz:
> > El día Monday, November 23, 2015 a las 01:26:25PM +0100, Benny Pedersen 
> > escribió:
> >
> >> its known 2 mta that makes incorrect headers so RDNS cant be used from
> >> them, is your isp using another mta that also breaks headers like domino
> >> and commicate pro
> >>
> >> the spamassamssin rule is correct but maybe missing a 3rd exception, i
> >> have not read all headers yet you have posted, but so far i think this
> >> is the case for your problem to get solved
> >
> > I set in my file .spamassassin/user_prefs
> >
> > meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))
> >
> > but it still gives always RDNS_NONE
> 
> because it does the same as the original rule, Bennys post don't make 

I do not see any affect of the above:

$ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
$ egrep -i 'DOMIN|GATE' /tmp/apache.d

> any sense - why do you not just disable the rule when you know it don#t 
> work on your environment?
> 
> meta RDNS_NONE 0
> 
> or
> 
> score RDNS_NONE 0

yes; I will do that until the ISP fixed the problem; thaks  

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 13:43 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 01:38:12PM +0100, Reindl Harald escribió:


Am 23.11.2015 um 13:34 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 01:26:25PM +0100, Benny Pedersen 
escribió:


its known 2 mta that makes incorrect headers so RDNS cant be used from
them, is your isp using another mta that also breaks headers like domino
and commicate pro

the spamassamssin rule is correct but maybe missing a 3rd exception, i
have not read all headers yet you have posted, but so far i think this
is the case for your problem to get solved


I set in my file .spamassassin/user_prefs

meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))

but it still gives always RDNS_NONE


because it does the same as the original rule, Bennys post don't make


I do not see any affect of the above:

$ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
$ egrep -i 'DOMIN|GATE' /tmp/apache.d


honestly *what* do you expect?

is your server a Lotus Domino?
no!

is your server a CommuniGate Pro?
no!

header __DOMINO_RCVD  Received =~ /by \S+ \(Lotus Domino /
header __CGATE_RCVD   Received =~ /by \S+ \(CommuniGate Pro/

forget the crap Benny posted and try to understand that *both* rules 
(the first is the untouched from upstream) are doing exactly the same: 
*not* fire RDNS_NONE on *known broken mailservers* while yours is broken 
too but has no exception


meta RDNS_NONE  (__RDNS_NONE && !__CGATE_RCVD && !__DOMINO_RCVD)
meta RDNS_NONE  (__RDNS_NONE && !(__CGATE_RCVD || __DOMINO_RCVD))



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 10:23:26AM +0200, Jari Fredriksson 
escribió:

> On 23.11.2015 8.54, Matthias Apitz wrote:
> > El día Sunday, November 22, 2015 a las 09:23:40PM +, RW escribió:
> >>> https://wiki.apache.org/spamassassin/Rules/RDNS_NONE
> >>>
> >>> RDNS_NONE checks more than just the PTR (reverse) DNS record.
> >>> It really should be named FCRDNS_NONE
> >>
> >> Then the wiki is wrong.
> >
> > This is exactly what I said in my first mail: the description of
> > RDNS_NONE is just wrong; nearly all my incoming mails are flagged by
> > RDNS_NONE; for example the mail I'm right now replying to which came
> > from apache.org says this when I run it through 'spamassassin -D':
> >
> > $ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
> > $ fgrep RDNS_NONE /tmp/apache.d
> > nov 23 07:46:38.098 [1927] dbg: rules: ran header rule __RDNS_NONE ==> 
> > got hit: "[ ip=140.211.11.3 rdns= "
> > nov 23 07:46:39.203 [1927] dbg: check: 
> > tests=FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE
> > ...
> >
> > and 140.211.11.3 has a rDNS:
> >
> > $ host 140.211.11.3
> > 3.11.211.140.in-addr.arpa domain name pointer hermes.apache.org.
> >
> > matthias
> >
> 
> Blah. That is NOT normal.

What do you want to say exactly with 'Blah. That is NOT normal.'?

> 
> X-Originating-IP: 89.204.154.196
> X-Spam-Report:
>   * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, 
> high
>   *  trust
>   *  [140.211.11.3 listed in list.dnswl.org]
>   * -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
>   *  [140.211.11.3 listed in wl.mailspike.net]
>   *  0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level 
> mail
>   *  domains are different
>   * -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay 
> domain
>   *  0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
>   *  [SPF failed: Please see 
> http://www.openspf.net/Why?s=mfrom;id=users-return-110372-jarif%3Diki.fi%40spamassassin.apache.org;ip=195.140.195.194;r=gamecock.fredriksson.dy.fi]
>   * -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
> X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
>   gamecock.fredriksson.dy.fi
> 
> 
> -- 
> jarif.bit

-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045

Re: question re/ RDNS_NONE

[Martin Gregorie]

On Mon, 2015-11-23 at 09:57 +0100, Matthias Apitz wrote:
> And what does this help in my case? Your mail through apache.org
> comes
> again with
> 
>   *  0.8 RDNS_NONE Delivered to internal network by a host with
> no rDNS
> 
Who owns this host? 

If it belongs to you or is your ISP's mail delivery MTA for incoming
mail, why isn't it defined as part of your internal network?


Martin

Re: question re/ RDNS_NONE

[Jari Fredriksson]

On 23.11.2015 8.54, Matthias Apitz wrote:

El día Sunday, November 22, 2015 a las 09:23:40PM +, RW escribió:

https://wiki.apache.org/spamassassin/Rules/RDNS_NONE

RDNS_NONE checks more than just the PTR (reverse) DNS record.
It really should be named FCRDNS_NONE


Then the wiki is wrong.


This is exactly what I said in my first mail: the description of
RDNS_NONE is just wrong; nearly all my incoming mails are flagged by
RDNS_NONE; for example the mail I'm right now replying to which came
from apache.org says this when I run it through 'spamassassin -D':

$ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
$ fgrep RDNS_NONE /tmp/apache.d
nov 23 07:46:38.098 [1927] dbg: rules: ran header rule __RDNS_NONE ==> got hit: 
"[ ip=140.211.11.3 rdns= "
nov 23 07:46:39.203 [1927] dbg: check: 
tests=FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE
...

and 140.211.11.3 has a rDNS:

$ host 140.211.11.3
3.11.211.140.in-addr.arpa domain name pointer hermes.apache.org.

matthias



Blah. That is NOT normal.

X-Originating-IP: 89.204.154.196
X-Spam-Report:
* -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, 
high
*  trust
*  [140.211.11.3 listed in list.dnswl.org]
* -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
*  [140.211.11.3 listed in wl.mailspike.net]
*  0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level 
mail
*  domains are different
* -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay 
domain
*  0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
	*  [SPF failed: Please see 
http://www.openspf.net/Why?s=mfrom;id=users-return-110372-jarif%3Diki.fi%40spamassassin.apache.org;ip=195.140.195.194;r=gamecock.fredriksson.dy.fi]

* -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
gamecock.fredriksson.dy.fi


--
jarif.bit

Re: question re/ RDNS_NONE

[Jari Fredriksson]

On 23.11.2015 10.30, Matthias Apitz wrote:

El día Monday, November 23, 2015 a las 10:23:26AM +0200, Jari Fredriksson 
escribió:


On 23.11.2015 8.54, Matthias Apitz wrote:

El día Sunday, November 22, 2015 a las 09:23:40PM +, RW escribió:

https://wiki.apache.org/spamassassin/Rules/RDNS_NONE

RDNS_NONE checks more than just the PTR (reverse) DNS record.
It really should be named FCRDNS_NONE


Then the wiki is wrong.


This is exactly what I said in my first mail: the description of
RDNS_NONE is just wrong; nearly all my incoming mails are flagged by
RDNS_NONE; for example the mail I'm right now replying to which came
from apache.org says this when I run it through 'spamassassin -D':

$ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
$ fgrep RDNS_NONE /tmp/apache.d
nov 23 07:46:38.098 [1927] dbg: rules: ran header rule __RDNS_NONE ==> got hit: 
"[ ip=140.211.11.3 rdns= "
nov 23 07:46:39.203 [1927] dbg: check: 
tests=FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE
...

and 140.211.11.3 has a rDNS:

$ host 140.211.11.3
3.11.211.140.in-addr.arpa domain name pointer hermes.apache.org.

matthias



Blah. That is NOT normal.


What do you want to say exactly with 'Blah. That is NOT normal.'?



Just that I do not see RDNS_NONE usually. Nearly all my incoming has a rDNS.


--
jarif.bit

Re: question re/ RDNS_NONE

[Reindl Harald]

Am 23.11.2015 um 10:33 schrieb Matthias Apitz:

El día Monday, November 23, 2015 a las 10:20:37AM +0100, Reindl Harald escribió:


Your mail through apache.org comes
again with

*  0.8 RDNS_NONE Delivered to internal network by a host with no rDNS

Maybe it's the SA version, mine is 3.4.0, yours 3.4.1?


what about fix your internal_networks / trusted_networks settings?


What should I fix exactly if apache.org triggers this RDNS_NONE:

$ fgrep RDNS_NONE /tmp/apache.d
nov 23 08:30:06.666 [2204] dbg: rules: ran header rule __RDNS_NONE ==> got hit: 
"[ ip=140.211.11.3 rdns= "

you can find the full -D output of such a mail here:

http://www.unixarea.de/apache.d.txt


post the full headers of that message



signature.asc
Description: OpenPGP digital signature

Re: question re/ RDNS_NONE

[Benny Pedersen]

Matthias Apitz skrev den 2015-11-23 13:34:


but it still gives always RDNS_NONE


you will have to add your isp mta incomming ip to your trusted_networks 
in local.cf, then RDNS_NONE will be testing mails sent to your isp, 
currently you test broken isp mta setup that is fetched with fetchmail


disble RDNS_NONE with a score of 0 is incorrect

i can possible send you a email via your isp and you forward this one to 
me, so i can help you much better then others here ?

Re: question re/ RDNS_NONE

[RW]

On Mon, 23 Nov 2015 11:03:07 +0100
Matthias Apitz wrote:

> El día Monday, November 23, 2015 a las 10:50:54AM +0100, Reindl
> Harald escribió:
> 
> > blame your MTA our your MTA configuration for the way it adds
> > received headers without name resolving, look at my recceived
> > header and yours for 140.211.11.3  
> 
> Thanks. It is not my MTA, but the one of my ISP running on
> ms-10.1blu.de. I will contact them.

Don't do that, there's nothing wrong with their headers or DNS. The
rule is triggered by an internal handover from a submission server to
an IMAP server being misinterpreted as an MX handover, it's purely a
problem caused by your configuration.

However, fixing it may not be the best thing to do because once you
specify trusted/internal networks you have to maintain them, and a
third-party network can change it's IP addresses at any time. 

Take at look the mail that's delivered  though your provider's MX
servers (rather than submitted) and look whether it's working
correctly. If it's working well with the autoguesser, it may be better
not to specify any network setting and just mitigate the occasional
spurious RDNS_NONE with a local rule. 



Note that the public IP address of your provider's IMAP server in the
fetchmail header does not have to be in either your trusted or internal
networks because it's ignored. 

Re: question re/ RDNS_NONE

[Matus UHLAR - fantomas]

On 23.11.15 14:40, Benny Pedersen wrote:

Matthias Apitz skrev den 2015-11-23 13:34:


but it still gives always RDNS_NONE


you will have to add your isp mta incomming ip to your 
trusted_networks in local.cf, then RDNS_NONE will be testing mails 
sent to your isp, currently you test broken isp mta setup that is 
fetched with fetchmail



I would put that one even in the internal_networks, so SA can check hosts
the ISP received mail from... 
--

Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 01:46:14PM +, RW escribió:

> > > blame your MTA our your MTA configuration for the way it adds
> > > received headers without name resolving, look at my recceived
> > > header and yours for 140.211.11.3  
> > 
> > Thanks. It is not my MTA, but the one of my ISP running on
> > ms-10.1blu.de. I will contact them.
> 
> Don't do that, there's nothing wrong with their headers or DNS. The
> rule is triggered by an internal handover from a submission server to
> an IMAP server being misinterpreted as an MX handover, it's purely a
> problem caused by your configuration.

Why do you think that the missing rDNS name in this line:

  Received: from [140.211.11.3] (helo=mail.apache.org) by ms-10.1blu.de with 
smtp (Exim 4.76)
(envelope-from

Re: question re/ RDNS_NONE

[Edda]

Am 23.11.15 um 10:33 schrieb Matthias Apitz:

What should I fix exactly if apache.org triggers this RDNS_NONE:

$ fgrep RDNS_NONE /tmp/apache.d
nov 23 08:30:06.666 [2204] dbg: rules: ran header rule __RDNS_NONE ==> got hit: 
"[ ip=140.211.11.3 rdns= "

you can find the full -D output of such a mail here:

http://www.unixarea.de/apache.d.txt


Just looked at your -D output. Your configuration is correct as 
140.211.11.3 is correctly identified as Last External.


RDNS_NONE uses the pseudo header X-Spam-Relays-External and the pseudo 
headers are filled up with information from the Received headers, not 
from real DNS lookups. Take a look at the "dbg: received-header" and 
"dbg: metadata" lines in your debug output or at Received.pm.


nov 23 08:30:06.182 [2204] dbg: received-header: parsed as [ ip=140.211.11.3 
rdns= helo=mail.apache.org by=ms-10.1blu.de ident= 
envfrom=users-return-110371-guru=unixarea...@spamassassin.apache.org intl=0 
id=1a0c7H-0003WU-3m auth= msa=0 ]

...

nov 23 08:30:06.187 [2204] dbg: metadata: X-Spam-Relays-External: [ 
ip=140.211.11.3 rdns= helo=mail.apache.org by=ms-10.1blu.de ident= 
envfrom=users-return-110371-guru=unixarea...@spamassassin.apache.org intl=0 
id=1a0c7H-0003WU-3m auth= msa=0 ] ...

The received header added by your ISP misses the hostname, therefore 
RDNS_NONE hits on every mail:


Received: from [140.211.11.3] (helo=mail.apache.org)
by ms-10.1blu.de with smtp (Exim 4.76)

(envelope-from

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Monday, November 23, 2015 a las 11:58:29PM +0100, Edda escribió:

> Received: from [140.211.11.3] (helo=mail.apache.org)
>   by ms-10.1blu.de with smtp (Exim 4.76)
>   
> 

Re: question re/ RDNS_NONE

[Benny Pedersen]

Matthias Apitz skrev den 2015-11-23 15:04:


Why do you think that the missing rDNS name in this line:


none, mails from apache is not fetchmailed


  Received: from [140.211.11.3] (helo=mail.apache.org) by
ms-10.1blu.de with smtp (Exim 4.76)
(envelope-from

Re: question re/ RDNS_NONE

[RW]

On Mon, 23 Nov 2015 15:04:28 +0100
Matthias Apitz wrote:

> El día Monday, November 23, 2015 a las 01:46:14PM +, RW escribió:

> > Don't do that, there's nothing wrong with their headers or DNS. The
> > rule is triggered by an internal handover from a submission server
> > to an IMAP server being misinterpreted as an MX handover, it's
> > purely a problem caused by your configuration.  
> 
> Why do you think that the missing rDNS name in this line:
> 
>   Received: from [140.211.11.3] (helo=mail.apache.org) by
> ms-10.1blu.de with smtp (Exim 4.76) (envelope-from
>   

Re: question re/ RDNS_NONE

[Matthias Apitz]

El día Sunday, November 22, 2015 a las 09:23:40PM +, RW escribió:

> normal delivery. Getting the internal/trusted networks right for this
> kind of mail is of often significantly more difficult than dealing with
> the normal case, and may be more trouble than it's worth on a
> network you don't control. 
> 
> A test email that's sent through a third-party mail service is much more
> representative as a test.  
> 
> 
> > https://wiki.apache.org/spamassassin/Rules/RDNS_NONE
> > 
> > RDNS_NONE checks more than just the PTR (reverse) DNS record.
> > It really should be named FCRDNS_NONE 
> 
> Then the wiki is wrong.

This is exactly what I said in my first mail: the description of
RDNS_NONE is just wrong; nearly all my incoming mails are flagged by
RDNS_NONE; for example the mail I'm right now replying to which came
from apache.org says this when I run it through 'spamassassin -D':

$ spamassassin -tD < /tmp/apache > /tmp/apache.o 2> /tmp/apache.d
$ fgrep RDNS_NONE /tmp/apache.d
nov 23 07:46:38.098 [1927] dbg: rules: ran header rule __RDNS_NONE ==> got 
hit: "[ ip=140.211.11.3 rdns= "
nov 23 07:46:39.203 [1927] dbg: check: 
tests=FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE
...

and 140.211.11.3 has a rDNS:

$ host 140.211.11.3
3.11.211.140.in-addr.arpa domain name pointer hermes.apache.org.

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de,  http://www.unixarea.de/  ☎ 
+49-176-38902045