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.
