On October 25, 2023 3:38:01 AM UTC, "Murray S. Kucherawy"
wrote:
>On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba
>wrote:
>
>> Now that we have a consensus call on the main issue that has remained open:
>>
>> 1. Do we need to retain our session at IETF 118 and discuss this (or
>> something else)
On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba
wrote:
> Now that we have a consensus call on the main issue that has remained open:
>
> 1. Do we need to retain our session at IETF 118 and discuss this (or
> something else) further?
>
> ...or...
>
> 2. Do we have what we need to finish up the
On Tue, Oct 24, 2023 at 5:34 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> In short, I am not part of the presumed consensus on this document. I will
> vigorously oppose any document which does not discuss malicious
> impersonation defenses for every domain.
>
Doug,
A
On 10/24/2023 2:15 PM, Barry Leiba wrote:
Now that we have a consensus call on the main issue that has remained open:
1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?
...or...
2. Do we have what we need to finish up the DMARCbis document, and
My working assumption is that this document, if approved, will be the last
statement, for a long time to come, on matters of sender authentication and
malicious impersonation defenses. That assumption raises the question,
"Is this the best possible statement of how to defend against malicious
+1 SHOULD NOT
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Mark Alley
Sent: Tuesday, October 24, 2023 1:26 PM
To: Matt V
Cc: dmarc-cha...@ietf.org; Francesca Palombini
; IETF DMARC WG
; art-...@ietf.org
Subject: Re: [dmarc-ietf] Dmarcbis way
I changed the subject line to differentiate the discussion regarding an
additional document from the consensus thread.
On Tue, Oct 24, 2023 at 1:15 PM Murray S. Kucherawy
wrote:
> [trimming redundant Ccs]
>
> On Tue, Oct 24, 2023 at 9:41 AM Dotzero wrote:
>
>> I'd like to first thank Francesca
Now that we have a consensus call on the main issue that has remained open:
1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?
...or...
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
Oh,
+1 for SHOULD NOT.
On Tue, Oct 24, 2023, 12:14 PM Matt V wrote:
> I also agree that "SHOULD NOT" would be my vote as the preferred language
> going forward.
>
> ~
> Matt
>
> On Tue, Oct 24, 2023 at 12:41 PM Dotzero wrote:
>
>> I'd like to first thank Francesca for taking the time to review
[trimming redundant Ccs]
On Tue, Oct 24, 2023 at 9:41 AM Dotzero wrote:
> I'd like to first thank Francesca for taking the time to review where the
> working group is as far as consensus.
>
+1, that was a lot to sift through.
The short version of the non-normative language should be in the
I also agree that "SHOULD NOT" would be my vote as the preferred language
going forward.
~
Matt
On Tue, Oct 24, 2023 at 12:41 PM Dotzero wrote:
> I'd like to first thank Francesca for taking the time to review where the
> working group is as far as consensus.
>
> I fall into the "SHOULD NOT"
I'd like to first thank Francesca for taking the time to review where the
working group is as far as consensus.
I fall into the "SHOULD NOT" consensus group with additional non-normative
language.
The short version of the non-normative language should be in the document
itself but I believe the
On Tue, Oct 24, 2023 at 8:57 AM Scott Kitterman
wrote:
> My understanding of IETF consensus is that technical objections have been
> addressed. I think this is critical to the difference between IETF
> consensus and voting. It's not just 'most people think X'. I don't think
> that the
I sincerely appreciate the work that Francesca put into this analysis. This
type of measured review of the conversation so far is incredibly valuable to
help focus input.
For my part, I would like to contribute support for proposed language
leveraging how domain administrators concerned
On October 24, 2023 3:38:54 PM UTC, "Murray S. Kucherawy"
wrote:
>On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman
>wrote:
>
>> I don't think this is consistent with the IETF's mandate to provide
>> documents
>> which promote interoperability. I do not, however, plan to file an appeal
>>
On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman
wrote:
> I don't think this is consistent with the IETF's mandate to provide
> documents
> which promote interoperability. I do not, however, plan to file an appeal
> about it.
>
Two things to say about that:
(1) This is Francesca's
Hi,
Le 23/10/2023 à 19:59, Alessandro Vesely a écrit :
My opinion is that Barry's text is good as is. As far as delimiting a
SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me:
It is therefore critical that domains that host users who might
post messages to
I think for interoperability reasons a MUST NOT is the correct decision:
Domains that choose to use p=reject and then allow their users to post to
mailing lists damage interoperability for uninvolved third parties. However,
for rough consensus purposes I would support Barry’s SHOULD NOT
Thanks for that, Scott. For what it’s worth, i have sympathy for your
position, both as a participant and as chair. I do, though think that what
we have now or something like it is the only way we will get rough
consensus, that the other option is not to publish DMARC as a standard, and
that
19 matches
Mail list logo
