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

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

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

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_RCV

RDNS_NONE hit, but no RDNS queries actually done?

, 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

Re: RDNS_NONE always being triggered

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 doe

RDNS_NONE always being triggered

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

Re: RDNS_NONE always being triggered

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 be

Re: RDNS_NONE always being triggered

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

Re: RDNS_NONE always being triggered

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

Re: RDNS_NONE always being triggered

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

Re: RDNS_NONE always being triggered

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

ever* 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 betwe

Re: question re/ RDNS_NONE

t 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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

>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

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 dep

Re: question re/ RDNS_NONE

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...@thel

Re: question re/ RDNS_NONE

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*

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

, 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::Sp

Re: question re/ RDNS_NONE

, 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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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 t

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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,

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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,

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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 excep

Re: question re/ RDNS_NONE

f 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

Re: question re/ RDNS_NONE

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, :-(

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

; 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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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 && !(__

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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 sinc

Re: question re/ RDNS_NONE

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 no

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

Reindl Harald skrev den 2015-11-23 13:38: score RDNS_NONE 0 why using spamassassin anyway ?

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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 al

Re: question re/ RDNS_NONE

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: $ spamassa

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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 loc

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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

Re: question re/ RDNS_NONE

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 f

Re: question re/ RDNS_NONE

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

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

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

Re: question re/ RDNS_NONE

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 reco

  1   2   >