ion 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 appea
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
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 Spam
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
>>> receive
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&id=24
Thanks Kevin, I'd taken a look at this already but I'd misunderstood
the original reply, I thought I was looking for som
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
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
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
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
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 look
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 H
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 pro
appens) - 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
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
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
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
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
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
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
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.
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/DNSEv
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
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::SpamAs
On November 25, 2015 12:15:45 AM John Hardin 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 possib
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
>
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 mai
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-re
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 he
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
>From: Bill Cole
>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
>>> Sent: Tuesday, November 24, 2015 1:41 PM
>>> To:
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
On 24 Nov 2015, at 14:54, David Jones wrote:
From: Bill Cole
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
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
>From: Bill Cole
>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
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
Am 24.11.2015 um 20:36 schrieb David Jones:
From: Reindl Harald
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
and that is why i call it harmful to completly
om 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 b
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 *sho
. 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
>From: Reindl Harald
>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
>>> and that is why i call it harmful to completly rely o
e 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&#x
x27;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 ca
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 t
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 th
>From: Reindl Harald
>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
om 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.
May
>From: RW
>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
amassassin 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
fi
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 wh
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 wit
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
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 dn
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
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
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:
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
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, ...
ion 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?
>>>
>&
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 dis
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 spamassa
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
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
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 spamassas
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
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
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 R
003WU-3m
> forg...@unixarea.de; Sun, 22 Nov 2015 22:24:11 +0100
>
> RDNS_NONE shouldn't fire on that. Edda
Edda, thanks! I did this change (i.e. inserted 'hermes.apache.org' in
the Received: line) and run the mail again through spamassassin -D ...
it passed fin
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 o
y
> ms-10.1blu.de with smtp (Exim 4.76) (envelope-from
> )
>
> id 1a0rRx-0006CK-Gq
> for g...@unixarea.de; Mon, 23 Nov 2015
> 14:46:33 +0100
>
> has something todo with my local configuration?
I don't. I didn't see that header. The original set of
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
)
id 1a0rRx-000
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
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
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
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
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 i
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
Reindl Harald skrev den 2015-11-23 13:38:
score RDNS_NONE 0
why using spamassassin anyway ?
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
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:
$ spa
u 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
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
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
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
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
matc
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 && !(__
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 b
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
matc
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 ru
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
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
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, mi
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, mi
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
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
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
; 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
agai
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
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
> >>
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
> 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 (re
1 - 100 of 168 matches
Mail list logo
