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
On Fri, Jul 05, 2019 at 04:42:54PM +, 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
On 7/5/19 11:30 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 03:59:41PM +, 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.
>
On Fri, Jul 05, 2019 at 04:31:01PM +, 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
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
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
On Fri, Jul 05, 2019 at 03:59:41PM +, 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
On 7/5/19 9:51 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:46:16PM +, 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
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
On Fri, Jul 05, 2019 at 02:46:16PM +, 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
On 7/5/19 9:36 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:32:42PM +, David Jones wrote:
>> On 7/5/19 9:03 AM, Henrik K wrote:
>>> On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote:
For the sake of others, it would be beneficial if the default behavior
of
On Fri, Jul 05, 2019 at 02:32:42PM +, David Jones wrote:
> On 7/5/19 9:03 AM, Henrik K wrote:
> > On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote:
> >>
> >> For the sake of others, it would be beneficial if the default behavior
> >> of X-Relay-Countries changed to the
On 7/5/19 9:03 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 01:37:50PM +, 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
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
>
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
On Fri, Jul 05, 2019 at 01:37:50PM +, 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.
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 +, David Jones wrote:
>>> Maybe allow the RelayCountry check to happen on the msa network or the
>>> first relay?
>>>
>>> Or something like trusted_countries
On Fri, Jul 05, 2019 at 09:50:35AM +0300, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:42:28AM +, 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
>
On Fri, Jul 05, 2019 at 02:42:28AM +, 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
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:
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
On 7/4/19 2:28 PM, RW wrote:
> On Thu, 4 Jul 2019 19:11:43 +
> 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
On Thu, 4 Jul 2019 19:11:43 +
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
23 matches
Mail list logo