-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Douglas Foster writes
>I am surprised at the lack of feedback about Barry's research link.
> It is a devastating attack on our ability to trust SPF when
>shared infrastructure is involved.
those of us who look at email
It appears that Todd Herr said:
>p=none by default." This seems inconsistent with the text in 5.7.2
>("Continue if one is found, or terminate DMARC evaluation otherwise") and
>4.7 ("Handling of DNS errors when querying for the DMARC policy record is
>left to the discretion of the Mail Receiver")
On Thu, Feb 29, 2024 at 2:14 PM Seth Blank wrote:
> As Chair: Consensus was already called. Todd just wants the wording
> consistent in the document. There's no need for another decision here.
>
This is my understanding as well. Mike Hammer summarized it neatly.
-MSK
As Chair: Consensus was already called. Todd just wants the wording
consistent in the document. There's no need for another decision here.
On Thu, Feb 29, 2024 at 4:36 PM Scott Kitterman
wrote:
> Right, I understand that view, but since the chairs have already stepped
> back on this issue, who
SPF trust was promised on the theory that shared infrastructure would
prevent clients from impersonating each other. This document blows up
that assumption.
It points out that clients have lost control of their SPF integrity.
Neither those clients nor their message recipients have enough data
On Wed, Feb 28, 2024 at 6:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I interpret your data differently. These domains collected data until it
> was clear that they could safely move to enforcement. Thereafter, they
> saw no need to study reports, at least until their
On Wed, Feb 28, 2024 at 7:37 PM Barry Leiba wrote:
> The editors and chairs think version -30 resolves the open issues and is
> ready for a final look, so this message starts a working group last call
> for the DMARCbis spec. Because of the upcoming IETF 119 meeting, we’ll let
> this go until
On Thursday, February 29, 2024 9:04:03 AM EST Todd Herr wrote:
> On Wed, Feb 28, 2024 at 6:27 PM Douglas Foster <
>
> dougfoster.emailstanda...@gmail.com> wrote:
> > I interpret your data differently. These domains collected data until it
> > was clear that they could safely move to
Would you prefer one comment/issue or in batch?
De: "Todd Herr"
À: "dmarc"
Envoyé: Jeudi 29 Février 2024 15:37:01
Objet: Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30
On Wed, Feb 28, 2024 at 7:37 PM Barry Leiba < [ mailto:barryle...@computer.org
|
This document is also ready for our final look, so this message starts
a working group last call for the aggregate reporting document, with
the same timing as for the DMARC spec.
Please post to the DMARC mailing list by 31 March, giving your last
call comments (which should include “I read it and
On Thu, Feb 29, 2024 at 9:58 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
> Would you prefer one comment/issue or in batch?
>
I would prefer that Barry's request be honored from his original post in
this thread, to wit:
If you have significant issues to raise that have not
On February 29, 2024 6:15:37 PM UTC, Benny Pedersen wrote:
>Douglas Foster skrev den 2024-02-29 18:48:
>> I am surprised at the lack of feedback about Barry's research link.
>> It is a devastating attack on our ability to trust SPF when shared
>> infrastructure is involved. As a result of
I am surprised at the lack of feedback about Barry's research link. It is
a devastating attack on our ability to trust SPF when shared infrastructure
is involved. As a result of that document, I have switched camps and
believe that we MUST provide a DKIM-only option for DMARC.
The proposed
It appears that Barry Leiba said:
>-=-=-=-=-=-
>
>A paper was presented this morning at NDSS about the state of SPF, which is
>worth a read by this group:
>
>https://www.ndss-symposium.org/ndss-paper/breakspf-how-shared-infrastructures-magnify-spf-vulnerabilities-across-the-internet/
I was
Douglas Foster skrev den 2024-02-29 18:48:
I am surprised at the lack of feedback about Barry's research link.
It is a devastating attack on our ability to trust SPF when shared
infrastructure is involved. As a result of that document, I have
switched camps and believe that we MUST provide a
Colleagues,
The second bullet of section 11.3 DNS Security reads:
"If they can block outgoing or reply DNS messages, they can prevent systems
from discovering senders' DMARC policies, causing recipients to assume
p=none by default." This seems inconsistent with the text in 5.7.2
("Continue if one
I agree that the rough consensus landed on "SHOULD NOT" even though there
were some who felt "MUST NOT" was "purer". I was one of those who
(reluctantly) supported "SHOULD NOT". Todd is simply trying to get
consistency within the document to match the outcome that there was rough
agreement on.
I think it ought to be resolved by the same AD that made the consensus call.
Scott K
On February 29, 2024 8:58:21 PM UTC, Dotzero wrote:
>I agree that the rough consensus landed on "SHOULD NOT" even though there
>were some who felt "MUST NOT" was "purer". I was one of those who
>(reluctantly)
This statement is patently false, though, and the guidance goes well beyond
operational reality. I think the statement should be struck in its entirety.
All the major free mail providers are moving to have DMARC policies on
their domains. Yahoo has it, 1und1 has it, Gmail has committed to do it.
It is not my intent here to relitigate any issues.
Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
on my part when the new text in 8.6 was published, and I just want to
confirm that 7.6 is indeed wrong.
On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman
wrote:
> In
I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman
wrote:
> Okay. I think 8.6 is the one in error. You see how this is going to go,
> right?
>
> Scott K
>
> On February 29, 2024 7:45:15 PM UTC, Todd Herr
Either way, I think Todd raises a valid point. Given the near identical
context of the language, the asserted intent should be consistent for
both, dependent on MUST NOT or SHOULD NOT consensus.
In my eyes as a consumer of the document output, I would probably be
asking the same clarifying
It appears that Scott Kitterman said:
>In what way is this a new issue that has not already been argued to death in
>the WG? I think for WGLC, we've already done this. We will, no doubt get to
>have this conversation during the IETF
>last call, but for the working group, this strikes me as
Colleagues,
I've been reading DMARCbic rev -30 today with a plan to collect the first
set of minor edits and I came across a sentence that I believe goes beyond
minor, so wanted to get a sanity check.
Section 7.6, Domain Owner Actions, ends with the following sentence:
In particular, this
In what way is this a new issue that has not already been argued to death in
the WG? I think for WGLC, we've already done this. We will, no doubt get to
have this conversation during the IETF last call, but for the working group,
this strikes me as exactly the type of relitigation of issues
Okay. I think 8.6 is the one in error. You see how this is going to go, right?
Scott K
On February 29, 2024 7:45:15 PM UTC, Todd Herr
wrote:
>It is not my intent here to relitigate any issues.
>
>Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
>on my part when the
Did we? The technical implications for interoperability are clear, so I don't
see why we would have decided to ignore them?
If you want to change it now, I don't see how you avoid reopening the issue
(you can't reopen the issue without reopening the issue).
Scott K
On February 29, 2024
I believe this to be the thread of reference on the topic -
https://mailarchive.ietf.org/arch/msg/dmarc/ink9cG3bono8O2Vif_ibiexad0A/
That's the thread I used to guide the updates to 8.6 in rev -29, anyway.
On Thu, Feb 29, 2024 at 2:53 PM Seth Blank wrote:
> I thought we landed on SHOULD NOT,
It was already resolved, Todd's point is that the text in 7.6 was never
updated to match, which was a mistake he wants to fix transparently.
On Thu, Feb 29, 2024 at 4:04 PM Scott Kitterman
wrote:
> I think it ought to be resolved by the same AD that made the consensus
> call.
>
> Scott K
>
> On
On Thu, Feb 29, 2024 at 10:10 AM Todd Herr wrote:
> On Thu, Feb 29, 2024 at 9:58 AM OLIVIER HUREAU <
> olivier.hur...@univ-grenoble-alpes.fr> wrote:
>
>> Would you prefer one comment/issue or in batch?
>>
>
> I would prefer that Barry's request be honored from his original post in
> this thread,
Right, I understand that view, but since the chairs have already stepped back
on this issue, who should make that call?
Scott K
On February 29, 2024 9:26:42 PM UTC, Seth Blank
wrote:
>It was already resolved, Todd's point is that the text in 7.6 was never
>updated to match, which was a
31 matches
Mail list logo
