On Fri, 7 Sep 2018, Matus UHLAR - fantomas wrote:
For now, I believe that using (ALL_TRUSTED && __DOS_SINGLE_EXT_RELAY)
is just what I need to prevent all rules from firing:
I think you mean !ALL_TRUSTED, right?
Will digest and comment on the rest in a bit.
--
John Hardin KA7OHZ
On Fri, 31 Aug 2018, John Hardin wrote:
None of the masscheck corpora that hit __HDR_ORDER_FTSDMC also
hit ALL_TRUSTED (or at least the portion is so small it falls off
the bottom of the report) so I don't feel too worried about adding
either !ALL_TRUSTED or __ANY_EXTERNAL (or potentially bot
On Sat, 1 Sep 2018, RW wrote:
On Fri, 31 Aug 2018 16:16:43 -0700 (PDT)
John Hardin wrote:
On Fri, 31 Aug 2018, John Hardin wrote:
None of the masscheck corpora that hit __HDR_ORDER_FTSDMC also
hit ALL_TRUSTED (or at least the portion is so small it falls off
the bottom of the report) so
On Fri, 31 Aug 2018 16:16:43 -0700 (PDT)
John Hardin wrote:
> On Fri, 31 Aug 2018, John Hardin wrote:
>
> > None of the masscheck corpora that hit __HDR_ORDER_FTSDMC also
> > hit ALL_TRUSTED (or at least the portion is so small it falls off
> > the bottom of the report) so I don't feel too wo
On Fri, 31 Aug 2018, Matus UHLAR - fantomas wrote:
Note that I list internal clients as trusted, not as internal.
Maybe this is the problem. Long time ago I learned to configure
dynamic IP addresses (dialups) as trusted, but not as internal.
On 31.08.18 12:07, John Hardin wrote:
Hrm. Not sure
On Fri, 31 Aug 2018, John Hardin wrote:
None of the masscheck corpora that hit __HDR_ORDER_FTSDMC also
hit ALL_TRUSTED (or at least the portion is so small it falls off
the bottom of the report) so I don't feel too worried about adding
either !ALL_TRUSTED or __ANY_EXTERNAL (or potentially b
On Fri, 31 Aug 2018, John Hardin wrote:
None of the masscheck corpora that hit __HDR_ORDER_FTSDMC also hit
ALL_TRUSTED (or at least the portion is so small it falls off the bottom of
the report) so I don't feel too worried about adding either !ALL_TRUSTED or
__ANY_EXTERNAL (or potentially
On Fri, 31 Aug 2018, John Hardin wrote:
On Fri, 31 Aug 2018, Matus UHLAR - fantomas wrote:
On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote:
That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and
HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on
local network, withou
On Fri, 31 Aug 2018, Matus UHLAR - fantomas wrote:
On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote:
That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and
HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on
local network, without SMTP authentication, and without DNS (wh
On 31 Aug 2018, at 4:53, Matus UHLAR - fantomas wrote:
Long time ago I learned to configure dynamic IP addresses (dialups) as
trusted, but not as internal.
On 31.08.18 09:37, Bill Cole wrote:
They probably should be neither.
In this case, clients are internal, not dialup, but I still think
On 31 Aug 2018, at 4:05, Matus UHLAR - fantomas wrote:
On 08/30/2018 10:16 AM, Bill Cole wrote:
It's hard to understand this circumstance based on the generic
description.
It appears that you have a configuration where a relay is in
trusted_networks (i.e. you believe what it asserts in Recei
On 31 Aug 2018, at 4:53, Matus UHLAR - fantomas wrote:
Note that I list internal clients as trusted, not as internal.
Maybe this is the problem.
Yes, maybe...
Long time ago I learned to configure dynamic IP addresses (dialups) as
trusted, but not as internal.
They probably should be neith
I have not checked whether SA orders the Received headers in correct date/time
sequence but if not, remember that many Microsoft products change whimsically
the order of Receiveds headers (Kevin sharks are starving)...
PedroD
On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote:
That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and
HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on
local network, without SMTP authentication, and without DNS (which may be
quite common in some organizations).
On
On Thu, 30 Aug 2018 12:16:33 -0400
Bill Cole wrote:
I think the fix for all is for everyone to get their
internal_networks and trusted_networks configurations correct.
On 30.08.18 20:35, RW wrote:
Whatever is happening in this particular case (whatever that is), any
rule that works on last-ext
On 08/30/2018 10:16 AM, Bill Cole wrote:
It's hard to understand this circumstance based on the generic description.
It appears that you have a configuration where a relay is in
trusted_networks (i.e. you believe what it asserts in Received headers)
but it is NOT in internal_networks so it is i
On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote:
That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and
HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on
local network, without SMTP authentication, and without DNS (which may be
quite common in some organizations).
Ar
On 30 Aug 2018, at 18:02, Grant Taylor wrote:
> On 08/30/2018 03:50 PM, Bill Cole wrote:
>> That will depend on how that particular MTA constructs its Received headers
>> in relation to the parsing in
>> Mail::SpamAssassin::Message::Metadata::Received, which is non-trivial to
>> describe in hum
On 08/30/2018 03:50 PM, Bill Cole wrote:
That will depend on how that particular MTA constructs
its Received headers in relation to the parsing in
Mail::SpamAssassin::Message::Metadata::Received, which is non-trivial
to describe in human language.
Fair enough.
Would it be possible for this s
On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote:
Is it really a problem to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT
and HDR_ORDER_FTSDMCXX_NORDNS ?
As I said on the bug: I'll review masscheck and add that if it appears
reasonable to do so.
(maybe even HDR_ORDER_FTSDMCXX_001C and
On 30 Aug 2018, at 15:56, Grant Taylor wrote:
> On 08/30/2018 01:08 PM, Bill Cole wrote:
>> If that MSA is requiring authentication (as it should) and recording that in
>> the Received header (as it should) then as I understand it, the handoff of
>> the message will not be considered for __RDNS_
On 08/30/2018 01:08 PM, Bill Cole wrote:
If that MSA is requiring authentication (as it should) and recording
that in the Received header (as it should) then as I understand it,
the handoff of the message will not be considered for __RDNS_NONE.
Okay.
What happens if the MSA isn't using authen
On Thu, 30 Aug 2018 12:16:33 -0400
Bill Cole wrote:
> I think the fix for all is for everyone to get their
> internal_networks and trusted_networks configurations correct.
Whatever is happening in this particular case (whatever that is), any
rule that works on last-external should distinguish
On 30 Aug 2018, at 12:40, Grant Taylor wrote:
> On 08/30/2018 10:16 AM, Bill Cole wrote:
>> It's hard to understand this circumstance based on the generic description.
>>
>> It appears that you have a configuration where a relay is in
>> trusted_networks (i.e. you believe what it asserts in Recei
On 08/30/2018 10:16 AM, Bill Cole wrote:
It's hard to understand this circumstance based on the generic description.
It appears that you have a configuration where a relay is in
trusted_networks (i.e. you believe what it asserts in Received headers)
but it is NOT in internal_networks so it is
On 30 Aug 2018, at 10:01, Matus UHLAR - fantomas wrote:
On 30.08.18 09:49, Kevin A. McGrail wrote:
I feel that you are fighting a bigger battle than one rule in SA.
two rules actually ;-) (with two more possible).
Without RDNS, you are running afoul of the postmaster rules of
virtually
ever
On 30.08.18 09:49, Kevin A. McGrail wrote:
I feel that you are fighting a bigger battle than one rule in SA.
two rules actually ;-) (with two more possible).
Without RDNS, you are running afoul of the postmaster rules of virtually
every major email player. You will have massive deliverabilit
Matus,
I feel that you are fighting a bigger battle than one rule in SA.
Without RDNS, you are running afoul of the postmaster rules of virtually
every major email player. You will have massive deliverability issues..
You are asking for a bandaid when you've just lost a leg to shark biite and
m
On 30.08.18 09:24, Kevin A. McGrail wrote:
Thanks Matus. This is a good place to debate, thank you.
Here is my response on the ticket:
Outlook express ended production in June 2006. I'm not sure how much
weight we can give to an email sent with it.
note that the issue is exactly the same wi
Thanks Matus. This is a good place to debate, thank you.
Here is my response on the ticket:
Outlook express ended production in June 2006. I'm not sure how much
weight we can give to an email sent with it.
The issue is at HDR_ORDER_FTSDMCXX_NORDNS with __RDNS_NONE.
RDNS is an expected technol
Hello,
the __HDR_ORDER_FTSDMC rule catches mail sent from windows live mail
(and outlook express, which, while obsolete, seems to be still used often)
That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and
HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on
local netwo
31 matches
Mail list logo
