Mailing List Archive

Fake EHLO triggering ALL_TRUSTED
Just had a compromised account on one of my customer's mail servers
(96.4.156.21) try to blast out phishing email. This 96.4 IP is our
customer space so it's in my trusted_networks since it will not forge
the Received header.

The 88.233 IP is from Turkey (88.233.47.16.dynamic.ttnet.com.tr) and
should have triggered a number of rules based on the RelayCountry plugin.

This email should not have hit ALL_TRUSTED and should have done
RelayCountry and ASN lookups on 88.233.47.16.


Received: from mail.lced.net (mail.lced.net [96.4.156.2])
by smtp5i.ena.net (Postfix) with ESMTP id DF9421480F90
for <brookeandjeff@eastlink.ca>; Thu, 4 Jul 2019 12:56:42 -0500 (CDT)
Received: from 192.168.1.2 (unknown [88.233.47.16])
by mail.lced.net (Postfix) with ESMTPA id 8F22630961D6D
for <brookeandjeff@eastlink.ca>; Thu, 4 Jul 2019 12:56:40 -0500 (CDT)


--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Thu, 4 Jul 2019 19:11:43 +0000
David Jones wrote:

> Just had a compromised account on one of my customer's mail servers
> (96.4.156.21) try to blast out phishing email. This 96.4 IP is our
> customer space so it's in my trusted_networks since it will not forge
> the Received header.

This is nothing to do with ehlo, it hit ALL_TRUSTED because it's
authenticated mail submission into the trusted network.


> The 88.233 IP is from Turkey (88.233.47.16.dynamic.ttnet.com.tr) and
> should have triggered a number of rules based on the RelayCountry
> plugin.
>
> This email should not have hit ALL_TRUSTED and should have done
> RelayCountry and ASN lookups on 88.233.47.16.
>
>
> Received: from mail.lced.net (mail.lced.net [96.4.156.2])
> by smtp5i.ena.net (Postfix) with ESMTP id DF9421480F90
> for <brookeandjeff@eastlink.ca>; Thu, 4 Jul 2019 12:56:42 -0500
> (CDT) Received: from 192.168.1.2 (unknown [88.233.47.16])
> by mail.lced.net (Postfix) with ESMTPA id 8F22630961D6D
> for <brookeandjeff@eastlink.ca>; Thu, 4 Jul 2019 12:56:40 -0500
> (CDT)
>
>
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/4/19 2:28 PM, RW wrote:
> On Thu, 4 Jul 2019 19:11:43 +0000
> David Jones wrote:
>
>> Just had a compromised account on one of my customer's mail servers
>> (96.4.156.21) try to blast out phishing email. This 96.4 IP is our
>> customer space so it's in my trusted_networks since it will not forge
>> the Received header.
>
> This is nothing to do with ehlo, it hit ALL_TRUSTED because it's
> authenticated mail submission into the trusted network.
>

Thank you for this information.

It seems like authenticated mail submission should only apply to
internal_networks and not extend out to the trusted_networks.

I trust the 96.4.165.21 mail server to not forge the Received headers
but compromised accounts happen.

Is there another way to accomplish checking the that 88.233 IP as the
last-external without stripping off the "A" in ESMTPA at the MTA before
SA sees it?

>> The 88.233 IP is from Turkey (88.233.47.16.dynamic.ttnet.com.tr) and
>> should have triggered a number of rules based on the RelayCountry
>> plugin.
>>
>> This email should not have hit ALL_TRUSTED and should have done
>> RelayCountry and ASN lookups on 88.233.47.16.
>>
>>
>> Received: from mail.lced.net (mail.lced.net [96.4.156.2])
>> by smtp5i.ena.net (Postfix) with ESMTP id DF9421480F90
>> for <brookeandjeff@eastlink.ca>; Thu, 4 Jul 2019 12:56:42 -0500
>> (CDT) Received: from 192.168.1.2 (unknown [88.233.47.16])
>> by mail.lced.net (Postfix) with ESMTPA id 8F22630961D6D
>> for <brookeandjeff@eastlink.ca>; Thu, 4 Jul 2019 12:56:40 -0500
>> (CDT)
>>
>>

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 4 Jul 2019, at 16:59, David Jones wrote:

> It seems like authenticated mail submission should only apply to
> internal_networks and not extend out to the trusted_networks.

No. See https://wiki.apache.org/spamassassin/DynablockIssues.

In short: if you don't trust the authentication of your
trusted_networks, you will end up rejecting their legitimately
authenticated users for being on PBL-like DNSBLs.

Arguably the trusted/internal/msa network model could use a rethink
since today we see so many cracked accounts. If you have specific ideas
other than redefining an existing client class back to a broken former
handling, I'd be interested in that discussion.

> I trust the 96.4.165.21 mail server to not forge the Received headers
> but compromised accounts happen.
>
> Is there another way to accomplish checking the that 88.233 IP as the
> last-external without stripping off the "A" in ESMTPA at the MTA
> before
> SA sees it?

Not without checking the IP of every authenticated client of
trusted_networks. I think you can do it with the '-firsttrusted' suffix
for DNSBL rules so that you could define a rule that looks for SBL & XBL
hits but not PBL hits in Zen.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/4/19 6:35 PM, Bill Cole wrote:
> On 4 Jul 2019, at 16:59, David Jones wrote:
>
>> It seems like authenticated mail submission should only apply to
>> internal_networks and not extend out to the trusted_networks.
>
> No. See https://wiki.apache.org/spamassassin/DynablockIssues.
>
> In short: if you don't trust the authentication of your
> trusted_networks, you will end up rejecting their legitimately
> authenticated users for being on PBL-like DNSBLs.
>
> Arguably the trusted/internal/msa network model could use a rethink
> since today we see so many cracked accounts. If you have specific
> ideas other than redefining an existing client class back to a broken
> former handling, I'd be interested in that discussion.
>
Maybe allow the RelayCountry check to happen on the msa network or the
first relay?

Or something like trusted_countries that could provide a limit/boundary
to the trust of trusted_networks?

Compromised accounts often get abused from foreign/unusual countries.  I
have meta rules and DWL/DBL for emails combined with RelayCountry but
these are useless in this situation.

>> I trust the 96.4.165.21 mail server to not forge the Received headers
>> but compromised accounts happen.
>>
>> Is there another way to accomplish checking the that 88.233 IP as the
>> last-external without stripping off the "A" in ESMTPA at the MTA before
>> SA sees it?
>
> Not without checking the IP of every authenticated client of
> trusted_networks. I think you can do it with the '-firsttrusted'
> suffix for DNSBL rules so that you could define a rule that looks for
> SBL & XBL hits but not PBL hits in Zen.
>
I was thinking about stripping the "A" off othe ESMTPA just for this
email server since I know that customer's mail flow should never have
email originate from Turkey and most other countries outside of the US. 
I don't care so much about RBLs but the country is a big indicator of a
compromised account.
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 02:42:28AM +0000, David Jones wrote:
> Maybe allow the RelayCountry check to happen on the msa network or the
> first relay?
>
> Or something like trusted_countries that could provide a limit/boundary
> to the trust of trusted_networks?
>
> Compromised accounts often get abused from foreign/unusual countries.? I
> have meta rules and DWL/DBL for emails combined with RelayCountry but
> these are useless in this situation.

Perhaps adding new datadata X-Relay-Countries-External would be enough, it
would check all external IPs (vs untrusted for the default
X-Relay-Countries). I think it could use useful in this and other
situations when there are lots of additional trusted networks.

Maybe also the X-Relay-Countries-MSA to check client IPs from msa_networks.

Might even make it to 3.4.3 if KAM wants to delay rc4 just a little bit more.
:-D
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 09:50:35AM +0300, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:42:28AM +0000, David Jones wrote:
> > Maybe allow the RelayCountry check to happen on the msa network or the
> > first relay?
> >
> > Or something like trusted_countries that could provide a limit/boundary
> > to the trust of trusted_networks?
> >
> > Compromised accounts often get abused from foreign/unusual countries.? I
> > have meta rules and DWL/DBL for emails combined with RelayCountry but
> > these are useless in this situation.
>
> Perhaps adding new datadata X-Relay-Countries-External would be enough, it
> would check all external IPs (vs untrusted for the default
> X-Relay-Countries). I think it could use useful in this and other
> situations when there are lots of additional trusted networks.
>
> Maybe also the X-Relay-Countries-MSA to check client IPs from msa_networks.
>
> Might even make it to 3.4.3 if KAM wants to delay rc4 just a little bit more.
> :-D

See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7731
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/5/19 1:54 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 09:50:35AM +0300, Henrik K wrote:
>> On Fri, Jul 05, 2019 at 02:42:28AM +0000, David Jones wrote:
>>> Maybe allow the RelayCountry check to happen on the msa network or the
>>> first relay?
>>>
>>> Or something like trusted_countries that could provide a limit/boundary
>>> to the trust of trusted_networks?
>>>
>>> Compromised accounts often get abused from foreign/unusual countries.  I
>>> have meta rules and DWL/DBL for emails combined with RelayCountry but
>>> these are useless in this situation.
>>
>> Perhaps adding new datadata X-Relay-Countries-External would be enough, it
>> would check all external IPs (vs untrusted for the default
>> X-Relay-Countries). I think it could use useful in this and other
>> situations when there are lots of additional trusted networks.
>>
>> Maybe also the X-Relay-Countries-MSA to check client IPs from msa_networks.
>>
>> Might even make it to 3.4.3 if KAM wants to delay rc4 just a little bit more.
>> :-D
>
> See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7731
>

Thank you Henrik! Very nice and quick work.

Depending on how this sorts out, I may have to duplicate all of my
existing X-Relay-Countries rules and add these to other meta rules with
an "or" but that would be fine.

For the sake of others, it would be beneficial if the default behavior
of X-Relay-Countries changed to the X-Relay-Countries-MSA. That
shouldn't be too much of a change to cause adverse effects since it
would still be hitting ALL_TRUSTED and no RBL checks happen. If the
RelayCountry.pm plugin was not enabled (default?) then this would result
in no change for the majority of SA instances and only enhance those
that have enabled it.

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 01:37:50PM +0000, David Jones wrote:
>
> For the sake of others, it would be beneficial if the default behavior
> of X-Relay-Countries changed to the X-Relay-Countries-MSA.

I renamed it X-Relay-Countries-MUA since it's more describing. It lists all
after the MSA itself.

What you suggest is not possible, since -MUA will be empty if there isn't
any MSA (and MUA after that) in the received chain. If this is unclear,
please let me know how to document it better. :-)
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 5 Jul 2019, at 9:37, David Jones wrote:

> For the sake of others, it would be beneficial if the default behavior
> of X-Relay-Countries changed to the X-Relay-Countries-MSA.

Definitely not for 3.4.3. Preferably not at all. While I agree in
principle with having some way to trust machines as honest without
trusting their authentication systems to be bulletproof, that shouldn't
involve changing a useful stable feature in a way that will break
reasonable configurations. That change would cause substantial false
positives at some sites if deployed without carefully considered
preparation. It would be a poison pill for packagers who value
stability.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/5/19 9:09 AM, Bill Cole wrote:
> On 5 Jul 2019, at 9:37, David Jones wrote:
>
>> For the sake of others, it would be beneficial if the default behavior
>> of X-Relay-Countries changed to the X-Relay-Countries-MSA.
>
> Definitely not for 3.4.3. Preferably not at all. While I agree in
> principle with having some way to trust machines as honest without
> trusting their authentication systems to be bulletproof, that shouldn't
> involve changing a useful stable feature in a way that will break
> reasonable configurations. That change would cause substantial false
> positives at some sites if deployed without carefully considered
> preparation. It would be a poison pill for packagers who value stability.
>
>

I believe the only change would be the Relay-Countries value would have
country codes in it. We aren't suggesting changing any other logic so
the ALL_TRUSTED would still hit and RBLs would not be check on
authenticated IPs.

Is your concern the RBL checks on those authenticated IPs?

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/5/19 9:03 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 01:37:50PM +0000, David Jones wrote:
>>
>> For the sake of others, it would be beneficial if the default behavior
>> of X-Relay-Countries changed to the X-Relay-Countries-MSA.
>
> I renamed it X-Relay-Countries-MUA since it's more describing. It lists all
> after the MSA itself.
>
> What you suggest is not possible, since -MUA will be empty if there isn't
> any MSA (and MUA after that) in the received chain. If this is unclear,
> please let me know how to document it better. :-)
>

If the -MUA is empty, wouldn't it simply work like it does today and
RelayCountry would skip all trusted relays? In this example it would
not fire at all just like it already did.

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 02:32:42PM +0000, David Jones wrote:
> On 7/5/19 9:03 AM, Henrik K wrote:
> > On Fri, Jul 05, 2019 at 01:37:50PM +0000, David Jones wrote:
> >>
> >> For the sake of others, it would be beneficial if the default behavior
> >> of X-Relay-Countries changed to the X-Relay-Countries-MSA.
> >
> > I renamed it X-Relay-Countries-MUA since it's more describing. It lists all
> > after the MSA itself.
> >
> > What you suggest is not possible, since -MUA will be empty if there isn't
> > any MSA (and MUA after that) in the received chain. If this is unclear,
> > please let me know how to document it better. :-)
> >
>
> If the -MUA is empty, wouldn't it simply work like it does today and
> RelayCountry would skip all trusted relays? In this example it would
> not fire at all just like it already did.

That's still breaking backwards compatibility. People should expect
X-Relay-Countries to be empty, even when there is MSA used.

It doesn't really cost anything to create a new header for this. Those who
want to use it for MSA/MUA identification, can do so with the new header.

PS. Check out the bug, I'm still contemplating a few things...
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/5/19 9:36 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:32:42PM +0000, David Jones wrote:
>> On 7/5/19 9:03 AM, Henrik K wrote:
>>> On Fri, Jul 05, 2019 at 01:37:50PM +0000, David Jones wrote:
>>>>
>>>> For the sake of others, it would be beneficial if the default behavior
>>>> of X-Relay-Countries changed to the X-Relay-Countries-MSA.
>>>
>>> I renamed it X-Relay-Countries-MUA since it's more describing. It lists all
>>> after the MSA itself.
>>>
>>> What you suggest is not possible, since -MUA will be empty if there isn't
>>> any MSA (and MUA after that) in the received chain. If this is unclear,
>>> please let me know how to document it better. :-)
>>>
>>
>> If the -MUA is empty, wouldn't it simply work like it does today and
>> RelayCountry would skip all trusted relays? In this example it would
>> not fire at all just like it already did.
>
> That's still breaking backwards compatibility. People should expect
> X-Relay-Countries to be empty, even when there is MSA used.
>
> It doesn't really cost anything to create a new header for this. Those who
> want to use it for MSA/MUA identification, can do so with the new header.
>
> PS. Check out the bug, I'm still contemplating a few things...
>

I am completely OK with switching to a new X-Relay-Countries-MUA header
as long as it works just like the current X-Relay-Countries when there
is no MUA. If it's differnt logic or an extra header to check, then
that would mean duplicating and managing another set of rules and scores
for dozens/hundreds of country codes.

In other words, could the new X-Relay-Countries rules be ordered so the
each one also includes the lower ones like syslog works?

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 02:46:16PM +0000, David Jones wrote:
>
> I am completely OK with switching to a new X-Relay-Countries-MUA header
> as long as it works just like the current X-Relay-Countries when there
> is no MUA. If it's differnt logic or an extra header to check, then
> that would mean duplicating and managing another set of rules and scores
> for dozens/hundreds of country codes.
>
> In other words, could the new X-Relay-Countries rules be ordered so the
> each one also includes the lower ones like syslog works?

I don't like it. There's specific function for the headers. Someone might
want to check specific countries for authenticated users, which might not be
the same countries than for generic relay checks.
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 5 Jul 2019, at 10:30, David Jones wrote:

> On 7/5/19 9:09 AM, Bill Cole wrote:
>> On 5 Jul 2019, at 9:37, David Jones wrote:
>>
>>> For the sake of others, it would be beneficial if the default
>>> behavior
>>> of X-Relay-Countries changed to the X-Relay-Countries-MSA.
>>
>> Definitely not for 3.4.3. Preferably not at all. While I agree in
>> principle with having some way to trust machines as honest without
>> trusting their authentication systems to be bulletproof, that
>> shouldn't
>> involve changing a useful stable feature in a way that will break
>> reasonable configurations. That change would cause substantial false
>> positives at some sites if deployed without carefully considered
>> preparation. It would be a poison pill for packagers who value
>> stability.
>>
>>
>
> I believe the only change would be the Relay-Countries value would
> have
> country codes in it.

Yes, which it shouldn't.

It may sound weird, but it is true that I work with 2 mostly unrelated
mail systems where mail comes in via MSAs whose authentication is
trustworthy from end-users who live and/or travel in places that send
those systems very little legitimate mail via untrusted/unauthenticated
sources.

> We aren't suggesting changing any other logic so
> the ALL_TRUSTED would still hit and RBLs would not be check on
> authenticated IPs.
>
> Is your concern the RBL checks on those authenticated IPs?

No. My concern is about changing what is in Relay-Countries.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/5/19 9:51 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:46:16PM +0000, David Jones wrote:
>>
>> I am completely OK with switching to a new X-Relay-Countries-MUA header
>> as long as it works just like the current X-Relay-Countries when there
>> is no MUA. If it's differnt logic or an extra header to check, then
>> that would mean duplicating and managing another set of rules and scores
>> for dozens/hundreds of country codes.
>>
>> In other words, could the new X-Relay-Countries rules be ordered so the
>> each one also includes the lower ones like syslog works?
>
> I don't like it. There's specific function for the headers. Someone might
> want to check specific countries for authenticated users, which might not be
> the same countries than for generic relay checks.
>

If there truly are specific functions for each header with different
logic then I agree that they should be separate.

My understanding of the proposed X-Relay-Countries-MUA would be
identical to the current X-Relay-Countries except when there is an
authenticated MSA, then it would show the country code. If you have
written the code (I haven't looked yet) for X-Relay-Countries-MUA to be
blank when the MUA is blank then I agree with you and I will have to
manage multiple sets of the same rules/scores checking each header.

This logic could be designed to provide individual headers and other
headers for layers of boundaries. The layer approach could be very
useful for scoring differences using multipliers for higher, less
trusted sources.

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 03:59:41PM +0000, David Jones wrote:
> My understanding of the proposed X-Relay-Countries-MUA would be
> identical to the current X-Relay-Countries except when there is an
> authenticated MSA, then it would show the country code.

I've never even thought of this, since it doesn't make sense in my mind.
Either there's MUA (Auth) or there isn't.

> If you have
> written the code (I haven't looked yet) for X-Relay-Countries-MUA to be
> blank when the MUA is blank then I agree with you and I will have to
> manage multiple sets of the same rules/scores checking each header.

Such is life. There are many many more scenarios where one has to maintain
many rules and scores. Things can be automated, documented, copypasted,
etc. Normal stuff for operators. :-)

> This logic could be designed to provide individual headers and other
> headers for layers of boundaries. The layer approach could be very
> useful for scoring differences using multipliers for higher, less
> trusted sources.

This is the latest documentation. If anyone wants to chime in, there's
still little time, I don't want to debate after 3.4.3-rc4.

X-Relay-Countries _RELAYCOUNTRY_
All untrusted relays. Contains all relays starting from the
trusted_networks border. This method has been used by default since
early SA versions.

X-Relay-Countries-External _RELAYCOUNTRYEXT_
All external relays. Contains all relays starting from the
internal_networks border. Could be useful in some cases when
trusted/msa_networks extend beyond the internal border and those
need to be checked too.

X-Relay-Countries-All _RELAYCOUNTRYALL_
All possible relays (internal + external).

X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_
Auth will contain all relays starting from the first relay that used
authentication. For example, this could be used to check for hacked
local users coming in from unexpected countries.
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/5/19 9:55 AM, Bill Cole wrote:
> On 5 Jul 2019, at 10:30, David Jones wrote:
>
>> On 7/5/19 9:09 AM, Bill Cole wrote:
>>> On 5 Jul 2019, at 9:37, David Jones wrote:
>>>
>>
>> I believe the only change would be the Relay-Countries value would have
>> country codes in it.
>
> Yes, which it shouldn't.
>
> It may sound weird, but it is true that I work with 2 mostly unrelated
> mail systems where mail comes in via MSAs whose authentication is
> trustworthy from end-users who live and/or travel in places that send
> those systems very little legitimate mail via untrusted/unauthenticated
> sources.
>

This could be handled pretty easily with a local meta rule if one wanted
to subtract points for a subset of senders that also hit untrusted
country codes to offset the additional score from that country hit.

Those are mail servers that you actually manage so are they in the
internal_networks? This proposal is only intended to change the way
trusted_networks are handled.

It seems like the internal_networks and trusted_networks are being used
for two different purposes that don't completely overlap.

1. Trusted to not forge the Received or X-Originating-IP headers.
2. Both make up the ALL_TRUSTED rule hit and include the authenticated
ESMTPA which can include spam from a compromised account.

My servers are my problem to detect and handle compromised accounts. I
can control these with local SA rules because I have many options at my
disposal. For example, using swatch on my own logs to trigger country
code lookups to detect the same user logging in from two different
untrusted countries within X minutes which would be unlikely.

Perhaps we need something added like a 3rd option like boundary_networks?

internal_networks = in our admin control and won't forge headers
trusted_networks = trust to not forge headers (no change)
boundary_networks = works just like trusted_networks but
X-Relay-Countries will fire.

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 07:30:11PM +0300, Henrik K wrote:
> X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_
> Auth will contain all relays starting from the first relay that used
> authentication. For example, this could be used to check for hacked
> local users coming in from unexpected countries.

And just to be complete, I addded to end:

If there are no authenticated relays, this will be empty.
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 04:31:01PM +0000, David Jones wrote:
>
> Perhaps we need something added like a 3rd option like boundary_networks?
>
> internal_networks = in our admin control and won't forge headers
> trusted_networks = trust to not forge headers (no change)
> boundary_networks = works just like trusted_networks but
> X-Relay-Countries will fire.

Keep in mind that RelayCountry is practically an independent plugin. It has
nothing to do with internal *_networks settings per se, while it does use
them for it's purposes. There is no reason to add a new internal SA
boundary_networks setting, just because one plugin wants to do some specific
boundary checks. Which it can pretty much do anyway, thus the *-Auth
metadata can already be added. I don't even understand what would be the
main purpose for boundary_networks.
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 7/5/19 11:30 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 03:59:41PM +0000, David Jones wrote:
>> My understanding of the proposed X-Relay-Countries-MUA would be
>> identical to the current X-Relay-Countries except when there is an
>> authenticated MSA, then it would show the country code.
>
> I've never even thought of this, since it doesn't make sense in my mind.
> Either there's MUA (Auth) or there isn't.
>
>> If you have
>> written the code (I haven't looked yet) for X-Relay-Countries-MUA to be
>> blank when the MUA is blank then I agree with you and I will have to
>> manage multiple sets of the same rules/scores checking each header.
>
> Such is life. There are many many more scenarios where one has to maintain
> many rules and scores. Things can be automated, documented, copypasted,
> etc. Normal stuff for operators. :-)
>
>> This logic could be designed to provide individual headers and other
>> headers for layers of boundaries. The layer approach could be very
>> useful for scoring differences using multipliers for higher, less
>> trusted sources.
>
> This is the latest documentation. If anyone wants to chime in, there's
> still little time, I don't want to debate after 3.4.3-rc4.
>
> X-Relay-Countries _RELAYCOUNTRY_
> All untrusted relays. Contains all relays starting from the
> trusted_networks border. This method has been used by default since
> early SA versions.
>
> X-Relay-Countries-External _RELAYCOUNTRYEXT_
> All external relays. Contains all relays starting from the
> internal_networks border. Could be useful in some cases when
> trusted/msa_networks extend beyond the internal border and those
> need to be checked too.
>
> X-Relay-Countries-All _RELAYCOUNTRYALL_
> All possible relays (internal + external).
>

Not sure how this would be helpful since it mixes everything together.
I guess it could be used as a positive indicator when certain countries
are not in the list but we kinda have this already.

> X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_
> Auth will contain all relays starting from the first relay that used
> authentication. For example, this could be used to check for hacked
> local users coming in from unexpected countries.
>

Perhaps we need something added like a 3rd option like boundary_networks
as an authentication boundary beyond trusted_networks?

internal_networks = in our admin control and won't forge headers
trusted_networks = trust to not forge headers (no change)
boundary_networks = works like trusted_networks except:

1. X-Relay-Countries will be populated
2. ESMTPA IP not included in ALL_TRUSTED

Then we don't need to add new headers and no new rules to manage.

--
David Jones
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On Fri, Jul 05, 2019 at 04:42:54PM +0000, David Jones wrote:
> > X-Relay-Countries-All _RELAYCOUNTRYALL_
> > All possible relays (internal + external).
> >
>
> Not sure how this would be helpful since it mixes everything together.
> I guess it could be used as a positive indicator when certain countries
> are not in the list but we kinda have this already.

I was hastily thinking about some complex multi-country multi-mta setups.
So a certain continents mailflow could be checked for example.

It's just an extra header, there's no need to use it. :-)

> > X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_
> > Auth will contain all relays starting from the first relay that used
> > authentication. For example, this could be used to check for hacked
> > local users coming in from unexpected countries.
> >
>
> Perhaps we need something added like a 3rd option like boundary_networks
> as an authentication boundary beyond trusted_networks?
>
> internal_networks = in our admin control and won't forge headers
> trusted_networks = trust to not forge headers (no change)
> boundary_networks = works like trusted_networks except:
>
> 1. X-Relay-Countries will be populated
> 2. ESMTPA IP not included in ALL_TRUSTED
>
> Then we don't need to add new headers and no new rules to manage.

As I said in another post, it doesn't make sense to add such internal
feature for single plugins purposes, which many people might not even use.
If all it's purposes could be clearly conceived, something to look into
4.0.0. Perhaps with any other major logic changes if needed.
Re: Fake EHLO triggering ALL_TRUSTED [ In reply to ]
On 5 Jul 2019, at 12:31, David Jones wrote:

> On 7/5/19 9:55 AM, Bill Cole wrote:
>> On 5 Jul 2019, at 10:30, David Jones wrote:
>>
>>> On 7/5/19 9:09 AM, Bill Cole wrote:
>>>> On 5 Jul 2019, at 9:37, David Jones wrote:
>>>>
>>>
>>> I believe the only change would be the Relay-Countries value would
>>> have
>>> country codes in it.
>>
>> Yes, which it shouldn't.
>>
>> It may sound weird, but it is true that I work with 2 mostly
>> unrelated
>> mail systems where mail comes in via MSAs whose authentication is
>> trustworthy from end-users who live and/or travel in places that send
>> those systems very little legitimate mail via
>> untrusted/unauthenticated
>> sources.
>>
>
> This could be handled pretty easily with a local meta rule if one
> wanted
> to subtract points for a subset of senders that also hit untrusted
> country codes to offset the additional score from that country hit.

Sure, I could work around the change with new rules that would make
sense with the new behavior and probably not with the old. I'd rather
not have to do that. More importantly, I'd rather a terminal minor
release not have a surprise for others who unwittingly rely on current
behavior and don't read this list.

> Those are mail servers that you actually manage so are they in the
> internal_networks?

The MSAs are intentionally NOT in internal_networks or msa_networks.
Their management is complicated.

[...]
> Perhaps we need something added like a 3rd option like
> boundary_networks?
>
> internal_networks = in our admin control and won't forge headers
> trusted_networks = trust to not forge headers (no change)
> boundary_networks = works just like trusted_networks but
> X-Relay-Countries will fire.

I think Henrik's approach is adequate without adding a new network class
that will confuse users further about how the existing 3 work.