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 ; Mon, 23 Nov 2015 07:12:54 +0100 (CET)
(envelope-from 
users-return-110371-guru=unixarea...@spamassassin.apache.org)
Delivered-To: 
Received: from imap.1blu.de [178.254.4.78]
by c720-r276659 with IMAP (fetchmail-6.3.26)
for  (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 ; 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 ; 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: ClamAV.pm Plugin Not Working

[Matus UHLAR - fantomas]

On 21.11.15 20:26, Daniel L. Srebnick wrote:

The directory containing the socket file must be world readable and
executable.  Because was in my case owned by clamscan/clamscan, spamd
could not write to it.  I figured this out by running spamd as root for a
bit and saw that everything worked.


maybe group permissions could be enough: putting spamd to group that has read
permissions on the directory... 


--
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.
Fighting for peace is like fucking for virginity...

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: Re-2: A rule to check X-ASN header

[Benny Pedersen]

steve skrev den 2015-11-23 13:31:


asn plugin currently does not work with ipv6

I'll cross that bridge when I come to it.


i just still need self to debug why it fails, currently i have seen 
2.0.0.0/8 when ipv6 recieved in 26xx: :=)



and if you see mails pretending sent from google/gmail it wont be dkim
pass and spf pass


The example i saw last week was from "Google Audit"
, was DKIM signed and valid [but
obviously not by Google's key :)] and was asking a user to verifiy
thier account... URIs weren't blacklisted at the time.


co.uk is a domain and a tld, very cool :)

dont blame me on that

i can make google.junc.eu is it now google that spams you ?

yes i know co.uk is a valid tld, but spammers seems not knowing why not 
to use it



Test results of that scan were...

DKIM_SIGNED=0.1
DKIM_VALID=-0.1
DKIM_VALID_AU=-0.1
HTML_MESSAGE=0.001
KAM_COUK=0.1
MIME_HTML_ONLY=0.723
RP_MATCHES_RCVD=-0.582
SPF_PASS=-0.001
TXREP=1.105


what dkim domain, whois dkim-domain


My thought process was that emails with Google in the Senders Name or
email address should only really originate from IP addresses / ASN's
Google own (initial invesgation suggest gmail.com comes from AS15169
thought I've not thrown a wide net yet).


asn is nice but too unstable to make rules on

I feel its worth exploring for my purposes.


okay with me if you do with stable data


Any further advice will be grafefully recived.


possible start using dmarc ?

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: Re-2: A rule to check X-ASN header

[Axb]

On 11/23/2015 01:31 PM, steve wrote:

My thought process was that emails with Google in the Senders Name or
email address should only really originate from IP addresses / ASN's
Google own (initial invesgation suggest gmail.com comes from AS15169
thought I've not thrown a wide net yet).


a meta rule with rcvd header and From: header rules will do the trick, 
faster and simpler.

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 
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

A rule to check X-ASN header

[steve]

Hi all,

I'm trying to create a rule which will check the results of the ASN plugin. 

My longer term goal is to use this and the Sender information together to catch 
suspicious emails that have Google in the Senders Name but orginate from a non 
Google domain (eg somegoogledomainijustmadeup.com) and doesn't originate from a 
Google ASN (and therefore a Google IP range).

As a test I have the following...

ifplugin Mail::SpamAssassin::Plugin::ASN
   header  T_SCS_ASN_EXISTS  exists:X-ASN
   header  T_SCS_ASN_ANYTHINGX-ASN =~ /.*/i
   header  T_SCS_ASN_ANY_AS  X-ASN =~ /AS[0-9]*/i
   header  T_SCS_ASN_AS15169 X-ASN =~ /AS15169/
   header  T_SCS_ASN_AS15169BX-ASN =~ /^AS15169 /
endif

On a test message which I sent myself on Friday from my google account and 
which I am now currently pipping into SpamAssassin at the command line the 
rules T_SCS_ASN_EXISTS and T_SCS_ASN_ANYTHING trigger but T_SCS_ASN_ANY_AS, 
T_SCS_ASN_AS15169 and T_SCS_ASN_AS15169B.

I've dabbled with rule priorities but it didn't appear to make any difference.
In any case the message itself has no ASN header in it so the fact the 
T_SCS_ASN_EXISTS triggers suggests to me my rules are being run after the ASN 
plugin completes its work (?)

I initally had problems even getting SpamAssassin to find the ASN header but 
http://www.gossamer-threads.com/lists/spamassassin/users/178388 pointed out 
"The metadata pseudo-headers are available to rules with an X- prefix." and 
goes on to give an example ...

header AS X-ASN =~ /^AS / 

... which doesn't trigger on my system.

Heres the relevant output from scanning my test message...

# spamassassin -D < ~/test-asn.txt | & /usr/bin/grep -i ASN
Nov 23 11:54:04.401 [74846] dbg: config: read file 
/usr/local/etc/mail/spamassassin/Spectrum-ASN.cf
Nov 23 11:54:04.670 [74846] dbg: plugin: loading 
Mail::SpamAssassin::Plugin::ASN from @INC
Nov 23 11:54:04.890 [74846] dbg: config: fixed relative path: 
/var/db/spamassassin/3.004001/updates_spamassassin_org/25_asn.cf
Nov 23 11:54:04.890 [74846] dbg: config: using 
"/var/db/spamassassin/3.004001/updates_spamassassin_org/25_asn.cf" for included 
file
Nov 23 11:54:04.891 [74846] dbg: config: read file 
/var/db/spamassassin/3.004001/updates_spamassassin_org/25_asn.cf
Nov 23 11:54:05.457 [74846] dbg: plugin: did not register 
Mail::SpamAssassin::Plugin::ASN, already registered
Nov 23 11:54:12.332 [74846] dbg: plugin: 
Mail::SpamAssassin::Plugin::ASN=HASH(0x80a83d798) implements 'parsed_metadata', 
priority 0
Nov 23 11:54:12.337 [74846] dbg: asn: using first external relay IP for 
lookups: 74.125.82.50
Nov 23 11:54:12.337 [74846] dbg: async: launching 
TXT/50.82.125.74.asn.routeviews.org for asnlookup-0-asn.routeviews.org
Nov 23 11:54:12.345 [74846] dbg: dns: providing a callback for id: 
23747/IN/TXT/50.82.125.74.asn.routeviews.org
Nov 23 11:54:12.345 [74846] dbg: async: starting: TXT, 
asnlookup-0-asn.routeviews.org (timeout 15.0s, min 3.0s)
Nov 23 11:54:12.345 [74846] dbg: asn: launched DNS TXT query for 
50.82.125.74.asn.routeviews.org in background
Nov 23 11:54:12.345 [74846] dbg: async: query 
23747/IN/TXT/50.82.125.74.asn.routeviews.org already underway, adding no.2 
asnlookup-1-asn.routeviews.org
Nov 23 11:54:12.345 [74846] dbg: asn: launched DNS TXT query for 
50.82.125.74.asn.routeviews.org in background
Nov 23 11:54:12.345 [74846] dbg: async: launching 
TXT/50.82.125.74.ip2asn.sasm4.net for asnlookup-2-ip2asn.sasm4.net
Nov 23 11:54:12.346 [74846] dbg: dns: providing a callback for id: 
18937/IN/TXT/50.82.125.74.ip2asn.sasm4.net
Nov 23 11:54:12.346 [74846] dbg: async: starting: TXT, 
asnlookup-2-ip2asn.sasm4.net (timeout 15.0s, min 3.0s)
Nov 23 11:54:12.346 [74846] dbg: asn: launched DNS TXT query for 
50.82.125.74.ip2asn.sasm4.net in background
Nov 23 11:54:12.346 [74846] dbg: async: launching 
TXT/50.82.125.74.origin.asn.spameatingmonkey.net for 
asnlookup-3-origin.asn.spameatingmonkey.net
Nov 23 11:54:12.347 [74846] dbg: dns: providing a callback for id: 
21798/IN/TXT/50.82.125.74.origin.asn.spameatingmonkey.net
Nov 23 11:54:12.347 [74846] dbg: async: starting: TXT, 
asnlookup-3-origin.asn.spameatingmonkey.net (timeout 15.0s, min 3.0s)
Nov 23 11:54:12.347 [74846] dbg: asn: launched DNS TXT query for 
50.82.125.74.origin.asn.spameatingmonkey.net in background
Nov 23 11:54:12.379 [74846] dbg: async: calling callback on key 
asnlookup-0-asn.routeviews.org
Nov 23 11:54:12.379 [74846] dbg: asn: asn.routeviews.org: lookup result packet: 
50.82.125.74.asn.routeviews.org. 83431 IN TXT 15169 74.125.0.0 16
Nov 23 11:54:12.379 [74846] dbg: asn: ASNCIDR added route 74.125.0.0/16
Nov 23 11:54:12.379 [74846] dbg: asn: ASN added asn 15169
Nov 23 11:54:12.379 [74846] dbg: check: tagrun - tag ASN is now ready, value: 
AS15169
Nov 23 11:54:12.379 [74846] dbg: check: tagrun - tag ASNCIDR is now ready, 
value: 74.125.0.0/16
Nov 23 11:54:12.379 [74846] dbg: async: calling callback 

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: A rule to check X-ASN header

[Reindl Harald]

Am 23.11.2015 um 13:31 schrieb steve:

The example i saw last week was from "Google Audit" 
, was DKIM signed and valid [but obviously not by Google's 
key :)] and was asking a user to verifiy thier account... URIs weren't blacklisted at the time.
My thought process was that emails with Google in the Senders Name or email 
address should only really originate from IP addresses / ASN's Google own 
(initial invesgation suggest gmail.com comes from AS15169 thought I've not 
thrown a wide net yet).


how do you come to that strange conclusion?

that is a domain as any other and "with Google in the Senders Name or 
email address should only really originate" is by all respect pure 
nonsense - DKIM, SPF and DMARC are about *domains* and not *partly 
matches* of some special handeled large companies

_

Domain name:
googletechteam.co.uk

Registrant:
Alexander Duffus

Registrant type:
UK Individual

Registrant's address:
Bury House
Royston
Hertfordshire
SG8 8QB
United Kingdom



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: A rule to check X-ASN header

[Benny Pedersen]

steve skrev den 2015-11-23 13:05:


Any advice gratefully received!


asn plugin currently does not work with ipv6

and if you see mails pretending sent from google/gmail it wont be dkim 
pass and spf pass


asn is nice but too unstable to make rules on

Re-2: A rule to check X-ASN header

[steve]

Hi Benny,

>> asn plugin currently does not work with ipv6
I'll cross that bridge when I come to it.

> and if you see mails pretending sent from google/gmail it wont be dkim 
> pass and spf pass
 
The example i saw last week was from "Google Audit" 
, was DKIM signed and valid [but obviously not by 
Google's key :)] and was asking a user to verifiy thier account... URIs weren't 
blacklisted at the time.

Test results of that scan were...

DKIM_SIGNED=0.1
DKIM_VALID=-0.1
DKIM_VALID_AU=-0.1
HTML_MESSAGE=0.001
KAM_COUK=0.1
MIME_HTML_ONLY=0.723
RP_MATCHES_RCVD=-0.582
SPF_PASS=-0.001
TXREP=1.105

My thought process was that emails with Google in the Senders Name or email 
address should only really originate from IP addresses / ASN's Google own 
(initial invesgation suggest gmail.com comes from AS15169 thought I've not 
thrown a wide net yet).

> asn is nice but too unstable to make rules on
I feel its worth exploring for my purposes.

Any further advice will be grafefully recived.

Regards

Steve

 Original Message 
Subject: Re: A rule to check X-ASN header (23-Nov-2015 12:13)
From:Benny Pedersen 
To:  st...@mailinglists.spectrumcs.net

> steve skrev den 2015-11-23 13:05:
> 
> > Any advice gratefully received!
> 
> asn plugin currently does not work with ipv6
> 
> and if you see mails pretending sent from google/gmail it wont be dkim 
> pass and spf pass
> 
> asn is nice but too unstable to make rules on
> 
> To: users@spamassassin.apache.org

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-4: A rule to check X-ASN header

[steve]

> steve skrev den 2015-11-23 13:31:
> 
> >>> asn plugin currently does not work with ipv6
> > I'll cross that bridge when I come to it.
> 
> i just still need self to debug why it fails, currently i have seen 
> 2.0.0.0/8 when ipv6 recieved in 26xx: :=)
> 
> >> and if you see mails pretending sent from google/gmail it wont be dkim
> >> pass and spf pass
> > 
> > The example i saw last week was from "Google Audit"
> > , was DKIM signed and valid [but
> > obviously not by Google's key :)] and was asking a user to verifiy
> > thier account... URIs weren't blacklisted at the time.
> 
> co.uk is a domain and a tld, very cool :)
> 
> dont blame me on that
> 
> i can make google.junc.eu is it now google that spams you ?

That was just one example I received. Yes, you can very well use google.junc.en 
and no that doesn't mean Google spams me.

My eventual goal is to test for "Has google in the sender name OR domain" and 
"is NOT from a ASN owned by Google".

https://www.ultratools.com/tools/asnInfoResult?domainName=Google

Am I'm not explaining myself correctly?

> 
> yes i know co.uk is a valid tld, but spammers seems not knowing why not 
> to use it
> 
> > Test results of that scan were...
> > 
> > DKIM_SIGNED=0.1
> > DKIM_VALID=-0.1
> > DKIM_VALID_AU=-0.1
> > HTML_MESSAGE=0.001
> > KAM_COUK=0.1
> > MIME_HTML_ONLY=0.723
> > RP_MATCHES_RCVD=-0.582
> > SPF_PASS=-0.001
> > TXREP=1.105
> 
> what dkim domain, whois dkim-domain

It was DKIM signed by the senders domain googletechteam.co.uk.

> 
> > My thought process was that emails with Google in the Senders Name or
> > email address should only really originate from IP addresses / ASN's
> > Google own (initial invesgation suggest gmail.com comes from AS15169
> > thought I've not thrown a wide net yet).
> > 
> >> asn is nice but too unstable to make rules on
> > I feel its worth exploring for my purposes.
> 
> okay with me if you do with stable data
Thanks
> 
> > Any further advice will be grafefully recived.
> 
> possible start using dmarc ?
Not sure how that would help in the situation I've outlined?

Overall, while i appericate your efforts and discussions about the validatility 
of my objectives, what I'm really after is how can I query the X-ASN header?

If this turns out to be a waste of time I'll be the first to let you know.

Many thanks

Steve
> 
> To: users@spamassassin.apache.org

Re-4: A rule to check X-ASN header

[steve]

> > My thought process was that emails with Google in the Senders Name or
> > email address should only really originate from IP addresses / ASN's
> > Google own (initial invesgation suggest gmail.com comes from AS15169
> > thought I've not thrown a wide net yet).
> 
> a meta rule with rcvd header and From: header rules will do the trick, 
> faster and simpler.
> 
Good thinking. I'll investigate this futher.

Thanks

Steve

Re-2: A rule to check X-ASN header

[steve]

> > The example i saw last week was from "Google Audit"  > co.uk>, was DKIM signed and valid [but obviously not by Google's key :)] 
> > and was asking a user to verifiy thier account... URIs weren't blacklisted 
> > at the time.
> > My thought process was that emails with Google in the Senders Name or email 
> > address should only really originate from IP addresses / ASN's Google own (
> > initial invesgation suggest gmail.com comes from AS15169 thought I've not 
> > thrown a wide net yet).
> 
> how do you come to that strange conclusion?
> 
> that is a domain as any other and "with Google in the Senders Name or 
> email address should only really originate" is by all respect pure 
> nonsense - DKIM, SPF and DMARC are about *domains* and not *partly 
> matches* of some special handeled large companies
> _
> 
>  Domain name:
>  googletechteam.co.uk
> 
>  Registrant:
>  Alexander Duffus
> 
>  Registrant type:
>  UK Individual
> 
>  Registrant's address:
>  Bury House
>  Royston
>  Hertfordshire
>  SG8 8QB
>  United Kingdom
> 

In my mailflow I believe it to be very unusual for a domain / sender to have 
Google in it and not orignate from Googles network.


The example I gave originated from 217.199.161.224 (ASN 20738 - Webfusion 
Internet Solutions) and had *google* in the domain, to me that's something I 
want to have visability of.

Overall, while i appericate your efforts and discussions about the validatility 
of my objectives, what I'm really after is how can I query the X-ASN header? 

If this turns out to be a waste of time I'll be the first to let you know. 

Many thanks 

Steve 

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)

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: Re-4: A rule to check X-ASN header

[Benny Pedersen]

steve skrev den 2015-11-23 15:43:


That was just one example I received. Yes, you can very well use
google.junc.en and no that doesn't mean Google spams me.

My eventual goal is to test for "Has google in the sender name OR
domain" and "is NOT from a ASN owned by Google".

https://www.ultratools.com/tools/asnInfoResult?domainName=Google

Am I'm not explaining myself correctly?


you assume that ALL ips in there asn is used for outbound emailing ?

https://dmarcian.com/spf-survey/gmail.com see the flatted ip ranges and 
compare it

Re-2: A rule to check X-ASN header

[steve]

> > Hi all,
> > 
> > I'm trying to create a rule which will check the results of the ASN
> > plugin. 
> ...
> > As a test I have the following...
> > 
> > ifplugin Mail::SpamAssassin::Plugin::ASN
> >header  T_SCS_ASN_EXISTS  exists:X-ASN
> >header  T_SCS_ASN_ANYTHINGX-ASN =~ /.*/i
> >header  T_SCS_ASN_ANY_AS  X-ASN =~ /AS[0-9]*/i
> >header  T_SCS_ASN_AS15169 X-ASN =~ /AS15169/
> >header  T_SCS_ASN_AS15169BX-ASN =~ /^AS15169 /
> > endif
> > 
> > On a test message which I sent myself on Friday from my google
> > account and which I am now currently pipping into SpamAssassin at the
> > command line the rules T_SCS_ASN_EXISTS and T_SCS_ASN_ANYTHING
> > trigger but T_SCS_ASN_ANY_AS, T_SCS_ASN_AS15169 and
> > T_SCS_ASN_AS15169B.
> ...
> > rules: ran header rule T_SCS_ASN_ANYTHING ==> got hit: "15169"
> 
> This is why the other tests fail, there's no "AS" before the number.
> 

RW,

Thank you! With that in mind I've made the following adjustment and the rule is 
now being triggered.

header  T_SCS_ASN_AS15169CX-ASN =~ /^15169$/

As to whether this will be helpful in detecting spam I'll let you know.

Kind regards

Steve

Re: A rule to check X-ASN header

[RW]

On Mon, 23 Nov 2015 12:05:59 +
steve wrote:

> Hi all,
> 
> I'm trying to create a rule which will check the results of the ASN
> plugin. 
...
> As a test I have the following...
> 
> ifplugin Mail::SpamAssassin::Plugin::ASN
>header  T_SCS_ASN_EXISTS  exists:X-ASN
>header  T_SCS_ASN_ANYTHINGX-ASN =~ /.*/i
>header  T_SCS_ASN_ANY_AS  X-ASN =~ /AS[0-9]*/i
>header  T_SCS_ASN_AS15169 X-ASN =~ /AS15169/
>header  T_SCS_ASN_AS15169BX-ASN =~ /^AS15169 /
> endif
> 
> On a test message which I sent myself on Friday from my google
> account and which I am now currently pipping into SpamAssassin at the
> command line the rules T_SCS_ASN_EXISTS and T_SCS_ASN_ANYTHING
> trigger but T_SCS_ASN_ANY_AS, T_SCS_ASN_AS15169 and
> T_SCS_ASN_AS15169B.
...
> rules: ran header rule T_SCS_ASN_ANYTHING ==> got hit: "15169"

This is why the other tests fail, there's no "AS" before the number.

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: A rule to check X-ASN header

[RW]

On Mon, 23 Nov 2015 16:07:38 +
RW wrote:

> On Mon, 23 Nov 2015 12:05:59 +
> steve wrote:
> 
> > Hi all,
> > 
> > I'm trying to create a rule which will check the results of the ASN
> > plugin.   
> ...
> > As a test I have the following...
> > 
> > ifplugin Mail::SpamAssassin::Plugin::ASN
> >header  T_SCS_ASN_EXISTS  exists:X-ASN
> >header  T_SCS_ASN_ANYTHINGX-ASN =~ /.*/i
> >header  T_SCS_ASN_ANY_AS  X-ASN =~ /AS[0-9]*/i
> >header  T_SCS_ASN_AS15169 X-ASN =~ /AS15169/
> >header  T_SCS_ASN_AS15169BX-ASN =~ /^AS15169 /
> > endif
> > 
> > On a test message which I sent myself on Friday from my google
> > account and which I am now currently pipping into SpamAssassin at
> > the command line the rules T_SCS_ASN_EXISTS and T_SCS_ASN_ANYTHING
> > trigger but T_SCS_ASN_ANY_AS, T_SCS_ASN_AS15169 and
> > T_SCS_ASN_AS15169B.  
> ...
> > rules: ran header rule T_SCS_ASN_ANYTHING ==> got hit: "15169"  
> 
> This is why the other tests fail, there's no "AS" before the number.

Ahd here's why:

asn_prefix 'prefix_string' (default: 'AS')
   The string specified in the argument is prepended to each ASN
   when storing it as a tag. This prefix is rather redundant, but
   its default value 'AS' is kept for backward compatibility with
   versions of SpamAssassin earlier than 3.4.0. A sensible setting
   is an empty string. The argument may be (but need not be)
   enclosed in single or double quotes for clarity.

Re-6: A rule to check X-ASN header

[steve]

> steve skrev den 2015-11-23 15:43:
> 
> > That was just one example I received. Yes, you can very well use
> > google.junc.en and no that doesn't mean Google spams me.
> > 
> > My eventual goal is to test for "Has google in the sender name OR
> > domain" and "is NOT from a ASN owned by Google".
> > 
> > https://www.ultratools.com/tools/asnInfoResult?domainName=Google
> > 
> > Am I'm not explaining myself correctly?
> 
> you assume that ALL ips in there asn is used for outbound emailing ?

At the moment I do not know so I'd like my rule to rule to run for a bit so I 
can get a clear picture of what is going on.
 
> https://dmarcian.com/spf-survey/gmail.com see the flatted ip ranges and 
> compare it

This is useful information. I'll look into this as well as pursuing my ASN 
angle.

While i appericate your efforts and discussions about the validatility of my 
objectives, and at the risk of repeating myself what I'm really after is how 
can I query the X-ASN header? 

If this turns out to be a waste of time I'll be the first to let you know. 

Regards

Steve