On Tuesday, June 21, 2022 7:02:12 AM EDT Douglas Foster wrote:
> Before we move to coding the similarities, differences, and risks into the
> document, it would be useful just to generate a complete list within this
> WG.
>
> It would certainly be a breach of trust to omit information from the
>
Before we move to coding the similarities, differences, and risks into the
document, it would be useful just to generate a complete list within this
WG.
It would certainly be a breach of trust to omit information from the
document, if done for the purpose of hiding tree walk limitations.
Doug
On Sun 19/Jun/2022 18:08:57 +0200 John R Levine wrote:
That seems like a pessimal way to make things interoperate: use one of
an unknown set of algorithms ...
Given that we're already working in an environment where it's unlikely that
everyone's working from a common version of the PSL, I
On Sat 18/Jun/2022 15:47:47 +0200 Scott Kitterman wrote:
The code to switch from PSL based organizational domain to tree walk based is
trivial. I think any marginal cost associated with implementing it or not
will be in the noise compared to the overall cost of designing, coding,
testing, and
That seems like a pessimal way to make things interoperate: use one of
an unknown set of algorithms ...
Given that we're already working in an environment where it's unlikely that
everyone's working from a common version of the PSL, I don't think this is
such a scary idea.
But one of the
On Sat, Jun 18, 2022 at 11:10 AM John Levine wrote:
> That seems like a pessimal way to make things interoperate: use one of
> an unknown set of algorithms and the other party can't tell which one
> you're going to use. If we can't agree that the tree walk is better
> than piggybacking on the
It appears that Murray S. Kucherawy said:
>The tree walk might be the DBOUND solution, for all we know. Having it in
>a separate, generic-as-possible, document might make the technique usable
>by other applications as well.
We had a few plausible proposals in the DBOUND group, and none of them
On June 18, 2022 3:09:19 PM UTC, "Murray S. Kucherawy"
wrote:
>On Sat, Jun 18, 2022 at 7:49 AM Scott Kitterman
>wrote:
>
>> Given that the mechanism we've defined uses DMARC records to make the
>> determination, I don't think it would be useful to separate it into a
>> different document.
On Sat, Jun 18, 2022 at 7:49 AM Scott Kitterman
wrote:
> Given that the mechanism we've defined uses DMARC records to make the
> determination, I don't think it would be useful to separate it into a
> different document. If we ever get an approach that's not DMARC specific,
> then I think it
On June 18, 2022 2:35:07 PM UTC, "Murray S. Kucherawy"
wrote:
>On Sat, Jun 18, 2022 at 6:48 AM Scott Kitterman
>wrote:
>
>> On Saturday, June 18, 2022 8:42:23 AM EDT Douglas Foster wrote:
>> > Let's talk through the selling process for the Tree Walk algorithm.
>> ...
>> > In sum, why should
On Sat, Jun 18, 2022 at 6:48 AM Scott Kitterman
wrote:
> On Saturday, June 18, 2022 8:42:23 AM EDT Douglas Foster wrote:
> > Let's talk through the selling process for the Tree Walk algorithm.
> ...
> > In sum, why should an Evaluator make the switch?
>
> I think there are some good points in
On Saturday, June 18, 2022 8:42:23 AM EDT Douglas Foster wrote:
> Let's talk through the selling process for the Tree Walk algorithm.
...
> In sum, why should an Evaluator make the switch?
I think there are some good points in here. Fundamentally, I agree that there
needs to be a value
Let's talk through the selling process for the Tree Walk algorithm.
Who are our Stakeholders?
There are three main stakeholder groups for DMARC: Senders,
Intermediaries, and Evaluators.Senders and Intermediaries just want to
ensure their messages get delivered. Evaluators have the
13 matches
Mail list logo
