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
15 matches
Mail list logo
