On Sun, Aug 7, 2022 at 4:07 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Evaluators need to use much more sophistication, when applying DMARC, than
> simply applying the formula and doing whatever the policy suggests.
>
I think that's common practice. The people on this
On Sun, Aug 7, 2022 at 6:41 PM John R Levine wrote:
> Moving this back to the main list:
>
> I said:
> Even if I agreed that it would be a good idea for every mailing list in the
> world to rewrite From lines so it's harder to tell who the messages are
> from and
> you can't reply reliably,
Yes.
Evaluators need to use much more sophistication, when applying DMARC, than
simply applying the formula and doing whatever the policy suggests.
Developers need to provide exception mechanisms which permit that
complexity to be implemented as local policy. This means we need language
to
Moving this back to the main list:
I said:
Even if I agreed that it would be a good idea for every mailing list in the
world to rewrite From lines so it's harder to tell who the messages are from and
you can't reply reliably, there's no way that would survive last call.
Remember that a few large
On Sunday, August 7, 2022 2:55:48 PM EDT John Levine wrote:
> It appears that Scott Kitterman said:
> >On August 6, 2022 11:10:28 AM UTC, Alessandro Vesely
wrote:
> >>On Fri 05/Aug/2022 17:58:48 +0200 Scott Kitterman wrote:
> >>> I don't think it changes anything technically, but I think it
The most obvious shortcuts are that names must match on the right-most two
labels before the org domain is found, and must match on the entire org
domain once it is known.
A high percentage of tree walks can be eliminated with these two tests.
On Sun, Aug 7, 2022, 2:56 PM John Levine wrote:
>
It appears that Scott Kitterman said:
>
>
>On August 6, 2022 11:10:28 AM UTC, Alessandro Vesely wrote:
>>On Fri 05/Aug/2022 17:58:48 +0200 Scott Kitterman wrote:
>>> I don't think it changes anything technically, but I think it goes
>>> some way to address Ale's concerns about clarity.
>>
>>
By remembering failure reports issued in the past, new failures having
already reported characteristics (e.g. same forwarder) can be silently
ignored. That would greatly reduce noise.
This is a horrible idea. It presupposes that failures from the same origin
(e.g. same forwarder) at different
On August 6, 2022 11:10:28 AM UTC, Alessandro Vesely wrote:
>On Fri 05/Aug/2022 17:58:48 +0200 Scott Kitterman wrote:
>> I don't think it changes anything technically, but I think it goes
>> some way to address Ale's concerns about clarity.
>
>
>Some way it goes.
In that case, does anyone
On Sun, Aug 7, 2022 at 6:04 AM Alessandro Vesely wrote:
> On Sat 06/Aug/2022 16:29:47 +0200 John Levine wrote:
> >>> I don't understand what you mean by "no data collection." It is true
> that
> >>> you can send a failure report immediately without saving anything for
> >>> later.
> >>
> >>
On Sat 06/Aug/2022 16:29:47 +0200 John Levine wrote:
I don't understand what you mean by "no data collection." It is true that
you can send a failure report immediately without saving anything for
later.
“Those who cannot remember the past are condemned to repeat it.” – George
Santayana,
Count| Bytes | Who
++---
61 ( 100%) | 488594 ( 100%) | Total
14 (23.0%) | 84075 (17.2%) | Alessandro Vesely
13 (21.3%) | 70989 (14.5%) | John Levine
11 (18.0%) | 108102 (22.1%) | Douglas Foster
7 (11.5%) | 58068 (11.9%) | Murray S.
12 matches
Mail list logo
