Re: [dmarc-ietf] Dmarcbis way forward

[Neil Anuskiewicz]

> On Nov 12, 2023, at 4:00 AM, Alessandro Vesely  wrote:
> 
> On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote:
 On Oct 23, 2023, at 11:00 AM, Alessandro Vesely  wrote:
>>> 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 mailing lists SHOULD NOT publish p=reject. Domains
>>>that choose to publish p=reject SHOULD implement policies that
>>>their users not post to Internet mailing lists.
>>> The exceptions to the latter SHOULD are rather obvious.  Do we really need 
>>> to formally specify domain policing?
>>> My perception is that Section 8.6 puts the issue in very clear terms.  It 
>>> is even overly clearly and thoroughly explained for average readers.  Only 
>>> IETF purists longing for email as it was in the 80s consider it important 
>>> to point out how DMARC is unjustly oppressing email forwarding, including 
>>> mailing lists.  The rest of the world just use it as needed.
>> What happened to the general purpose domain, actually subdomain, which I 
>> understood to be a non enforcing subdomain just for distribution lists. That 
>> idea was far from perfect but it seemed good. To clarify were you obliquely 
>> supporting the general purpose domain idea?
>> I can think of alternatives but those alternatives clearly affect 
>> interoperability. Since. Discussion some weeks ago I learned here that we 
>> must consider interoperability at every step, which makes sense morally and 
>> practically in the face of a real interoperability issue.
>> Yeah, I lurk enough to have drunk the koolaid. That said, are there list 
>> operators who participate and cogently make their case on why there’s no 
>> viable mitigating changes they could make? It’s plausible that the answer is 
>> no but it’s not 100% clear that this is a problem that can’t be solved. It’s 
>> pretty clear there aren’t good solutions on less bad ones.
>> If this issue is already decided on and I’m beating a dead horse, I 
>> apologize. If I’m going to lurk it’s got to be every day for at least a few 
>> minutes to avoid dead horse beating that I’m sure is annoying.
> 
> 
> A taxonomy of possible mitigations was published in 2014:
> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail
> 
> That page distinguishes among sending side workarounds and other approaches. 
> The former can be implemented unilaterally without further discussions. 
> Discussions take decades, as we see.  It seems that mailing lists, and 
> forwarding in general constitute a minor problem for the vast majority of 
> mailbox providers.  The urgency for a better solution is only perceived by 
> mailing list users, an area where ietfers are especially active but the rest 
> of the world, on average, is not.
> 
> There are cooperative solutions, but they won't be implemented until 
> forwarding becomes a noticeable problem for large operators.

Sir, that these mitigations can be implemented without discussion, then doesn't 
that make the problem needing mitigation outside the scope of this working 
group? The difference between no discussion and a working group is like the 
ocean and a bucket of water. Don't let anything that isn't a flat out blocker 
get in the way. Encourage use of the bucket but you can lead an admin to water.

Neil
> -- 
> 
> 
> 
> 
> 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Douglas Foster]

MUST NOT or SHOULD NOT make little difference.   Both are the Crocker
Proposal revived and simplified:  "The solution to authentication problems
MUST be LESS AUTHENTICATION!"If you can convince nearly all senders to
use p=NONE, and if you can convince nearly all evaluators to enforce only
when p=REJECT, then you will have created the pretense of an authentication
regime without much actual authentication.   Spammers are very good at mass
production, so we can expect 100 malicious impersonations to be allowed for
every 1 legitimate mailing list message allowed.

One problem is that the strategy is unlikely to work.   I don't expect
our document to convince large numbers of p=reject organizations to
suddenly embrace p=reject.   I also expect savvy organizations to start
enforcing authentication even when p=none, if they are not doing so
already.  I don't need Gmail to publish p=reject to identify and block
the attacks which falsely pretend to be from Gmail.   Given the suggested
1:100 problem, the proposed solution to the mailing list problem is an
unstable equilibrium.

We should also be worried that we are losing our audience.The big
evaluation platforms get bigger every day, and they have problems that
cannot wait years while we try to churn out documents.   I have been
disappointed by their absence or silence, but I should not have been.   How
have we given them reason to believe that we know something that they have
not already figured out?   Our real audience is the shrinking market of
organizations and product developers that are trying to solve the email
filtering problem without surrendering completely to big tech.   That
audience needs guidance on how to evaluate correctly, and our document has
systematically avoided doing so.

Our document should read like an FDA-approved commercial for prescription
medicine:   :"This is a great product, but you should also be aware that
these are four ways it could maim or kill you."

Sender Authentication, used properly, is a powerful defense against
malicious actors.   But any implementation needs to be prepared to handle
(a) strict authentication policies when relaxed authentication is needed.
(b) ESP messages that lack a client domain signature
(c) Mailing list messages that lack a verifiable author domain signature
(d) Duplicate and incorrect SPF policies
(e) Incorrectly determined organizational boundaries
and some others.

To this point, RFC 7489 and DMARCbis are content to let evaluators figure
all of this out on their own.  The price for their learning curve is that
acceptable messages are blocked and unacceptable messages are allowed.   If
you want your acceptable messages to be accepted, you have a vested
interest in minimizing that learning curve rather than prologing it.

MUST NOT is not the solution.   Intelligent advice for intelligent
evaluators could be.

Doug Foster






On Wed, Nov 15, 2023 at 7:51 PM Jim Fenton  wrote:

> I’m a little slow responding to this; my apologies for that.
>
> On 23 Oct 2023, at 1:03, Francesca Palombini wrote:
>
> > I believe there is a rough consensus that a change needs to be made in
> the text to include stronger requirements admonishing operators against
> deploying DMARC in a way that causes disruption. The mails go in many
> directions, but the most contentious point I could identify is if there
> ought to be some normative MUST NOT or SHOULD NOT text. Many people have
> suggested text (thank you!). I believe the ones with more tractions are
> Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3].
>
> Count me in the MUST NOT column, using either Scott’s text or the original
> text from Barry [1]. The document needs to make a clear statement here, and
> the text in [3] is far too verbose for most readers to follow, especially
> when the reasons for not following the SHOULD NOT are added. In addition,
> [3] seems to presume that the sending domain has some way of knowing what
> email addresses are mailing lists, and presumes that it knows something
> about the disposition decision that will be made by the receiving domain
> (that it does not, in general, even know). Sure, it might determine mailing
> lists heuristically (looking for mailing list headers on incoming messages,
> for example), but that won’t work in all cases (alumni addresses being an
> example).
>
> I’m also concerned about p=quarantine: I’m under the impression that
> address rewriting is done by some mailing lists to avoid the quarantining
> of mailing list messages. If that is the case, whatever is said about
> p=reject should also apply to p=quarantine.
>
> -Jim
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Jim Fenton]

I’m a little slow responding to this; my apologies for that.

On 23 Oct 2023, at 1:03, Francesca Palombini wrote:

> I believe there is a rough consensus that a change needs to be made in the 
> text to include stronger requirements admonishing operators against deploying 
> DMARC in a way that causes disruption. The mails go in many directions, but 
> the most contentious point I could identify is if there ought to be some 
> normative MUST NOT or SHOULD NOT text. Many people have suggested text (thank 
> you!). I believe the ones with more tractions are Scott’s MUST NOT proposal 
> [2] and Barry’s SHOULD NOT proposal [3].

Count me in the MUST NOT column, using either Scott’s text or the original text 
from Barry [1]. The document needs to make a clear statement here, and the text 
in [3] is far too verbose for most readers to follow, especially when the 
reasons for not following the SHOULD NOT are added. In addition, [3] seems to 
presume that the sending domain has some way of knowing what email addresses 
are mailing lists, and presumes that it knows something about the disposition 
decision that will be made by the receiving domain (that it does not, in 
general, even know). Sure, it might determine mailing lists heuristically 
(looking for mailing list headers on incoming messages, for example), but that 
won’t work in all cases (alumni addresses being an example).

I’m also concerned about p=quarantine: I’m under the impression that address 
rewriting is done by some mailing lists to avoid the quarantining of mailing 
list messages. If that is the case, whatever is said about p=reject should also 
apply to p=quarantine.

-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Alessandro Vesely]

On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote:

On Oct 23, 2023, at 11:00 AM, Alessandro Vesely  wrote:

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 mailing lists SHOULD NOT publish p=reject. Domains
that choose to publish p=reject SHOULD implement policies that
their users not post to Internet mailing lists.

The exceptions to the latter SHOULD are rather obvious.  Do we really need to 
formally specify domain policing?

My perception is that Section 8.6 puts the issue in very clear terms.  It is 
even overly clearly and thoroughly explained for average readers.  Only IETF 
purists longing for email as it was in the 80s consider it important to point 
out how DMARC is unjustly oppressing email forwarding, including mailing lists. 
 The rest of the world just use it as needed.


What happened to the general purpose domain, actually subdomain, which I 
understood to be a non enforcing subdomain just for distribution lists. That 
idea was far from perfect but it seemed good. To clarify were you obliquely 
supporting the general purpose domain idea?

I can think of alternatives but those alternatives clearly affect 
interoperability. Since. Discussion some weeks ago I learned here that we must 
consider interoperability at every step, which makes sense morally and 
practically in the face of a real interoperability issue.

Yeah, I lurk enough to have drunk the koolaid. That said, are there list 
operators who participate and cogently make their case on why there’s no viable 
mitigating changes they could make? It’s plausible that the answer is no but 
it’s not 100% clear that this is a problem that can’t be solved. It’s pretty 
clear there aren’t good solutions on less bad ones.

If this issue is already decided on and I’m beating a dead horse, I apologize. 
If I’m going to lurk it’s got to be every day for at least a few minutes to 
avoid dead horse beating that I’m sure is annoying.



A taxonomy of possible mitigations was published in 2014:
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

That page distinguishes among sending side workarounds and other approaches. 
The former can be implemented unilaterally without further discussions. 
Discussions take decades, as we see.  It seems that mailing lists, and 
forwarding in general constitute a minor problem for the vast majority of 
mailbox providers.  The urgency for a better solution is only perceived by 
mailing list users, an area where ietfers are especially active but the rest of 
the world, on average, is not.


There are cooperative solutions, but they won't be implemented until forwarding 
becomes a noticeable problem for large operators.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Neil Anuskiewicz]

> On Nov 11, 2023, at 7:24 PM, Steven M Jones  wrote:
> 
> On 11/12/23 03:59, Neil Anuskiewicz wrote:
>> What is the definition of rough consensus. That is if you took a vote, 100 
>> people voted yes and 3 voted no, the three win? Id there’s a document that 
>> states these rules I’d be happy to dig into it. If there’s a rule we should 
>> have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
>> understandable if I’m not entitled to a vote. That said, what do the rules 
>> say?
> 
> 
> Scott gave the chapter-and-verse reference:
> 
>> https://datatracker.ietf.org/doc/html/rfc7282
> 
> The problem we typically have is with the level of participation. 
> Specifically, not having enough people actively participating. (I am guilty 
> of being a "variable" participant myself.)
> 
> As I described the situation to a group last week, consensus is a very 
> different animal when you have your 100 participants, versus 6 or 8 regular 
> participants. The lower the number, the more space each question/objection 
> takes up.
> 
> That's just group dynamics; on top of that, you have questions like whether 
> the X or Y participants you have adequately represent the "Internet 
> community," or even the "IETF community," as Murray raised in San Francisco.

I volunteer to participate when I’m ready in terms of knowledge and I’ll strive 
to develop my participation savvy. Lol. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Steven M Jones]

On 11/12/23 03:59, Neil Anuskiewicz wrote:

What is the definition of rough consensus. That is if you took a vote, 100 
people voted yes and 3 voted no, the three win? Id there’s a document that 
states these rules I’d be happy to dig into it. If there’s a rule we should 
have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
understandable if I’m not entitled to a vote. That said, what do the rules say?



Scott gave the chapter-and-verse reference:


https://datatracker.ietf.org/doc/html/rfc7282


The problem we typically have is with the level of participation. 
Specifically, not having enough people actively participating. (I am 
guilty of being a "variable" participant myself.)


As I described the situation to a group last week, consensus is a very 
different animal when you have your 100 participants, versus 6 or 8 
regular participants. The lower the number, the more space each 
question/objection takes up.


That's just group dynamics; on top of that, you have questions like 
whether the X or Y participants you have adequately represent the 
"Internet community," or even the "IETF community," as Murray raised in 
San Francisco.


--S.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Neil Anuskiewicz]

> On Nov 11, 2023, at 11:06 AM, Scott Kitterman  wrote:
> 
> The short answer is it depends.  We don't vote.
> 
> Here's the longer answer:
> 
> https://datatracker.ietf.org/doc/html/rfc7282
> 
> Scott K
> 
>> On November 11, 2023 6:59:20 PM UTC, Neil Anuskiewicz  
>> wrote:
>> What is the definition of rough consensus. That is if you took a vote, 100 
>> people voted yes and 3 voted no, the three win? Id there’s a document that 
>> states these rules I’d be happy to dig into it. If there’s a rule we should 
>> have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
>> understandable if I’m not entitled to a vote. That said, what do the rules 
>> say? 
>> 
 On Oct 23, 2023, at 9:07 PM, Scott Kitterman  wrote:
>>> 
>>> On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
 I have been asked by Murray to assist with a consensus evaluation on the
 discussion that has been going on for a while about the dmarcbis document
 and how to move forward.
 
 I have made an attempt to evaluate consensus on the topic, trying to look 
 at
 it from a complete outsider’s point of view and trying not to let my
 personal opinion bias my assessment. This is a summary of that evaluation.
 It is based on several threads in the mailing list: [1], [2], [3] and
 recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
 chronology of comments, because some people have expressed different
 support for different proposals, in which case I consider the latest email
 I can find as the person’s latest opinion. Although that was mentioned, I
 believe there is no consensus to move the document status to Informational.
 I believe there is a rough consensus that a change needs to be made in the
 text to include stronger requirements admonishing operators against
 deploying DMARC in a way that causes disruption. The mails go in many
 directions, but the most contentious point I could identify is if there
 ought to be some normative MUST NOT or SHOULD NOT text. Many people have
 suggested text (thank you!). I believe the ones with more tractions are
 Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3]. I
 believe most people who’d prefer just descriptive text have stated that
 they can live with the SHOULD NOT text, but they have stronger objections
 towards the MUST NOT text. There also a number of people who strongly
 believe MUST NOT is the way to go, but these people have not objected
 strongly to Barry’s latest proposed text in the mailing list (although they
 have made their preference clear during the meeting [4]). As a consequence,
 I believe there is a stronger (very rough) consensus for going with Barry’s
 SHOULD NOT text. I also believe there is consensus to add some
 non-normative explanatory text (be it in the interoperability or security
 consideration sections, or both) around it. I suggest the authors and the
 working group start with Berry’s text and fine-tune the details around it.
 In particular, as another AD that might have to ballot on this document, I
 suggest that you pay particular attention to the text around the SHOULD
 NOT, as also Murray suggested in [5]. I have often blocked documents with
 the following text: “If SHOULD is used, then it must be accompanied by at
 least one of: (1) A general description of the character of the exceptions
 and/or in what areas exceptions are likely to arise.  Examples are fine
 but, except in plausible and rare cases, not enumerated lists. (2) A
 statement about what should be done, or what the considerations are, if the
 "SHOULD" requirement is not met. (3) A statement about why it is not a
 MUST.”. I appreciate everybody’s patience and constructive discussion.

 If I’m not mistaken Francesca has outlined an opening for a deal. 
 According to the rules document, making everyone 100% happy isn’t the 
 priority. If agreement can be reached that’s satisfactory to most, if not 
 all parties, could get us to rough consensus.  This seems like evidence 
 that the parties aren’t taking immutable stands, leaving an opening for an 
 agreement. Well done, Francesca, your astute summary might possibly get us 
 over the finish line avoiding a protracted stalemate.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Scott Kitterman]

The short answer is it depends.  We don't vote.

Here's the longer answer:

https://datatracker.ietf.org/doc/html/rfc7282

Scott K

On November 11, 2023 6:59:20 PM UTC, Neil Anuskiewicz  
wrote:
>What is the definition of rough consensus. That is if you took a vote, 100 
>people voted yes and 3 voted no, the three win? Id there’s a document that 
>states these rules I’d be happy to dig into it. If there’s a rule we should 
>have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
>understandable if I’m not entitled to a vote. That said, what do the rules 
>say? 
>
>> On Oct 23, 2023, at 9:07 PM, Scott Kitterman  wrote:
>> 
>> On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
>>> I have been asked by Murray to assist with a consensus evaluation on the
>>> discussion that has been going on for a while about the dmarcbis document
>>> and how to move forward.
>>> 
>>> I have made an attempt to evaluate consensus on the topic, trying to look at
>>> it from a complete outsider’s point of view and trying not to let my
>>> personal opinion bias my assessment. This is a summary of that evaluation.
>>> It is based on several threads in the mailing list: [1], [2], [3] and
>>> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
>>> chronology of comments, because some people have expressed different
>>> support for different proposals, in which case I consider the latest email
>>> I can find as the person’s latest opinion. Although that was mentioned, I
>>> believe there is no consensus to move the document status to Informational.
>>> I believe there is a rough consensus that a change needs to be made in the
>>> text to include stronger requirements admonishing operators against
>>> deploying DMARC in a way that causes disruption. The mails go in many
>>> directions, but the most contentious point I could identify is if there
>>> ought to be some normative MUST NOT or SHOULD NOT text. Many people have
>>> suggested text (thank you!). I believe the ones with more tractions are
>>> Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3]. I
>>> believe most people who’d prefer just descriptive text have stated that
>>> they can live with the SHOULD NOT text, but they have stronger objections
>>> towards the MUST NOT text. There also a number of people who strongly
>>> believe MUST NOT is the way to go, but these people have not objected
>>> strongly to Barry’s latest proposed text in the mailing list (although they
>>> have made their preference clear during the meeting [4]). As a consequence,
>>> I believe there is a stronger (very rough) consensus for going with Barry’s
>>> SHOULD NOT text. I also believe there is consensus to add some
>>> non-normative explanatory text (be it in the interoperability or security
>>> consideration sections, or both) around it. I suggest the authors and the
>>> working group start with Berry’s text and fine-tune the details around it.
>>> In particular, as another AD that might have to ballot on this document, I
>>> suggest that you pay particular attention to the text around the SHOULD
>>> NOT, as also Murray suggested in [5]. I have often blocked documents with
>>> the following text: “If SHOULD is used, then it must be accompanied by at
>>> least one of: (1) A general description of the character of the exceptions
>>> and/or in what areas exceptions are likely to arise.  Examples are fine
>>> but, except in plausible and rare cases, not enumerated lists. (2) A
>>> statement about what should be done, or what the considerations are, if the
>>> "SHOULD" requirement is not met. (3) A statement about why it is not a
>>> MUST.”. I appreciate everybody’s patience and constructive discussion.
>>> Francesca, ART AD
>>> [1]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>>> [2]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>>> [3]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>>> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>>> [5]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
>> 
>> 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.
>> 
>> Scott K
>> 
>> 
>> 
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Neil Anuskiewicz]

What is the definition of rough consensus. That is if you took a vote, 100 
people voted yes and 3 voted no, the three win? Id there’s a document that 
states these rules I’d be happy to dig into it. If there’s a rule we should 
have a vote. Who is entitled to vote? Like I’m new to this and so it’d be 
understandable if I’m not entitled to a vote. That said, what do the rules say? 

> On Oct 23, 2023, at 9:07 PM, Scott Kitterman  wrote:
> 
> On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
>> I have been asked by Murray to assist with a consensus evaluation on the
>> discussion that has been going on for a while about the dmarcbis document
>> and how to move forward.
>> 
>> I have made an attempt to evaluate consensus on the topic, trying to look at
>> it from a complete outsider’s point of view and trying not to let my
>> personal opinion bias my assessment. This is a summary of that evaluation.
>> It is based on several threads in the mailing list: [1], [2], [3] and
>> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
>> chronology of comments, because some people have expressed different
>> support for different proposals, in which case I consider the latest email
>> I can find as the person’s latest opinion. Although that was mentioned, I
>> believe there is no consensus to move the document status to Informational.
>> I believe there is a rough consensus that a change needs to be made in the
>> text to include stronger requirements admonishing operators against
>> deploying DMARC in a way that causes disruption. The mails go in many
>> directions, but the most contentious point I could identify is if there
>> ought to be some normative MUST NOT or SHOULD NOT text. Many people have
>> suggested text (thank you!). I believe the ones with more tractions are
>> Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3]. I
>> believe most people who’d prefer just descriptive text have stated that
>> they can live with the SHOULD NOT text, but they have stronger objections
>> towards the MUST NOT text. There also a number of people who strongly
>> believe MUST NOT is the way to go, but these people have not objected
>> strongly to Barry’s latest proposed text in the mailing list (although they
>> have made their preference clear during the meeting [4]). As a consequence,
>> I believe there is a stronger (very rough) consensus for going with Barry’s
>> SHOULD NOT text. I also believe there is consensus to add some
>> non-normative explanatory text (be it in the interoperability or security
>> consideration sections, or both) around it. I suggest the authors and the
>> working group start with Berry’s text and fine-tune the details around it.
>> In particular, as another AD that might have to ballot on this document, I
>> suggest that you pay particular attention to the text around the SHOULD
>> NOT, as also Murray suggested in [5]. I have often blocked documents with
>> the following text: “If SHOULD is used, then it must be accompanied by at
>> least one of: (1) A general description of the character of the exceptions
>> and/or in what areas exceptions are likely to arise.  Examples are fine
>> but, except in plausible and rare cases, not enumerated lists. (2) A
>> statement about what should be done, or what the considerations are, if the
>> "SHOULD" requirement is not met. (3) A statement about why it is not a
>> MUST.”. I appreciate everybody’s patience and constructive discussion.
>> Francesca, ART AD
>> [1]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>> [2]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>> [3]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>> [5]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
> 
> 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.
> 
> Scott K
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Neil Anuskiewicz]

> On Oct 23, 2023, at 11:00 AM, Alessandro Vesely  wrote:
> 
> 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 mailing lists SHOULD NOT publish p=reject. Domains
> that choose to publish p=reject SHOULD implement policies that
> their users not post to Internet mailing lists.
> 
> The exceptions to the latter SHOULD are rather obvious.  Do we really need to 
> formally specify domain policing?
> 
> My perception is that Section 8.6 puts the issue in very clear terms.  It is 
> even overly clearly and thoroughly explained for average readers.  Only IETF 
> purists longing for email as it was in the 80s consider it important to point 
> out how DMARC is unjustly oppressing email forwarding, including mailing 
> lists.  The rest of the world just use it as needed.

What happened to the general purpose domain, actually subdomain, which I 
understood to be a non enforcing subdomain just for distribution lists. That 
idea was far from perfect but it seemed good. To clarify were you obliquely 
supporting the general purpose domain idea? 

I can think of alternatives but those alternatives clearly affect 
interoperability. Since. Discussion some weeks ago I learned here that we must 
consider interoperability at every step, which makes sense morally and 
practically in the face of a real interoperability issue. 

Yeah, I lurk enough to have drunk the koolaid. That said, are there list 
operators who participate and cogently make their case on why there’s no viable 
mitigating changes they could make? It’s plausible that the answer is no but 
it’s not 100% clear that this is a problem that can’t be solved. It’s pretty 
clear there aren’t good solutions on less bad ones.  

If this issue is already decided on and I’m beating a dead horse, I apologize. 
If I’m going to lurk it’s got to be every day for at least a few minutes to 
avoid dead horse beating that I’m sure is annoying.

Neil
> 
> 
>> On Mon 23/Oct/2023 10:03:36 +0200 Francesca Palombini wrote:
>> I have been asked by Murray to assist with a consensus evaluation on the 
>> discussion that has been going on for a while about the dmarcbis document 
>> and how to move forward.
>> I have made an attempt to evaluate consensus on the topic, trying to look at 
>> it from a complete outsider’s point of view and trying not to let my 
>> personal opinion bias my assessment. This is a summary of that evaluation. 
>> It is based on several threads in the mailing list: [1], [2], [3] and 
>> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to 
>> chronology of comments, because some people have expressed different support 
>> for different proposals, in which case I consider the latest email I can 
>> find as the person’s latest opinion.
>> Although that was mentioned, I believe there is no consensus to move the 
>> document status to Informational. I believe there is a rough consensus that 
>> a change needs to be made in the text to include stronger requirements 
>> admonishing operators against deploying DMARC in a way that causes 
>> disruption. The mails go in many directions, but the most contentious point 
>> I could identify is if there ought to be some normative MUST NOT or SHOULD 
>> NOT text. Many people have suggested text (thank you!). I believe the ones 
>> with more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT 
>> proposal [3]. I believe most people who’d prefer just descriptive text have 
>> stated that they can live with the SHOULD NOT text, but they have stronger 
>> objections towards the MUST NOT text. There also a number of people who 
>> strongly believe MUST NOT is the way to go, but these people have not 
>> objected strongly to Barry’s latest proposed text in the mailing list 
>> (although they have made their preference clear during the meeting [4]). As 
>> a consequence, I believe there is a stronger (very rough) consensus for 
>> going with Barry’s SHOULD NOT text. I also believe there is consensus to add 
>> some non-normative explanatory text (be it in the interoperability or 
>> security consideration sections, or both) around it.
>> I suggest the authors and the working group start with Berry’s text and 
>> fine-tune the details around it.
>> In particular, as another AD that might have to ballot on this document, I 
>> suggest that you pay particular attention to the text around the SHOULD NOT, 
>> as also Murray suggested in [5]. I have often blocked documents with the 
>> following text: “If SHOULD is used, then it must be accompanied by at least 
>> one of: (1) A general description of the character of the exceptions and/or 
>> in what areas exceptions are likely to arise.  Examples are fine but, except 
>> in plausible and rare cases, not enumerated lists. (2) A statement about 
>> wha

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Neil Anuskiewicz]

> On Oct 28, 2023, at 5:01 AM, Alessandro Vesely  wrote:
> 
> On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  
>>> wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
 If there isn't a consensus to do a DKIM-only feature, which seems to be 
 the case, I agree, wrap up the few minor editorial issues and we're done.
>>> 
>>> If we add the feature, we should in any case exemplify how to fix SPF, 
>>> saying that doing so is safer, at least until all DMARC software has 
>>> acquired the new feature.  As the addition would be understood as a 
>>> response to the known vulnerability, it will likely be spread.
>>> 
>>> As many of us consider it cleaner to have DMARC based on DKIM only, having 
>>> that possibility as an option is a first step in that direction anyway.  
>>> The thesis that DKIM is enough has been opposed but the only cases where 
>>> SPF saves the day seem to be software bugs.  The DKIM-only feature would 
>>> allow to probe that thesis, which fixing SPF records would not.
>> 
>> What do we know now that we didn't know the last time we decided not to go 
>> DKIM only?  I'd argue there's nothing and endless relitigation of issues 
>> like this is making it impossible to actually accomplish what we're 
>> chartered to accomplish.
> 
> 
> You're the only one strongly opposing the idea, AFAICS, and I still don't 
> know why.
> 
> 
>> Let's either focus and finish or give up and close the group.
> 
> 
> Even if we don't add the feature, we should address the vulnerability. 
> Currently there is only a bullet in Section 4.8, Organizational Domain 
> Discovery, saying:
> 
>* The domain found in the RFC5321.MailFrom header if there is an SPF
>  pass result for the message being evaluated.
> 
> We need to add a subsection in Security Consideration, discussing an example 
> of an include mechanism with a neutral qualifier and its effect on DMARC 
> outcome; that is, how that avoids spurious authentications.
> 
> The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
> Specific to SPF.  We could add a reference to the added subsection there.
> 
If explicit language gets us a good portion of the way there. That is forward 
progress for those who support this. Alexandra there must be others not willing 
to go that direction and digging in wil just mean this same conversation 6 
months ago. To keep it neutral the hums should prevail now and those who lost 
this one, remember the battle may be winding down but you have time to provide 
tangible evidence this was a brain dead decision. I’m guess WG members are 
smart and experience quite a bit of neurogenesis (I.e., don’t hold to an idea 
for ego certitude). Even if those who don’t hum hate it, take solace that time 
will show you right if you are right and I doubt anyone humming will hum that 
dissonant song of wrong again. 

If the no hummers are right I hope they humbly re litigate this and change a 
bad policy. Let’s test drive this baby and see if it breaks down out in the 
boonies.
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

On a theoretical level, probabilistic tools like spam assassin will be
predictably wrong some of the time.   Accurate disposition requires audits
and overrides using static rules based on confirmed evidence.  I cannot
find much sympathy for sites that enforce SPF without considering DKIM and
without an audit process.   They are better off ignoring SPF completely.

In the matter of SPF Upgrade attacks, we start from the assumption that SPF
PASS is not reliably true, so neutral is closer to the truth.

Doug

On Sun, Oct 29, 2023, 8:41 PM Tero Kivinen  wrote:

> Murray S. Kucherawy writes:
> > On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
> > dougfoster.emailstanda...@gmail.com> wrote:
> >
> > By contrast, the new tag cannot be effective until DMARCbis is
> published
> > and filtering software updated.  This involves years.  Even then,
> domain
> > owners will never have confidence that the new token support has been
> > implemented by all recipient evaluators.
> >
> > At least on its face, this is a big concern.  A domain owner publishing
> "auth=
> > dkim" is going to get varying results as some sites update to software
> > supporting such a tag while others ignore it.  I don't know if the
> potential
> > for some benefit is a desirable trade for the potential for some
> confusion.
>
> Varying meaning, those who implement auth=dkim will get extra
> protection, and those who do not, are left as they are now.
>
> I myself think that adding clear indication that sender always uses
> dkim, and evaluators can rely on that makes the DMARC better, and more
> secure.
>
> And as every DMARC evaluator needs to support DKIM anyways (there is
> no such thing as SPF only DMARC evaluator, both SPF and DKIM are
> mandatory to implement), there is no real difference in complexity for
> evaluators.
>
> > Seems like a slam dunk for SPF neutral.  I said the problem and it's
> > solution needs to be laid out in our document because I am one of
> those
> > who did not understand it as a possible strategy
> >
> > I think I agree.
>
> This will also change the behavior of the receivers. For example
> spamassasin does give more points to SPF_NEUTRAL (around 0.6-0.7) than
> SPF_PASS (-0.001) etc. I would assume other similar software also use
> SPF results similarly.
>
> The reason why SPF_PASS gives only -0.001 is that it is assumed that
> spammers will use their own domain and thus can get SPF records to
> match (DMARC, DKIM and SPF are never meant to work against spammers).
> --
> kivi...@iki.fi
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sun 29/Oct/2023 21:03:17 +0100 Mark Alley wrote:
Giving this some more thought from the opposite point of view... the benefits 
to an auth=DKIM method in DMARC itself would remove the need for domain owners 
to do SPF tinkering for any upgrade mitigation, and shared mail infrastructure 
where one could potentially be affected by SPF upgrade could instead be 
mitigated by the new tag, but still retain positive SPF authentication.



Hm... diligent SPF settings are still due.  I don't think the ability to sweep 
SPF negligence under DMARC carpet can be considered an upside...



So, theoretically, if we look at it that way, there are a couple of upsides, 
although obviously there is additional added complexity, and as Doug surmised, 
the adaptation of mail filters will take a significant amount of time before we 
see any semblance of ubiquitous adoption.



For added complexity, we need to add an element to the PolicyPublishedType to 
account for auth=.




I'm on the fence currently about the auth= method.



+1, it's role for the next several years seems to be a gauge in the security 
theater.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Douglas Foster 
writes

>By contrast, the new tag cannot be effective until DMARCbis is published
>and filtering software updated.  This involves years.  

Hard to say ... there is some self-interest here in having shiny new
features (such as they are) and it is argued that pretty much everyone
uses one of a small number of libraries so only a small number of
programmers need to stay up late to make updating possible

Although people did not update software very often 20 years back, fear
of compromises (and the widespread existence of such compromises) means
that updating cycles are far faster than they used to be.

>Even then, domain
>owners will never have confidence that the new token support has been
>implemented by all recipient evaluators.

That of course was one of the reasons for having a version bump ... but
there was no consensus for that. However, careful reading of reports
will tell you whether those evaluators who send reports have updated,
and you can take a view from those

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT8VyN2nQQHFxEViEQI4KwCgoq/AfjOOaln5Gz+lGTdC1w2jHG8AoNvY
ojMIxIPArJ94MmA8MhS1tJ0Z
=bOmC
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Tero Kivinen]

Murray S. Kucherawy writes:
> On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> 
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated.  This involves years.  Even then, domain
> owners will never have confidence that the new token support has been
> implemented by all recipient evaluators.
> 
> At least on its face, this is a big concern.  A domain owner publishing "auth=
> dkim" is going to get varying results as some sites update to software
> supporting such a tag while others ignore it.  I don't know if the potential
> for some benefit is a desirable trade for the potential for some confusion.

Varying meaning, those who implement auth=dkim will get extra
protection, and those who do not, are left as they are now.

I myself think that adding clear indication that sender always uses
dkim, and evaluators can rely on that makes the DMARC better, and more
secure.

And as every DMARC evaluator needs to support DKIM anyways (there is
no such thing as SPF only DMARC evaluator, both SPF and DKIM are
mandatory to implement), there is no real difference in complexity for
evaluators.

> Seems like a slam dunk for SPF neutral.  I said the problem and it's
> solution needs to be laid out in our document because I am one of those
> who did not understand it as a possible strategy
> 
> I think I agree.

This will also change the behavior of the receivers. For example
spamassasin does give more points to SPF_NEUTRAL (around 0.6-0.7) than
SPF_PASS (-0.001) etc. I would assume other similar software also use
SPF results similarly.

The reason why SPF_PASS gives only -0.001 is that it is assumed that
spammers will use their own domain and thus can get SPF records to
match (DMARC, DKIM and SPF are never meant to work against spammers).
-- 
kivi...@iki.fi

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Murray S. Kucherawy]

On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated.  This involves years.  Even then, domain
> owners will never have confidence that the new token support has been
> implemented by all recipient evaluators.
>

At least on its face, this is a big concern.  A domain owner publishing
"auth=dkim" is going to get varying results as some sites update to
software supporting such a tag while others ignore it.  I don't know if the
potential for some benefit is a desirable trade for the potential for some
confusion.

Seems like a slam dunk for SPF neutral.  I said the problem and it's
> solution needs to be laid out in our document because I am one of those who
> did not understand it as a possible strategy
>

I think I agree.

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Mark Alley]

Giving this some more thought from the opposite point of view... the
benefits to an auth=DKIM method in DMARC itself would remove the need for
domain owners to do SPF tinkering for any upgrade mitigation, and shared
mail infrastructure where one could potentially be affected by SPF upgrade
could instead be mitigated by the new tag, but still retain positive SPF
authentication.

So, theoretically, if we look at it that way, there are a couple of
upsides, although obviously there is additional added complexity, and as
Doug surmised, the adaptation of mail filters will take a
significant amount of time before we see any semblance of ubiquitous
adoption.

I'm on the fence currently about the auth= method.

- Mark Alley

On Sun, Oct 29, 2023, 2:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Reporting allows certainty within the limits of the reporting mechanism.
> My inference is that many domains stop at p=none for an extended period or
> forever because the reporting mechanism does not provide that certainty.
>  For my part, I backed away from reject when I received fail-with-reject
> reports from Outlook.com.  These proved to be false results (messages were
> not blocked) but the fear remained.  Since then, domain members have
> started participating with mailing lists, and I have not determined how the
> list handles p=reject participation.  So I am back at none.
>
> More importantly, the SPF neutral gimmick can be applied immediately, with
> confidence that it will be handled as intended by essentially all
> evaluators.
>
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated.  This involves years.  Even then, domain
> owners will never have confidence that the new token support has been
> implemented by all recipient evaluators.
>
> Additionally, we have testimony that the neutral gimmick has been recently
> used on a large scale, to block SPf upgrade attacks, with good results.
>
> Seems like a slam dunk for SPF neutral.  I said the problem and it's
> solution needs to be laid out in our document because I am one of those who
> did not understand it as a possible strategy
>
> Doug
>
> On Sun, Oct 29, 2023, 2:03 PM Richard Clayton 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> In message > f...@mail.gmail.com>, Douglas Foster > m> writes
>>
>> >* auth=DKIMOnly requires that the domain owner have high confidence
>> >  that every message source is applying DKIM signatures.
>>
>> which of course the reporting mechanism allows them to acquire
>>
>> - --
>> richard   Richard Clayton
>>
>> Those who would give up essential Liberty, to purchase a little temporary
>> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>>
>> -BEGIN PGP SIGNATURE-
>> Version: PGPsdk version 1.7.1
>>
>> iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw
>> XWnnTNQEzFoispkq3McuQGgw
>> =PlmH
>> -END PGP SIGNATURE-
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

Reporting allows certainty within the limits of the reporting mechanism.
My inference is that many domains stop at p=none for an extended period or
forever because the reporting mechanism does not provide that certainty.
 For my part, I backed away from reject when I received fail-with-reject
reports from Outlook.com.  These proved to be false results (messages were
not blocked) but the fear remained.  Since then, domain members have
started participating with mailing lists, and I have not determined how the
list handles p=reject participation.  So I am back at none.

More importantly, the SPF neutral gimmick can be applied immediately, with
confidence that it will be handled as intended by essentially all
evaluators.

By contrast, the new tag cannot be effective until DMARCbis is published
and filtering software updated.  This involves years.  Even then, domain
owners will never have confidence that the new token support has been
implemented by all recipient evaluators.

Additionally, we have testimony that the neutral gimmick has been recently
used on a large scale, to block SPf upgrade attacks, with good results.

Seems like a slam dunk for SPF neutral.  I said the problem and it's
solution needs to be laid out in our document because I am one of those who
did not understand it as a possible strategy

Doug

On Sun, Oct 29, 2023, 2:03 PM Richard Clayton 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message  f...@mail.gmail.com>, Douglas Foster  m> writes
>
> >* auth=DKIMOnly requires that the domain owner have high confidence
> >  that every message source is applying DKIM signatures.
>
> which of course the reporting mechanism allows them to acquire
>
> - --
> richard   Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -BEGIN PGP SIGNATURE-
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw
> XWnnTNQEzFoispkq3McuQGgw
> =PlmH
> -END PGP SIGNATURE-
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Douglas Foster  writes

>* auth=DKIMOnly requires that the domain owner have high confidence 
>  that every message source is applying DKIM signatures.

which of course the reporting mechanism allows them to acquire

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw
XWnnTNQEzFoispkq3McuQGgw
=PlmH
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

I have become persuaded to Scott's approach, as long as it is documented
clearly.

For DMARC-enabled evaluators:

   - auth=DKIMOnly requires that the domain owner have high confidence that
   every message source is applying DKIM signatures.
   - ?include=hostingservice only requires knowledge that one particular
   message source has implemented DKIM signatures.

Because certainty can be hard to achieve, the requirement for 100%
participation may be a significant obstacle.   ?include allows the rule to
be applied tactically where needed (on multi-tenant hosting services) and
bypassed elsewhere (when SPF upgrade is not a concern).

For SPF-only evaluators:
I have some experience with four different SPF-only products, and in each
case, when the SPF test is enabled, the disposition is "block on SPF FAIL,
allow on any other result".  Therefore I think the risk is low that a
change from PASS to NEUTRAL will actually cause legitimate messages to be
blocked.

In sum, no expected impact on SPF-only evaluators, and immediate SPF
Upgrade protection for evaluators that are compliant with both SPF and
DMARC specifications.

Doug Foster


On Sun, Oct 29, 2023 at 9:44 AM Richard Clayton 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message  il.com>, Wei Chuang  writes
>
> >I don't think the SPF '?' qualifier approach works because as Richard
> >Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
> >Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
> >
> >A "neutral" result MUST be treated exactly like the "none"  result;
> >the distinction exists only for informational purposes.
>
> Scott pointed out that I had not understood it correctly ... when you
> run a matching sending IP against a "?" mechanism then you get "neutral"
> which you are obliged to treat as "none". But you stop there.
>
> When you run a non-matching sending IP against that same "?" mechanism
> then you get a "fail" so you keep on going to look at all the other
> mechanisms (which also all fail) and eventually (in practice) reach
> "-all" or "~all" at the end of the record.
>
> hence you can still use SPF to filter out the non-starters, but you
> don't get any warm and fuzzy feeling from the pass...
>
> So the SPF publisher they can either publish "?" information or nothing
> at all -- and the _only_ reason for doing the former is to help with an
> initial filtering mechanism at sites that use SPF for that purpose.
>
> >If it happens to work, it's likely an implementation detail not
> >standardized across the ecosystem and may change.
>
> You're right that there's no way of knowing whether the people who are
> currently paying a lot of attention to SPF (and less so to DKIM) are
> going to make poorer decisions when what used to be an SPF pass now
> becomes a "none" result.
>
> Allowing DKIM-only to be specified in DMARC allows people to still
> publish SPF records that yield a pass (thus generating a (possibly
> mistaken) warm and fuzzy feeling in some quarters ...)
>
> >Moreover it will be
> >highly confusing to those outside of those with connection to the
> >knowledgeable few.  That broader community depends on the literal
> >interpretation of the RFC.
>
> That's what still confuses me about the objections to the proposal to
> explicitly allow people to say "DKIM only".
>
> Yes I get that it adds a little bit to the text of the document and
> requires a bit more code to parse the new parameter and hence you can
> object on the basis of "complexity" -- but it does seem simpler to
> understand the stricture "ignore SPF" than grok the necessity to alter
> SPF records to use a complex-to-understand mechanism which may degrade
> some deliverability.
>
> - --
> richard   Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -BEGIN PGP SIGNATURE-
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZT5hO92nQQHFxEViEQIM0gCfU3ZV3bEfi9kAfEFThr+30GJWqFsAoI2z
> xh0KGaaD5mELlRimHgVMwRDu
> =HmrF
> -END PGP SIGNATURE-
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Wei Chuang  writes

>I don't think the SPF '?' qualifier approach works because as Richard
>Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
>Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
>
>A "neutral" result MUST be treated exactly like the "none"  result;
>the distinction exists only for informational purposes.

Scott pointed out that I had not understood it correctly ... when you
run a matching sending IP against a "?" mechanism then you get "neutral"
which you are obliged to treat as "none". But you stop there.

When you run a non-matching sending IP against that same "?" mechanism
then you get a "fail" so you keep on going to look at all the other
mechanisms (which also all fail) and eventually (in practice) reach
"-all" or "~all" at the end of the record.

hence you can still use SPF to filter out the non-starters, but you
don't get any warm and fuzzy feeling from the pass...

So the SPF publisher they can either publish "?" information or nothing
at all -- and the _only_ reason for doing the former is to help with an
initial filtering mechanism at sites that use SPF for that purpose.

>If it happens to work, it's likely an implementation detail not
>standardized across the ecosystem and may change.  

You're right that there's no way of knowing whether the people who are
currently paying a lot of attention to SPF (and less so to DKIM) are
going to make poorer decisions when what used to be an SPF pass now
becomes a "none" result.

Allowing DKIM-only to be specified in DMARC allows people to still
publish SPF records that yield a pass (thus generating a (possibly
mistaken) warm and fuzzy feeling in some quarters ...) 

>Moreover it will be
>highly confusing to those outside of those with connection to the
>knowledgeable few.  That broader community depends on the literal
>interpretation of the RFC.

That's what still confuses me about the objections to the proposal to
explicitly allow people to say "DKIM only".

Yes I get that it adds a little bit to the text of the document and
requires a bit more code to parse the new parameter and hence you can
object on the basis of "complexity" -- but it does seem simpler to
understand the stricture "ignore SPF" than grok the necessity to alter
SPF records to use a complex-to-understand mechanism which may degrade
some deliverability.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT5hO92nQQHFxEViEQIM0gCfU3ZV3bEfi9kAfEFThr+30GJWqFsAoI2z
xh0KGaaD5mELlRimHgVMwRDu
=HmrF
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sat 28/Oct/2023 16:51:27 +0200 Scott Kitterman wrote:

On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely  wrote:


You're the only one strongly opposing the idea, AFAICS, and I still don't know 
why.


As to why, I don't think there's a valid use case and the proponents for this 
haven't really thought it through.  As an example, someone (I don't recall who) 
cited the issue of domain owners that publish SPF, but can't be bothered to set 
up DKIM.  The implication is that this minimum effort domain owner will read 
DMARCbis when it comes out and decide to update their records as a result with 
the new tag.  I don't think that's very realistic.

So who would use this tag then?

It would have to be a domain owner which publishes an SPF record that enables 
spoofing their domain, understands SPF and DMARC well enough to know that is a 
concern for DMARC and yet simultaneously doesn't know how to fix their SPF 
record and does know about this new tag.

I don't think that person exists.  At best this new tag is some kind of 
security theater.



Perhaps your hypothetical domain owner knows how to fix SPF records, but 
/prefers/ to use auth=dkim.  Actually, she has to fix SPF records anyway, for 
DMARC parsers which don't recognize the new tag.


Being a security theater would match the other use of auth=, to purify DMARC by 
eliminating years of mumbo-jumbo SPF advice.  In case that becomes a widespread 
trend, DMARCter could drop SPF for good.




I think this is the only thing we're doing in DMARCbis that will actively 
worsen DMARC.



No, that is t=.  auth= would be backward compatible.


Best
Ale
--


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Mark Alley]

The intended purpose of using it in the referenced scenario is to avoid the
negative connotation of ~ or - on their shared infrastructure mechanism(s)
in SPF evaluation, while also producing a non-pass for SPF to DMARC.

Many receivers use the failure SPF results as additional signals to
spam/junk filtering; if a sender used the latter two (~ or -) instead of
neutral (?), it would only cause more issues.

But as you stated, I agree the handling of the neutral qualifier is most
likely non-standardized across the internet.


- Mark Alley


On Sun, Oct 29, 2023, 1:39 AM Wei Chuang 
wrote:

> I don't think the SPF '?' qualifier approach works because as Richard
> Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
> Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
>
> A "neutral" result MUST be treated exactly like the "none"  result;
> the distinction exists only for informational purposes.
>
> If it happens to work, it's likely an implementation detail not
> standardized across the ecosystem and may change.  Moreover it will be
> highly confusing to those outside of those with connection to the
> knowledgeable few.  That broader community depends on the literal
> interpretation of the RFC.
> -Wei
>
> On Sat, Oct 28, 2023 at 3:58 PM Mark Alley  40tekmarc@dmarc.ietf.org> wrote:
>
>> For the shared provider SPF upgrade example, I think Scott's previously
>> mentioned method of using SPF '?' qualifier on the relevant shared
>> mechanism mitigates the upgrade problem, and ensures only DKIM can provide
>> passing authentication.
>>
>> Thinking back earlier this year to the well-publicized SPF upgrade
>> vulnerability of a certain vendor, many affected senders mitigated it until
>> fixed by the vendor by utilizing the aforementioned neutral ? qualifier
>> method to great effect.
>>
>> Do we really need this when existing protocol methods of mitigating SPF
>> upgrades already exist?
>>
>> This is basically like painting a potato red, and calling it a tomato. It
>> still tastes like a potato.
>>
>> -Mark Alley
>>
>> On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch > 40google@dmarc.ietf.org> wrote:
>>
>>> As to why, I don't think there's a valid use case and the proponents for
 this haven't really thought it through.  As an example, someone (I don't
 recall who) cited the issue of domain owners that publish SPF, but can't be
 bothered to set up DKIM.  The implication is that this minimum effort
 domain owner will read DMARCbis when it comes out and decide to update
 their records as a result with the new tag.  I don't think that's very
 realistic.

 So who would use this tag then?

 It would have to be a domain owner which publishes an SPF record that
 enables spoofing their domain, understands SPF and DMARC well enough to
 know that is a concern for DMARC and yet simultaneously doesn't know how to
 fix their SPF record and does know about this new tag.

 I don't think that person exists.  At best this new tag is some kind of
 security theater.

>>>
>>> Thanks for that clarification! I think I can clear up what the specific
>>> use case is. It's to deal with SPF Upgrade. Assume we have a domain, `
>>> business.com`, that has properly set up SPF and DKIM and uses a shared
>>> provider and so includes the relevant provider IPs in their SPF record.
>>> They have a DMARC p=reject policy. But, unfortunately, the shared provider
>>> they use is vulnerable to SPF upgrade and so there have been successful
>>> upgrades allowing a spammer / phisher to achieve a `business.com` SPF
>>> pass. Notably, this does not allow the spammer to achieve a `
>>> business.com` DKIM pass. Today, this will be a DMARC pass (because of
>>> the SPF), and it is not always so easy for downstream receivers to know
>>> there has been an upgrade.
>>>
>>> Take the above example, and imagine we've added an `auth=dkim` tag
>>> option. `business.com` then adds it to their DMARC record to protect
>>> their domain. Now, when a receiver gets the upgraded message they see it is
>>> a DMARC fail and can reject the message. This protects the `business.com`
>>> domain from impersonation in a way that is not possible today without `
>>> business.com` either removing SPF or leaving their shared provider (the
>>> only ways to "fix their SPF record"), both a much larger change. Does that
>>> make more sense as a legitimate use case?
>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sat 28/Oct/2023 17:28:50 +0200 Scott Kitterman wrote:



We need to add a subsection in Security Consideration, discussing an
example of an include mechanism with a neutral qualifier and its effect on
DMARC outcome; that is, how that avoids spurious authentications.


I disagree.  It's already addressed in RFC 7208 and we have:

11.1.  Authentication Methods

   Security considerations from the authentication methods used by DMARC
   are incorporated here by reference.

It's already covered.


I thought some more about this and maybe we should put something in about
this.



Thank you for your intellectual honesty.



 Maybe something like:

Domains which publish SPF records that include mechanisms which relate to mail
services which do not protect against cross-user forgery (RFC 7208, Section
11.4) are advised to do so only with the '?' qualifier to mitigate the risk
that such spoofed messages will receive a DMARC pass result.



That's a good start.  I think we should add an example showing, say:

"v=spf1 ?include:spf.protection.extra-large-domain.example -all"

It seems to me that people have the false persuasion that qualifiers can only 
be used in the all mechanism.



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sun 29/Oct/2023 07:39:09 +0100 Wei Chuang wrote:
I don't think the SPF '?' qualifier approach works because as Richard 
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for 
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:


 A "neutral" result MUST be treated exactly like the "none"  result;
 the distinction exists only for informational purposes.

If it happens to work, it's likely an implementation detail not 
standardized across the ecosystem and may change.  Moreover it will be 
highly confusing to those outside of those with connection to the 
knowledgeable few.  That broader community depends on the literal 
interpretation of the RFC.



Obviously, using ?include is only meaningful for SPF records ending in -all. 
Some receivers don't reject even when they find -all.  I don't think there are 
receivers that reject when they see ?all or ~all.  So the question is:


Is there a real difference between spf=neutral and spf=pass,
apart from its effect on DMARC?

IOW, why do domains that apply DKIM signatures undergo the effort to set up a 
complicated SPF record ending in ~all, when they could just have set "v=spf1 
~all" and obtain a DMARC pass via DKIM?


Like kitterman.com, tana.it also makes use of the neutral qualifier, but we are 
small senders.  State.gov uses -all but doesn't use the neutral qualifier.  I 
think they want to use the SPF ability to have spoofs rejected, which was SPF 
original goal.  Using the neutral qualifier would work for them too, no?



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Wei Chuang]

I don't think the SPF '?' qualifier approach works because as Richard
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:

A "neutral" result MUST be treated exactly like the "none"  result;
the distinction exists only for informational purposes.

If it happens to work, it's likely an implementation detail not
standardized across the ecosystem and may change.  Moreover it will be
highly confusing to those outside of those with connection to the
knowledgeable few.  That broader community depends on the literal
interpretation of the RFC.
-Wei

On Sat, Oct 28, 2023 at 3:58 PM Mark Alley  wrote:

> For the shared provider SPF upgrade example, I think Scott's previously
> mentioned method of using SPF '?' qualifier on the relevant shared
> mechanism mitigates the upgrade problem, and ensures only DKIM can provide
> passing authentication.
>
> Thinking back earlier this year to the well-publicized SPF upgrade
> vulnerability of a certain vendor, many affected senders mitigated it until
> fixed by the vendor by utilizing the aforementioned neutral ? qualifier
> method to great effect.
>
> Do we really need this when existing protocol methods of mitigating SPF
> upgrades already exist?
>
> This is basically like painting a potato red, and calling it a tomato. It
> still tastes like a potato.
>
> -Mark Alley
>
> On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch  40google@dmarc.ietf.org> wrote:
>
>> As to why, I don't think there's a valid use case and the proponents for
>>> this haven't really thought it through.  As an example, someone (I don't
>>> recall who) cited the issue of domain owners that publish SPF, but can't be
>>> bothered to set up DKIM.  The implication is that this minimum effort
>>> domain owner will read DMARCbis when it comes out and decide to update
>>> their records as a result with the new tag.  I don't think that's very
>>> realistic.
>>>
>>> So who would use this tag then?
>>>
>>> It would have to be a domain owner which publishes an SPF record that
>>> enables spoofing their domain, understands SPF and DMARC well enough to
>>> know that is a concern for DMARC and yet simultaneously doesn't know how to
>>> fix their SPF record and does know about this new tag.
>>>
>>> I don't think that person exists.  At best this new tag is some kind of
>>> security theater.
>>>
>>
>> Thanks for that clarification! I think I can clear up what the specific
>> use case is. It's to deal with SPF Upgrade. Assume we have a domain, `
>> business.com`, that has properly set up SPF and DKIM and uses a shared
>> provider and so includes the relevant provider IPs in their SPF record.
>> They have a DMARC p=reject policy. But, unfortunately, the shared provider
>> they use is vulnerable to SPF upgrade and so there have been successful
>> upgrades allowing a spammer / phisher to achieve a `business.com` SPF
>> pass. Notably, this does not allow the spammer to achieve a `business.com`
>> DKIM pass. Today, this will be a DMARC pass (because of the SPF), and it is
>> not always so easy for downstream receivers to know there has been an
>> upgrade.
>>
>> Take the above example, and imagine we've added an `auth=dkim` tag
>> option. `business.com` then adds it to their DMARC record to protect
>> their domain. Now, when a receiver gets the upgraded message they see it is
>> a DMARC fail and can reject the message. This protects the `business.com`
>> domain from impersonation in a way that is not possible today without `
>> business.com` either removing SPF or leaving their shared provider (the
>> only ways to "fix their SPF record"), both a much larger change. Does that
>> make more sense as a legitimate use case?
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 4:03:30 PM EDT Emanuel Schorsch wrote:
> > As to why, I don't think there's a valid use case and the proponents for
> > this haven't really thought it through.  As an example, someone (I don't
> > recall who) cited the issue of domain owners that publish SPF, but can't
> > be
> > bothered to set up DKIM.  The implication is that this minimum effort
> > domain owner will read DMARCbis when it comes out and decide to update
> > their records as a result with the new tag.  I don't think that's very
> > realistic.
> > 
> > So who would use this tag then?
> > 
> > It would have to be a domain owner which publishes an SPF record that
> > enables spoofing their domain, understands SPF and DMARC well enough to
> > know that is a concern for DMARC and yet simultaneously doesn't know how
> > to
> > fix their SPF record and does know about this new tag.
> > 
> > I don't think that person exists.  At best this new tag is some kind of
> > security theater.
> 
> Thanks for that clarification! I think I can clear up what the specific use
> case is. It's to deal with SPF Upgrade. Assume we have a domain, `
> business.com`, that has properly set up SPF and DKIM and uses a shared
> provider and so includes the relevant provider IPs in their SPF record.
> They have a DMARC p=reject policy. But, unfortunately, the shared provider
> they use is vulnerable to SPF upgrade and so there have been successful
> upgrades allowing a spammer / phisher to achieve a `business.com` SPF pass.
> Notably, this does not allow the spammer to achieve a `business.com` DKIM
> pass. Today, this will be a DMARC pass (because of the SPF), and it is not
> always so easy for downstream receivers to know there has been an upgrade.
> 
> Take the above example, and imagine we've added an `auth=dkim` tag option. `
> business.com` then adds it to their DMARC record to protect their domain.
> Now, when a receiver gets the upgraded message they see it is a DMARC fail
> and can reject the message. This protects the `business.com` domain from
> impersonation in a way that is not possible today without `business.com`
> either removing SPF or leaving their shared provider (the only ways to "fix
> their SPF record"), both a much larger change. Does that make more sense as
> a legitimate use case?

For that to be useful, it needs a domain owner which understand SPF and their 
providers well enough to know they need to include this new tag, but not well 
enough to know they can used a neutral qualifier in their SPF records (as Mark 
Alley just mentioned, there are alternatives other than removing their SPF or 
leaving the provider).  The is precisely the domain owner that I don't believe 
exists (and I think Mark's input supports that there are other ways to solve 
this).

Ultimately, if I domain's reputation suffers because it uses shared 
infrastructure that isn't sufficiently careful to avoid cross-user forgery, I 
think the system is working as designed.  They should either get the provider 
to clean up their act or leave if they want a high reputation.  That's just 
market forces as work, which I think is the best way to solve this.

It may be that what we need to do is add some language about not inferring too 
much from DMARC pass.  Since both DKIM and SPF have upgrade attack risks, I 
think ultimately people are over-reliant on what a DMARC pass means.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Mark Alley]

For the shared provider SPF upgrade example, I think Scott's previously
mentioned method of using SPF '?' qualifier on the relevant shared
mechanism mitigates the upgrade problem, and ensures only DKIM can provide
passing authentication.

Thinking back earlier this year to the well-publicized SPF upgrade
vulnerability of a certain vendor, many affected senders mitigated it until
fixed by the vendor by utilizing the aforementioned neutral ? qualifier
method to great effect.

Do we really need this when existing protocol methods of mitigating SPF
upgrades already exist?

This is basically like painting a potato red, and calling it a tomato. It
still tastes like a potato.

-Mark Alley

On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch  wrote:

> As to why, I don't think there's a valid use case and the proponents for
>> this haven't really thought it through.  As an example, someone (I don't
>> recall who) cited the issue of domain owners that publish SPF, but can't be
>> bothered to set up DKIM.  The implication is that this minimum effort
>> domain owner will read DMARCbis when it comes out and decide to update
>> their records as a result with the new tag.  I don't think that's very
>> realistic.
>>
>> So who would use this tag then?
>>
>> It would have to be a domain owner which publishes an SPF record that
>> enables spoofing their domain, understands SPF and DMARC well enough to
>> know that is a concern for DMARC and yet simultaneously doesn't know how to
>> fix their SPF record and does know about this new tag.
>>
>> I don't think that person exists.  At best this new tag is some kind of
>> security theater.
>>
>
> Thanks for that clarification! I think I can clear up what the specific
> use case is. It's to deal with SPF Upgrade. Assume we have a domain, `
> business.com`, that has properly set up SPF and DKIM and uses a shared
> provider and so includes the relevant provider IPs in their SPF record.
> They have a DMARC p=reject policy. But, unfortunately, the shared provider
> they use is vulnerable to SPF upgrade and so there have been successful
> upgrades allowing a spammer / phisher to achieve a `business.com` SPF
> pass. Notably, this does not allow the spammer to achieve a `business.com`
> DKIM pass. Today, this will be a DMARC pass (because of the SPF), and it is
> not always so easy for downstream receivers to know there has been an
> upgrade.
>
> Take the above example, and imagine we've added an `auth=dkim` tag option.
> `business.com` then adds it to their DMARC record to protect their
> domain. Now, when a receiver gets the upgraded message they see it is a
> DMARC fail and can reject the message. This protects the `business.com`
> domain from impersonation in a way that is not possible today without `
> business.com` either removing SPF or leaving their shared provider (the
> only ways to "fix their SPF record"), both a much larger change. Does that
> make more sense as a legitimate use case?
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Emanuel Schorsch]

>
> As to why, I don't think there's a valid use case and the proponents for
> this haven't really thought it through.  As an example, someone (I don't
> recall who) cited the issue of domain owners that publish SPF, but can't be
> bothered to set up DKIM.  The implication is that this minimum effort
> domain owner will read DMARCbis when it comes out and decide to update
> their records as a result with the new tag.  I don't think that's very
> realistic.
>
> So who would use this tag then?
>
> It would have to be a domain owner which publishes an SPF record that
> enables spoofing their domain, understands SPF and DMARC well enough to
> know that is a concern for DMARC and yet simultaneously doesn't know how to
> fix their SPF record and does know about this new tag.
>
> I don't think that person exists.  At best this new tag is some kind of
> security theater.
>

Thanks for that clarification! I think I can clear up what the specific use
case is. It's to deal with SPF Upgrade. Assume we have a domain, `
business.com`, that has properly set up SPF and DKIM and uses a shared
provider and so includes the relevant provider IPs in their SPF record.
They have a DMARC p=reject policy. But, unfortunately, the shared provider
they use is vulnerable to SPF upgrade and so there have been successful
upgrades allowing a spammer / phisher to achieve a `business.com` SPF pass.
Notably, this does not allow the spammer to achieve a `business.com` DKIM
pass. Today, this will be a DMARC pass (because of the SPF), and it is not
always so easy for downstream receivers to know there has been an upgrade.

Take the above example, and imagine we've added an `auth=dkim` tag option. `
business.com` then adds it to their DMARC record to protect their domain.
Now, when a receiver gets the upgraded message they see it is a DMARC fail
and can reject the message. This protects the `business.com` domain from
impersonation in a way that is not possible today without `business.com`
either removing SPF or leaving their shared provider (the only ways to "fix
their SPF record"), both a much larger change. Does that make more sense as
a legitimate use case?
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Hector Santos]

Fwiiw, Lurker opinion:

I ideally vote to make DMARCBis Experimental Status and begin to explore the 
“required” integration between envelope (5321 only) protocols and payload 
(5322) protocols. Specifically, work on a “proper” DKIM+SPF Policy Modeling 
with 3rd party signature support. 

But realistically, we should finish DMARCBis as is, as Levine desires.  
However, imto, keeping it a Standard Track will increase the ignorance.  I 
don’t see any new gains for current my package implementation.  At best, the 
industry is acknowledging a big integration problem. Domains who can’ get past 
sending mail the large Mall Hosting domains and managed domains DMARC 
processing are learning to relax their policies. 

PS:  I don’t plan any appeal 

—
HLS


> On Oct 28, 2023, at 12:49 PM, Murray S. Kucherawy  wrote:
> 
> On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton  > wrote:
>> Paying attention to the (sometimes inferred) age of a signature is also
>> important for reducing the opportunity for replay, viz: it would be a
>> Good Thing for senders to set appropriately short expire times.
> 
> Why does it have to be inferred sometimes?  Have you found "t=" values to be 
> occasionally inaccurate?
> 
> The DKIM standard advises against using "x=" to combat replay attacks.  We 
> could always update that advice, but we might also want to review why it was 
> put there in the first place.  I remember the reason being a good one.
> 
> I think there's also been discussion around the reliability of "x=" across 
> implementations.  Since it's not mandatory to support, it doesn't seem to be 
> very common to produce without the expectation of consumers.
> 
> -MSK, participating
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Murray S. Kucherawy]

On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton 
wrote:

> Paying attention to the (sometimes inferred) age of a signature is also
> important for reducing the opportunity for replay, viz: it would be a
> Good Thing for senders to set appropriately short expire times.
>

Why does it have to be inferred sometimes?  Have you found "t=" values to
be occasionally inaccurate?

The DKIM standard advises against using "x=" to combat replay attacks.  We
could always update that advice, but we might also want to review why it
was put there in the first place.  I remember the reason being a good one.

I think there's also been discussion around the reliability of "x=" across
implementations.  Since it's not mandatory to support, it doesn't seem to
be very common to produce without the expectation of consumers.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 11:26:40 AM EDT Richard Clayton wrote:
> In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
>  writes
> 
> >What's your plan for when easily getting a DMARC pass due to bad SPF
> >records doesn't work anymore, so the bad guys focus more on DKIM replay?
> 
> At $DAYJOB$, DKIM replay is simply not an issue any more ... caching
> DKIM values and blocking more than N emails with the same value (whilst
> of course exempting mailing lists) has proved extremely effective for
> several years now.
> 
> Paying attention to the (sometimes inferred) age of a signature is also
> important for reducing the opportunity for replay, viz: it would be a
> Good Thing for senders to set appropriately short expire times.

I guess that works as long as N - 1 spoofed DMARC pass results is OK.  I think 
not everyone has been so fortunate.  I expect it will get more focus if cross-
user forgery for SPF stops working as well.

Scott K




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 10:51:27 AM EDT Scott Kitterman wrote:
> >Even if we don't add the feature, we should address the vulnerability. 
Currently there is only a bullet in Section 4.8, Organizational Domain 
Discovery, saying:
> > * The domain found in the RFC5321.MailFrom header if there is an SPF
> > pass result for the message being evaluated.
> >
> >We need to add a subsection in Security Consideration, discussing an
> >example of an include mechanism with a neutral qualifier and its effect on
> >DMARC outcome; that is, how that avoids spurious authentications.
> >
> >The other snippet where SPF qualifiers are discussed is Section 8.1, Issues
> >Specific to SPF.  We could add a reference to the added subsection there.
> I disagree.  It's already addressed in RFC 7208 and we have:
> 
> 11.1.  Authentication Methods
> 
>Security considerations from the authentication methods used by DMARC
>are incorporated here by reference.
> 
> It's already covered.

I thought some more about this and maybe we should put something in about 
this.  Maybe something like:

Domains which publish SPF records that include mechanisms which relate to mail 
services which do not protect against cross-user forgery (RFC 7208, Section 
11.4) are advised to do so only with the '?' qualifier to mitigate the risk 
that such spoofed messages will receive a DMARC pass result.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
 writes

>What's your plan for when easily getting a DMARC pass due to bad SPF records 
>doesn't work anymore, so the bad guys focus more on DKIM replay?

At $DAYJOB$, DKIM replay is simply not an issue any more ... caching
DKIM values and blocking more than N emails with the same value (whilst
of course exempting mailing lists) has proved extremely effective for
several years now.

Paying attention to the (sometimes inferred) age of a signature is also
important for reducing the opportunity for replay, viz: it would be a
Good Thing for senders to set appropriately short expire times.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT0oMN2nQQHFxEViEQLj2wCg9sCc40wN2UuXY4/Ms7TuMtt/QlAAn1/V
kAUjrpkVAoDkoMlPbVsn1I4X
=tMcf
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote:
> In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
> Vesely  writes
> 
> >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
> >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  
wrote:
> >>>If we add the feature, we should in any case exemplify how to fix SPF,
> >>>saying>
> >that doing so is safer, at least until all DMARC software has acquired the
> >new feature.  As the addition would be understood as a response to the
> >known vulnerability, it will likely be spread.
> >
> >> What do we know now that we didn't know the last time we decided not to
> >> go
> >
> >DKIM only?  I'd argue there's nothing and endless relitigation of issues
> >like this is making it impossible to actually accomplish what we're
> >chartered to accomplish.
> >
> >You're the only one strongly opposing the idea, AFAICS, and I still don't
> >know why.
> 
> The only reason that I think that SPF results are of any value at all
> (and hence we should go with a "DKIM pass only" marker for those who
> need it, rather than just wiping SPF from the document) is because some
> people have argued that a SPF only approach is of value to them -- they
> can do a sanity check on the sending IP, and they then use other methods
> to decide whether they like the email. Their server their choice...
> 
> ... Scott has been arguing (AIUI) that people who want a DKIM only
> situation should add the "?" qualifier to relevant SPF mechanisms. This
> will produce a "neutral" result and hence there will not be a SPF pass
> for DMARC to consider.
> 
> This is all very well, but I have been reading RFC7208 "Sender Policy
> Framework (SPF) for Authorizing Use of Domains in Email, Version 1"
> (which we should note is authored by S Kitterman) and in particular
> looking at #8.2 which says:
> 
> A "neutral" result MUST be treated exactly like the "none"  result;
> the distinction exists only for informational purposes.
> 
> that is (and Scott can correct me if I misunderstand), that people using
> SPF in an RFC compliant manner (which the libraries they use will
> undoubtedly do) are effectively obliged to ignore any mechanism with a
> "?" qualifier.  BTW the same text appears in RFC4408 #2.5.2. so this has
> always been the case.
> 
> That is -- using "?" means that the SPF information will not only be
> disregarded for DMARC purposes but also for SPF purposes as well.
> 
> In my view that makes promoting the use of "?" a non-starter. So if we
> want to allow the people who value SPF to continue to have records they
> can use whilst addressing the reality that such records are often,
> necessarily, far too wide to provide real authentication, we must have a
> way in DMARC of saying "only consider DKIM".

It's not "ignore the mechanism", it's "stop processing and the result in 
Neutral".

The idea behind this is that if you get a match from a mechanism with the '?' 
qualifier processing stops, so you never get to the end of the record.  As a 
result messages from that particular source don't reach the final 'all' 
mechanism.  It's not some kind of global thing, it's just for that source.  
This isn't a novel concept.  I've used it in the SPF record for kitterman.com 
for as long as I can remember for two relays I might, in theory, use, but I 
have no idea how they handle cross-user forgery risks.

What's your plan for when easily getting a DMARC pass due to bad SPF records 
doesn't work anymore, so the bad guys focus more on DKIM replay?  DMARC 
without DKIM as a solution?

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely  wrote:
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
 
 If there isn't a consensus to do a DKIM-only feature, which seems to be 
 the case, I agree, wrap up the few minor editorial issues and we're done.
>>> 
>>> If we add the feature, we should in any case exemplify how to fix SPF, 
>>> saying that doing so is safer, at least until all DMARC software has 
>>> acquired the new feature.  As the addition would be understood as a 
>>> response to the known vulnerability, it will likely be spread.
>>> 
>>> As many of us consider it cleaner to have DMARC based on DKIM only, having 
>>> that possibility as an option is a first step in that direction anyway.  
>>> The thesis that DKIM is enough has been opposed but the only cases where 
>>> SPF saves the day seem to be software bugs.  The DKIM-only feature would 
>>> allow to probe that thesis, which fixing SPF records would not.
>> 
>> What do we know now that we didn't know the last time we decided not to go 
>> DKIM only?  I'd argue there's nothing and endless relitigation of issues 
>> like this is making it impossible to actually accomplish what we're 
>> chartered to accomplish.
>
>
>You're the only one strongly opposing the idea, AFAICS, and I still don't know 
>why.
>
Okay.  It sounded to me like you were pushing to reopen the debate about 
dropping SPF.

>> Let's either focus and finish or give up and close the group.
>
>
>Even if we don't add the feature, we should address the vulnerability. 
>Currently there is only a bullet in Section 4.8, Organizational Domain 
>Discovery, saying:
>
>* The domain found in the RFC5321.MailFrom header if there is an SPF
>  pass result for the message being evaluated.
>
>We need to add a subsection in Security Consideration, discussing an example 
>of an include mechanism with a neutral qualifier and its effect on DMARC 
>outcome; that is, how that avoids spurious authentications.
>
>The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
>Specific to SPF.  We could add a reference to the added subsection there.
>
I disagree.  It's already addressed in RFC 7208 and we have:

11.1.  Authentication Methods

   Security considerations from the authentication methods used by DMARC
   are incorporated here by reference.

It's already covered.

As to why, I don't think there's a valid use case and the proponents for this 
haven't really thought it through.  As an example, someone (I don't recall who) 
cited the issue of domain owners that publish SPF, but can't be bothered to set 
up DKIM.  The implication is that this minimum effort domain owner will read 
DMARCbis when it comes out and decide to update their records as a result with 
the new tag.  I don't think that's very realistic.

So who would use this tag then?

It would have to be a domain owner which publishes an SPF record that enables 
spoofing their domain, understands SPF and DMARC well enough to know that is a 
concern for DMARC and yet simultaneously doesn't know how to fix their SPF 
record and does know about this new tag.

I don't think that person exists.  At best this new tag is some kind of 
security theater.

So far, I don't think anyone has really said where this analysis is wrong.  
IETF consensus isn't about numbers.  It's about addressing issues raised by 
those in the rough and moving towards something we can all live with.

I think this is the only thing we're doing in DMARCbis that will actively 
worsen DMARC.  I'd like to either not include it or understand where I'm wrong.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
Vesely  writes

>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:

>>>If we add the feature, we should in any case exemplify how to fix SPF, 
>>>saying 
>that doing so is safer, at least until all DMARC software has acquired the new 
>feature.  As the addition would be understood as a response to the known 
>vulnerability, it will likely be spread.
>>>
>> What do we know now that we didn't know the last time we decided not to go 
>DKIM only?  I'd argue there's nothing and endless relitigation of issues like 
>this is making it impossible to actually accomplish what we're chartered to 
>accomplish.
>
>You're the only one strongly opposing the idea, AFAICS, and I still don't know 
>why.

The only reason that I think that SPF results are of any value at all
(and hence we should go with a "DKIM pass only" marker for those who
need it, rather than just wiping SPF from the document) is because some
people have argued that a SPF only approach is of value to them -- they
can do a sanity check on the sending IP, and they then use other methods
to decide whether they like the email. Their server their choice...

... Scott has been arguing (AIUI) that people who want a DKIM only
situation should add the "?" qualifier to relevant SPF mechanisms. This
will produce a "neutral" result and hence there will not be a SPF pass
for DMARC to consider.

This is all very well, but I have been reading RFC7208 "Sender Policy
Framework (SPF) for Authorizing Use of Domains in Email, Version 1"
(which we should note is authored by S Kitterman) and in particular
looking at #8.2 which says:

A "neutral" result MUST be treated exactly like the "none"  result;
the distinction exists only for informational purposes.  

that is (and Scott can correct me if I misunderstand), that people using
SPF in an RFC compliant manner (which the libraries they use will
undoubtedly do) are effectively obliged to ignore any mechanism with a
"?" qualifier.  BTW the same text appears in RFC4408 #2.5.2. so this has
always been the case.
 
That is -- using "?" means that the SPF information will not only be
disregarded for DMARC purposes but also for SPF purposes as well.

In my view that makes promoting the use of "?" a non-starter. So if we
want to allow the people who value SPF to continue to have records they
can use whilst addressing the reality that such records are often,
necessarily, far too wide to provide real authentication, we must have a
way in DMARC of saying "only consider DKIM".

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT0fit2nQQHFxEViEQJiVgCg/QCfb5OmzSnGjXMiiTM7sPiepQcAniMF
q/BTNqNrSy8NfpE0xUvnktYF
=AHm6
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:

On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:

On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:


If there isn't a consensus to do a DKIM-only feature, which seems to be the 
case, I agree, wrap up the few minor editorial issues and we're done.


If we add the feature, we should in any case exemplify how to fix SPF, saying 
that doing so is safer, at least until all DMARC software has acquired the new 
feature.  As the addition would be understood as a response to the known 
vulnerability, it will likely be spread.

As many of us consider it cleaner to have DMARC based on DKIM only, having that 
possibility as an option is a first step in that direction anyway.  The thesis 
that DKIM is enough has been opposed but the only cases where SPF saves the day 
seem to be software bugs.  The DKIM-only feature would allow to probe that 
thesis, which fixing SPF records would not.


What do we know now that we didn't know the last time we decided not to go DKIM 
only?  I'd argue there's nothing and endless relitigation of issues like this 
is making it impossible to actually accomplish what we're chartered to 
accomplish.



You're the only one strongly opposing the idea, AFAICS, and I still don't know 
why.



Let's either focus and finish or give up and close the group.



Even if we don't add the feature, we should address the vulnerability. 
Currently there is only a bullet in Section 4.8, Organizational Domain 
Discovery, saying:


* The domain found in the RFC5321.MailFrom header if there is an SPF
  pass result for the message being evaluated.

We need to add a subsection in Security Consideration, discussing an example of 
an include mechanism with a neutral qualifier and its effect on DMARC outcome; 
that is, how that avoids spurious authentications.


The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
Specific to SPF.  We could add a reference to the added subsection there.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:
>On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
>> It appears that Scott Kitterman   said:
 That is unfortunately true, but if we could decouple the DMARC from SPF, 
 then at least we could fix the situation at some point...
>>> 
>>> I propose that we not repeat this discussion and instead, try to focus on 
>>> finishing.
>> 
>> If there isn't a consensus to do a DKIM-only feature, which seems to be the 
>> case, I agree, wrap up the few minor editorial issues and we're done.
>
>
>The two reasons I see against the DKIM-only feature are that it can be fixed 
>in SPF and a generic resistance to complications.
>
>If we add the feature, we should in any case exemplify how to fix SPF, saying 
>that doing so is safer, at least until all DMARC software has acquired the new 
>feature.  As the addition would be understood as a response to the known 
>vulnerability, it will likely be spread.
>
>As many of us consider it cleaner to have DMARC based on DKIM only, having 
>that possibility as an option is a first step in that direction anyway.  The 
>thesis that DKIM is enough has been opposed but the only cases where SPF saves 
>the day seem to be software bugs.  The DKIM-only feature would allow to probe 
>that thesis, which fixing SPF records would not.
>
What do we know now that we didn't know the last time we decided not to go DKIM 
only?  I'd argue there's nothing and endless relitigation of issues like this 
is making it impossible to actually accomplish what we're chartered to 
accomplish.

Let's either focus and finish or give up and close the group.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:

It appears that Scott Kitterman   said:
That is unfortunately true, but if we could decouple the DMARC from 
SPF, then at least we could fix the situation at some point...


I propose that we not repeat this discussion and instead, try to focus on 
finishing.


If there isn't a consensus to do a DKIM-only feature, which seems to be the case, 
I agree, wrap up the few minor editorial issues and we're done.



The two reasons I see against the DKIM-only feature are that it can be fixed in 
SPF and a generic resistance to complications.


If we add the feature, we should in any case exemplify how to fix SPF, saying 
that doing so is safer, at least until all DMARC software has acquired the new 
feature.  As the addition would be understood as a response to the known 
vulnerability, it will likely be spread.


As many of us consider it cleaner to have DMARC based on DKIM only, having that 
possibility as an option is a first step in that direction anyway.  The thesis 
that DKIM is enough has been opposed but the only cases where SPF saves the day 
seem to be software bugs.  The DKIM-only feature would allow to probe that 
thesis, which fixing SPF records would not.



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Wei Chuang]

I  concur with what Doug mentioned.  As someone on the receiving end of bad
press due to an exploit of what I perceive to be weaknesses in the DMARC
standards particularly around depending on SPF [1], and then had to drop
everything to mitigate, I would suggest taking this opportunity to
strengthen DMARCbis.  After all, preventing From header spoofing is the
core of what DMARC is about.  As for why a new tag, I noted in [2], we see
a high degree of overlapping coverage in DKIM and SPF authentication, but
there is a small set of SPF only authentication that likely needs coverage,
and noted that different senders have different From header security needs
e.g. those that use cloud services really should only use DKIM but a very
small sender might not.  As noted, I proposed language [3] for DMARC to
enable this change, and at least on that thread there seemed to be
consensus.
-Wei

[1] There was an attack on BIMI starting on March 31.  An attacker was able
to exploit a large cloud provider that provides mail services for many well
known companies to forward a message with a spoofed From header.   That
message could obtain SPF authentication using the relay's IP SPF, thereby
getting a DMARC pass hence a BIMI pass.  Agreed with the earlier statement
that the fault here doesn't appear to lie with SPF domain owner as they
appeared to have followed reasonable practices.  Rather SPF relies upon IP
which is very often shared between multiple senders.  The Forward Pass
paper documents this very well:
https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf
[2] https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/
I realized that the archived text version of tables there got munged, so
putting the key table back to format for text:
The following categorizes combination of SPF and DKIM authentication of
percentage of traffic that Gmail sees on a given day.  Of this traffic,
DKIM is not passing for 5.56% and of that there's SPF coverage for 4.78%
(86% of DKIM not passing).  A large cause for this is messages that were
not DKIM signed but could be validated with SPF at 3.91% (70% of DKIM not
passing).

ConcatSpfPassDkimAuthResults %
TRUE,PASS92.58%
TRUE,NEUTRAL 3.91%
FALSE,PASS   1.85%
FALSE,NEUTRAL0.72%
TRUE,FAIL0.69%
TRUE,TEMPERROR   0.17%
FALSE,FAIL   0.05%
FALSE,TEMPERROR  0.02%
TRUE,POLICY  0.00%
FALSE,POLICY 0.00%
Grand Total100.00%

[3] Initial "auth" tag proposal
https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
and with comments rolled up
https://mailarchive.ietf.org/arch/msg/dmarc/oqcJoGfBCX0C3Y7yZzCga3k6sTs/

On Thu, Oct 26, 2023 at 5:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Like Ale, I thought the group had agreed to implement an auth=DKIM-only
> option of some type.
>
> I understood the motivation to be false pass created by malicious
> forwarding through a legitimate hosting platform.  Therefore  SPF precision
> is an unrelated issue.
>
> Doug
>
> On Thu, Oct 26, 2023, 5:46 PM Tero Kivinen  wrote:
>
>> John Levine writes:
>> > It appears that Scott Kitterman   said:
>> > >>* Is there consensus on moving ahead with the idea of a way to
>> indicate
>> > >>which authentication method(s) the Domain Owner wants Receivers to
>> use?  If
>> > >>so, it doesn't seem to be in the document yet.
>> > >
>> > >I haven't seen any valid case for it yet.  It adds complexity to
>> > >little or no benefit.
>> >
>> > Normally I am in favor of keeping stuff simple, but I think in this
>> case the
>> > argument for "DKIM only" is quite strong.
>>
>> Actually removing SPF completely from DMARC would simplyfy the
>> protocol a lot, and would solve several issues, where people use DMARC
>> with only SPF, or claim to do dmarc, but do filtering based on the SPF
>> records before getting to the actual email, thus not checking DKIM
>> records at all.
>>
>> If the DMARC would only use DKIM, that would make it clear that if you
>> want to publish DMARC records you needs to also use DKIM, and when
>> checking DMARC records you need to check verify DKIM signatures.
>>
>> Whether you do SPF in addition to that before or after would be local
>> implementation issue, and not part of the DMARC.
>>
>> There were people who wanted to keep SPF as part of the DMARC, who did
>> not even do DMARC, because the used SPF only as a first step of
>> filtering during the MAIL FROM phase (before being able to fetch DMARC
>> records, or checking DKIM signatures)...
>>
>> > There's the counterargument "so don't publish SPF" but it's on so
>> > many checklists that even though that would be a fine idea, it's not
>> > practical.
>>
>> That is unfortunately true, but if we could decouple the DMARC from
>> SPF, then at least we could fix the situation at some point

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Thu, Oct 26, 2023 at 8:25 PM Scott Kitterman 
wrote:

>
>
>
> I propose that we not repeat this discussion and instead, try to focus on
> finishing.
>
> Scott K
>


Agreed.  +1

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[John Levine]

It appears that Scott Kitterman   said:
>>That is unfortunately true, but if we could decouple the DMARC from
>>SPF, then at least we could fix the situation at some point... 
>
>I propose that we not repeat this discussion and instead, try to focus on 
>finishing.

If there isn't a consensus to do a DKIM-only feature, which seems to be the 
case,
I agree, wrap up the few minor editorial issues and we're done.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

Like Ale, I thought the group had agreed to implement an auth=DKIM-only
option of some type.

I understood the motivation to be false pass created by malicious
forwarding through a legitimate hosting platform.  Therefore  SPF precision
is an unrelated issue.

Doug

On Thu, Oct 26, 2023, 5:46 PM Tero Kivinen  wrote:

> John Levine writes:
> > It appears that Scott Kitterman   said:
> > >>* Is there consensus on moving ahead with the idea of a way to indicate
> > >>which authentication method(s) the Domain Owner wants Receivers to
> use?  If
> > >>so, it doesn't seem to be in the document yet.
> > >
> > >I haven't seen any valid case for it yet.  It adds complexity to
> > >little or no benefit.
> >
> > Normally I am in favor of keeping stuff simple, but I think in this case
> the
> > argument for "DKIM only" is quite strong.
>
> Actually removing SPF completely from DMARC would simplyfy the
> protocol a lot, and would solve several issues, where people use DMARC
> with only SPF, or claim to do dmarc, but do filtering based on the SPF
> records before getting to the actual email, thus not checking DKIM
> records at all.
>
> If the DMARC would only use DKIM, that would make it clear that if you
> want to publish DMARC records you needs to also use DKIM, and when
> checking DMARC records you need to check verify DKIM signatures.
>
> Whether you do SPF in addition to that before or after would be local
> implementation issue, and not part of the DMARC.
>
> There were people who wanted to keep SPF as part of the DMARC, who did
> not even do DMARC, because the used SPF only as a first step of
> filtering during the MAIL FROM phase (before being able to fetch DMARC
> records, or checking DKIM signatures)...
>
> > There's the counterargument "so don't publish SPF" but it's on so
> > many checklists that even though that would be a fine idea, it's not
> > practical.
>
> That is unfortunately true, but if we could decouple the DMARC from
> SPF, then at least we could fix the situation at some point...
> --
> kivi...@iki.fi
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 26, 2023 9:46:04 PM UTC, Tero Kivinen  wrote:
>John Levine writes:
>> It appears that Scott Kitterman   said:
>> >>* Is there consensus on moving ahead with the idea of a way to indicate
>> >>which authentication method(s) the Domain Owner wants Receivers to use?  If
>> >>so, it doesn't seem to be in the document yet.
>> >
>> >I haven't seen any valid case for it yet.  It adds complexity to
>> >little or no benefit.  
>> 
>> Normally I am in favor of keeping stuff simple, but I think in this case the
>> argument for "DKIM only" is quite strong.
>
>Actually removing SPF completely from DMARC would simplyfy the
>protocol a lot, and would solve several issues, where people use DMARC
>with only SPF, or claim to do dmarc, but do filtering based on the SPF
>records before getting to the actual email, thus not checking DKIM
>records at all.
>
>If the DMARC would only use DKIM, that would make it clear that if you
>want to publish DMARC records you needs to also use DKIM, and when
>checking DMARC records you need to check verify DKIM signatures.
>
>Whether you do SPF in addition to that before or after would be local
>implementation issue, and not part of the DMARC.
>
>There were people who wanted to keep SPF as part of the DMARC, who did
>not even do DMARC, because the used SPF only as a first step of
>filtering during the MAIL FROM phase (before being able to fetch DMARC
>records, or checking DKIM signatures)...
>
>> There's the counterargument "so don't publish SPF" but it's on so
>> many checklists that even though that would be a fine idea, it's not
>> practical.
>
>That is unfortunately true, but if we could decouple the DMARC from
>SPF, then at least we could fix the situation at some point... 

I propose that we not repeat this discussion and instead, try to focus on 
finishing.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Tero Kivinen]

John Levine writes:
> It appears that Scott Kitterman   said:
> >>* Is there consensus on moving ahead with the idea of a way to indicate
> >>which authentication method(s) the Domain Owner wants Receivers to use?  If
> >>so, it doesn't seem to be in the document yet.
> >
> >I haven't seen any valid case for it yet.  It adds complexity to
> >little or no benefit.  
> 
> Normally I am in favor of keeping stuff simple, but I think in this case the
> argument for "DKIM only" is quite strong.

Actually removing SPF completely from DMARC would simplyfy the
protocol a lot, and would solve several issues, where people use DMARC
with only SPF, or claim to do dmarc, but do filtering based on the SPF
records before getting to the actual email, thus not checking DKIM
records at all.

If the DMARC would only use DKIM, that would make it clear that if you
want to publish DMARC records you needs to also use DKIM, and when
checking DMARC records you need to check verify DKIM signatures.

Whether you do SPF in addition to that before or after would be local
implementation issue, and not part of the DMARC.

There were people who wanted to keep SPF as part of the DMARC, who did
not even do DMARC, because the used SPF only as a first step of
filtering during the MAIL FROM phase (before being able to fetch DMARC
records, or checking DKIM signatures)...

> There's the counterargument "so don't publish SPF" but it's on so
> many checklists that even though that would be a fine idea, it's not
> practical.

That is unfortunately true, but if we could decouple the DMARC from
SPF, then at least we could fix the situation at some point... 
-- 
kivi...@iki.fi

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 16:01:01 +0200 Scott Kitterman wrote:

On October 25, 2023 1:37:55 PM UTC, John Levine  wrote:

It appears that Scott Kitterman   said:


I haven't seen any valid case for it yet.  It adds complexity to little or no benefit. 


[...]

There's the counterargument "so don't publish SPF" but it's on so many 
checklists
that even though that would be a fine idea, it's not practical.


Diving into the SPF angle, if someone has a 'legitimate' mail source that also 
sends spoofed mail for them, they can prefix the relevant mechanism with '?' so 
it produces a neutral rather than a pass result.  DMARC will ignore it then.  
Still solvable in SPF with no protocol change.



For example, change _o365spf.state.gov to

   "v=spf1 ?include:spf.protection.outlook.com -all"

It was a mistake to have a missing qualifier default to +.  Suggesting that the 
qualifier is optional implicitly depreciated the value of "pass".  But yes, 
that fix would work.


It is still possible to provide for an alternative way to fix it.  More 
complication for more flexibility.



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Murray S. Kucherawy]

On Wed, Oct 25, 2023 at 9:33 AM Richard Clayton 
wrote:

> >The operator is making the decision to publish or enforce, not the
> >user.
>
> Looking at $DAYJOB$ logs for this week I see a shade under 300 people
> who are participating in IETF working groups using p=reject addresses.
>
> I believe they have made an informed decision as to what email address
> they will use and have not "blundered" at all (in fact a couple look as
> if they have set up the email address specially in order to participate.
>
> (that was easy to count and it seemed relevant to do so, counting other
> mailing lists is complex)
>
> There are 5 or so in this group...
>
> Surely you are not going to ask them to leave.
>

IETF users are not the source of my concern.  It's the less savvy ones, who
tend to just want what they want and not have to concern themselves with
what they consider to be the operational minutiae of email, that I'm
highlighting here.

Even if you clearly present such information, I have doubts about how many
will read it, much less understand it.

When's the last time any of us actually read a EULA?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Murray S. Kucherawy 
writes

>Do you really want to be pushing that information and decision 
>burden onto users?  How many of them will understand versus 
>ignoring it and just blundering ahead?

I think that depends how clearly the information is presented

>The operator is making the decision to publish or enforce, not the 
>user.

Looking at $DAYJOB$ logs for this week I see a shade under 300 people
who are participating in IETF working groups using p=reject addresses.

I believe they have made an informed decision as to what email address
they will use and have not "blundered" at all (in fact a couple look as
if they have set up the email address specially in order to participate.

(that was easy to count and it seemed relevant to do so, counting other
mailing lists is complex)

There are 5 or so in this group...

Surely you are not going to ask them to leave.

- -- 
richard  Richard Clayton

Those who would give up essential Liberty, to purchase aBenjamin
little temporary Safety, deserve neither Liberty nor Safety.Franklin

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZTlDEd2nQQHFxEViEQLOowCg0paP4kt9wbajuJ4tKO+uY/G6BoYAoJry
+RxYXsHtHSMV+KgNQP87805W
=zUUT
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Murray S. Kucherawy]

On Wed, Oct 25, 2023 at 8:17 AM Richard Clayton 
wrote:

> So might I suggest a wording that captures what will actually happen in
> the real world
>
>   Domains that choose to publish p=reject SHOULD inform the people
>   using those domains of the issues that may arise if theu post to
>   Internet mailing lists.
>
> I'd even live with a MUST for that second sentence :-)
>

-1.

Do you really want to be pushing that information and decision burden onto
users?  How many of them will understand versus ignoring it and just
blundering ahead?

The operator is making the decision to publish or enforce, not the user.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Brotman, Alex  writes

>+1 SHOULD NOT

If there is not going to be a consensus for just a discussion of the
issue (which I would prefer) then my view, obviously is that SHOULD NOT
is to be preferred to MUST NOT

The relevant bit of Barry's text is I believe:

  It is therefore critical that domains that host users who might
  post messages to mailing lists SHOULD NOT publish p=reject.
  Domains that choose to publish p=reject SHOULD implement
  policies that their users not post to Internet mailing lists.

but I am concerned about the second sentence.

It would be perfectly possible at $DAYJOB$ (where I help look after a
number of domains with p=reject and a large number of users) to meet
that SHOULD by blocking those users from sending to mailing lists.  This
would (a) be somewhat unpopular and (b) for many mailing lists which
have implemented workarounds of various kinds completely unnecessary.

So might I suggest a wording that captures what will actually happen in
the real world

  Domains that choose to publish p=reject SHOULD inform the people
  using those domains of the issues that may arise if theu post to
  Internet mailing lists.

I'd even live with a MUST for that second sentence :-)

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZTkxF92nQQHFxEViEQK63QCgyXe3+giXO9UlDA9jAC2T4E6kGeQAn3NC
WoNnAF7y6HrECK9Y1kcdE1nd
=iSip
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote:
> In message , Scott
> Kitterman  writes
> 
> >>> My reading of the discussion is:
> >>> 
> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
> 
> sadly so, it would have been the right thing to do
> 
> >>> 2. We did not have rough consensus to complicate DMARC by having the
> >
> >publishing domain specify authentication methods.
> 
> hmm...  it does seem to be the best way of addressing #1
> 
> >The purported use case is "my SPF is so awful you can't trust it and at the
> >same time, so critical I still have to publish the record".  I don't think
> >that's a real thing.
> 
> there appear to be receivers who use SPF as a filtering mechanism to
> reject patently obvious forgeries -- and if SPF passes they then apply
> other mechanisms because they don't want to bother with DKIM  (I've seen
> posts to this effect -- their customers, their funeral)
> 
> not having an SPF record at all would mean that these receivers would
> not be able to do that filtering (and the lack of SPF might adversely
> affect various heuristics for determining how email should be treated)
> 
> viz: there is an edge case for senders to continue to publish SPF even
> when it almost useless (it stops people forging mail from a different
> cloud, but not from the one that they use)
> 
> if that is so, then senders need to be able to tell all the receivers
> who do believe in the value of DKIM (and there are a lot of those) "take
> no notice of my SPF record" ... so DMARCbis should support that
> 
> Note that if BIMI is involved the SPF will be ignored anyway (and the
> documentation might even say that RSN)
> 
> >If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.
> 
> senders using clouds to spin up and spin down resources depending on
> demand will struggle to "fix it"  ...  that's why it was so widely drawn
> in the first place. Senders using shared IPs at ESPs are also not in a
> position to "fix it" -- they can only hope that the ESP correctly
> polices what is being sent by each particular customer.

Modifying their SPF record to include '?' for the suspect mechanisms is the 
exact technical solution to this problem.  It has no impact on rejecting 
messages that fail SPF and keeps such mail from passing DMARC.

The solution to bad SPF deployments is fixing them.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote:
> > >There's the counterargument "so don't publish SPF" but it's on so many
> > 
> > checklists
> > 
> > >that even though that would be a fine idea, it's not practical.
> > 
> > Diving into the SPF angle, if someone has a 'legitimate' mail source that
> > also sends spoofed mail for them, they can prefix the relevant mechanism
> > with '?' so it produces a neutral rather than a pass result.  DMARC will
> > ignore it then.  Still solvable in SPF with no protocol change.
> > 
> > These sources are effectively open relays (not literally, but
> > practically).  This isn't a problem that should be solved by a protocol
> > change in DMARC.
> 
> I too had thought there was consensus on this issue. I think in this case
> it is appropriate for a protocol change. Senders today do not currently
> have a way to express "ignore my SPF when evaluating DMARC". Adding that to
> the protocol is necessary to give them that choice. We have seen hundreds
> of senders affected by this issue and it is not acceptable for them to turn
> off SPF because there are a variety of receivers out there with varying
> requirements and turning off SPF entirely might have a negative impact. It
> is more than acceptable for them to say: ignore SPF from the perspective of
> DMARC.

And then where's DMARC when the demand comes up to ignore DKIM because of the 
impacts of DKIM replay attacks?

To me this is similar to the multiple suggestions over the years to add an "I 
really mean it" flag to SPF for records that end in -all and it's an equally 
'good' idea.  This is entirely fixable within SPF as the message you are 
replying to describes.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Scott
Kitterman  writes

>>> My reading of the discussion is:
>>> 
>>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.

sadly so, it would have been the right thing to do

>>> 2. We did not have rough consensus to complicate DMARC by having the 
>publishing domain specify authentication methods.

hmm...  it does seem to be the best way of addressing #1

>The purported use case is "my SPF is so awful you can't trust it and at the 
>same 
>time, so critical I still have to publish the record".  I don't think that's a 
>real thing.

there appear to be receivers who use SPF as a filtering mechanism to
reject patently obvious forgeries -- and if SPF passes they then apply
other mechanisms because they don't want to bother with DKIM  (I've seen
posts to this effect -- their customers, their funeral)

not having an SPF record at all would mean that these receivers would
not be able to do that filtering (and the lack of SPF might adversely
affect various heuristics for determining how email should be treated)

viz: there is an edge case for senders to continue to publish SPF even
when it almost useless (it stops people forging mail from a different
cloud, but not from the one that they use)

if that is so, then senders need to be able to tell all the receivers
who do believe in the value of DKIM (and there are a lot of those) "take
no notice of my SPF record" ... so DMARCbis should support that

Note that if BIMI is involved the SPF will be ignored anyway (and the
documentation might even say that RSN) 

>If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.

senders using clouds to spin up and spin down resources depending on
demand will struggle to "fix it"  ...  that's why it was so widely drawn
in the first place. Senders using shared IPs at ESPs are also not in a
position to "fix it" -- they can only hope that the ESP correctly
polices what is being sent by each particular customer.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZTktx92nQQHFxEViEQLZfwCgrWwC2PLCvHV8I9aHLE5XVZLZGTQAnjar
ThGQVjdL/8CrteVWGe3KaNTO
=BqvR
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Emanuel Schorsch]

>
> >There's the counterargument "so don't publish SPF" but it's on so many
> checklists
> >that even though that would be a fine idea, it's not practical.
>
> Diving into the SPF angle, if someone has a 'legitimate' mail source that
> also sends spoofed mail for them, they can prefix the relevant mechanism
> with '?' so it produces a neutral rather than a pass result.  DMARC will
> ignore it then.  Still solvable in SPF with no protocol change.
>
> These sources are effectively open relays (not literally, but
> practically).  This isn't a problem that should be solved by a protocol
> change in DMARC.
>

I too had thought there was consensus on this issue. I think in this case
it is appropriate for a protocol change. Senders today do not currently
have a way to express "ignore my SPF when evaluating DMARC". Adding that to
the protocol is necessary to give them that choice. We have seen hundreds
of senders affected by this issue and it is not acceptable for them to turn
off SPF because there are a variety of receivers out there with varying
requirements and turning off SPF entirely might have a negative impact. It
is more than acceptable for them to say: ignore SPF from the perspective of
DMARC.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 25, 2023 1:37:55 PM UTC, John Levine  wrote:
>It appears that Scott Kitterman   said:
>>>* Is there consensus on moving ahead with the idea of a way to indicate
>>>which authentication method(s) the Domain Owner wants Receivers to use?  If
>>>so, it doesn't seem to be in the document yet.
>>
>>I haven't seen any valid case for it yet.  It adds complexity to little or no 
>>benefit. 
>
>Normally I am in favor of keeping stuff simple, but I think in this case the
>argument for "DKIM only" is quite strong.  People whose opinion I trust tell
>me that so many SPF records include so many large clouds that in practice
>an SPF pass no longer tells you anything useful.
>
>There's the counterargument "so don't publish SPF" but it's on so many 
>checklists
>that even though that would be a fine idea, it's not practical.

Diving into the SPF angle, if someone has a 'legitimate' mail source that also 
sends spoofed mail for them, they can prefix the relevant mechanism with '?' so 
it produces a neutral rather than a pass result.  DMARC will ignore it then.  
Still solvable in SPF with no protocol change.

These sources are effectively open relays (not literally, but practically).  
This isn't a problem that should be solved by a protocol change in DMARC.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[John Levine]

It appears that Scott Kitterman   said:
>>* Is there consensus on moving ahead with the idea of a way to indicate
>>which authentication method(s) the Domain Owner wants Receivers to use?  If
>>so, it doesn't seem to be in the document yet.
>
>I haven't seen any valid case for it yet.  It adds complexity to little or no 
>benefit. 

Normally I am in favor of keeping stuff simple, but I think in this case the
argument for "DKIM only" is quite strong.  People whose opinion I trust tell
me that so many SPF records include so many large clouds that in practice
an SPF pass no longer tells you anything useful.

There's the counterargument "so don't publish SPF" but it's on so many 
checklists
that even though that would be a fine idea, it's not practical.

>>* Given some of the stuff we're hearing in the wings about the utility of
>>ARC, do we want to talk about it in -bis at all? 

>ARC solves nothing on its own.  ARC plus a list of senders I trust not to lie 
>to me is quite useful.  I don't
>think it can be raised to a more formal part of DMARC since its utility if 
>entirely dependent on
>non-standardized (and almost certainly non-standardizable) special sauce.

Agreed.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman 
wrote:

>
>
> On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely 
> wrote:
> >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
>  * Is there consensus on moving ahead with the idea of a way to
> indicate which authentication method(s) the Domain Owner wants Receivers to
> use?  If so, it doesn't seem to be in the document yet.
> >>>
> >>> My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge cases of domains with over-wide SPF policies, since they proved to
> be vulnerable to false DMARC pass.  The WG discussed the possibility to
> also require both methods to limit replay, and concluded that the idea was
> a foot gun.  Hence the WG agreed on the comma syntax.
> >>
> >> My reading of the discussion is:
> >>
> >> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
> >
> >
> >Yes.
> >
> >
> >> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
> >
> >
> >One thread started here:
> >https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
> >
> >It ends up with Wei recapitulating the thread and summarizing the changes
> to the draft.  No objections.  I expected those changes to be carried out.
> >
> >
> >> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
> >
> >
> >I had only seen Scott's reading, which surprised me.  After you and
> Michael hold that no agreement was reached, I begin to doubt of my reading
> myself.
> >
> >In particular, since there is a paper[*] showing how a "spoofed email
> >purporting to be b...@state.gov is delivered to a Gmail user’s inbox
> with no warning indicators", Wei's argument seemed to be fully reasonable.
> >
> >What outstanding objections were there?
>
> The purported use case is "my SPF is so awful you can't trust it and at
> the same time, so critical I still have to publish the record".  I don't
> think that's a real thing.
>
> If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.
>

+1

We need to stop confusing operational/implementation issues on the part of
some with issues that reflect poor logic in a standard.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely  wrote:
>On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
 * Is there consensus on moving ahead with the idea of a way to indicate 
 which authentication method(s) the Domain Owner wants Receivers to use?  
 If so, it doesn't seem to be in the document yet.
>>> 
>>> My recall is that we want to limit DMARC evaluation to DKIM only, for the 
>>> edge cases of domains with over-wide SPF policies, since they proved to be 
>>> vulnerable to false DMARC pass.  The WG discussed the possibility to also 
>>> require both methods to limit replay, and concluded that the idea was a 
>>> foot gun.  Hence the WG agreed on the comma syntax.
>> 
>> My reading of the discussion is:
>> 
>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>
>
>Yes.
>
>
>> 2. We did not have rough consensus to complicate DMARC by having the 
>> publishing domain specify authentication methods.
>
>
>One thread started here:
>https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
>
>It ends up with Wei recapitulating the thread and summarizing the changes to 
>the draft.  No objections.  I expected those changes to be carried out.
>
>
>> Ale, you're saying that my reading on (2) is wrong, yes?  Can you provide 
>> support for that?
>
>
>I had only seen Scott's reading, which surprised me.  After you and Michael 
>hold that no agreement was reached, I begin to doubt of my reading myself.
>
>In particular, since there is a paper[*] showing how a "spoofed email
>purporting to be b...@state.gov is delivered to a Gmail user’s inbox with no 
>warning indicators", Wei's argument seemed to be fully reasonable.
>
>What outstanding objections were there?

The purported use case is "my SPF is so awful you can't trust it and at the 
same time, so critical I still have to publish the record".  I don't think 
that's a real thing.

If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate 
which authentication method(s) the Domain Owner wants Receivers to use?  If 
so, it doesn't seem to be in the document yet.


My recall is that we want to limit DMARC evaluation to DKIM only, for the edge 
cases of domains with over-wide SPF policies, since they proved to be 
vulnerable to false DMARC pass.  The WG discussed the possibility to also 
require both methods to limit replay, and concluded that the idea was a foot 
gun.  Hence the WG agreed on the comma syntax.


My reading of the discussion is:

1. We did not have rough consensus to eliminate the use of SPF in DMARC.



Yes.


2. We did not have rough consensus to complicate DMARC by having the 
publishing domain specify authentication methods.



One thread started here:
https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/

It ends up with Wei recapitulating the thread and summarizing the changes to 
the draft.  No objections.  I expected those changes to be carried out.



Ale, you're saying that my reading on (2) is wrong, yes?  Can you 
provide support for that?



I had only seen Scott's reading, which surprised me.  After you and Michael 
hold that no agreement was reached, I begin to doubt of my reading myself.


In particular, since there is a paper[*] showing how a "spoofed email
purporting to be b...@state.gov is delivered to a Gmail user’s inbox with no 
warning indicators", Wei's argument seemed to be fully reasonable.


What outstanding objections were there?


Best
Ale
--

[*] Enze Liu et al.  "Forward Pass: On the Security Implications of
Email Forwarding Mechanism and Policy", https://arxiv.org/abs/2302.07287




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 7:12 AM Barry Leiba  wrote:

> > > * Is there consensus on moving ahead with the idea of a way to indicate
> > > which authentication method(s) the Domain Owner wants Receivers to
> use?  If
> > > so, it doesn't seem to be in the document yet.
> >
> > My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge
> > cases of domains with over-wide SPF policies, since they proved to be
> > vulnerable to false DMARC pass.  The WG discussed the possibility to also
> > require both methods to limit replay, and concluded that the idea was a
> foot
> > gun.  Hence the WG agreed on the comma syntax.
>
> My reading of the discussion is:
>
> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>

+1


> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
>

+1


> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
>
>
Mi chael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Barry Leiba]

> > * Is there consensus on moving ahead with the idea of a way to indicate
> > which authentication method(s) the Domain Owner wants Receivers to use?  If
> > so, it doesn't seem to be in the document yet.
>
> My recall is that we want to limit DMARC evaluation to DKIM only, for the edge
> cases of domains with over-wide SPF policies, since they proved to be
> vulnerable to false DMARC pass.  The WG discussed the possibility to also
> require both methods to limit replay, and concluded that the idea was a foot
> gun.  Hence the WG agreed on the comma syntax.

My reading of the discussion is:

1. We did not have rough consensus to eliminate the use of SPF in DMARC.

2. We did not have rough consensus to complicate DMARC by having the
publishing domain specify authentication methods.

Ale, you're saying that my reading on (2) is wrong, yes?  Can you
provide support for that?

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 05:38:01 +0200 Murray S. Kucherawy wrote:

On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba  wrote:


2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?


A few questions, but they don't demand in-person time if we want to just 
deal with them on the list:


* Is there consensus on moving ahead with the idea of a way to indicate 
which authentication method(s) the Domain Owner wants Receivers to use?  If 
so, it doesn't seem to be in the document yet.



My recall is that we want to limit DMARC evaluation to DKIM only, for the edge 
cases of domains with over-wide SPF policies, since they proved to be 
vulnerable to false DMARC pass.  The WG discussed the possibility to also 
require both methods to limit replay, and concluded that the idea was a foot 
gun.  Hence the WG agreed on the comma syntax.



* Given some of the stuff we're hearing in the wings about the utility of 
ARC, do we want to talk about it in -bis at all?  The original plan (I 
thought) was that if it turned out to be high signal, we could add it as a 
third supported method.  I'm hearing positive value from a couple of 
operators, but nothing of the form "Yes, this solves the DMARC problem with 
lists."



ARC was barely specified.  A protocol to regulate in which cases it overrides 
DMARC was not specified.  A reporting mechanism was not specified.  These 
issues belong to the charter and I hope the WG will tackle them, after DMARCbis 
last call.  To merge an ARC applicability statement into DMARCbis would distort 
it into an experimental thing, thereby failing to standardize it.



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Tue 24/Oct/2023 20:15:22 +0200 Barry Leiba wrote:


2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?



IMHO this one.


Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Alessandro Vesely]

On Tue 24/Oct/2023 15:20:02 +0200 Baptiste Carvello wrote:

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 mailing lists SHOULD NOT publish p=reject. Domains
  that choose to publish p=reject SHOULD implement policies that
  their users not post to Internet mailing lists.

The exceptions to the latter SHOULD are rather obvious.  Do we really need to 
formally specify domain policing?


I for one would be interested in hearing what you believe those exceptions are. 
When reading your aggressive next paragraph, I'm lead to think that in your 
view, "technologies dating from the 80s deserve no respect" is reason enough to 
break both SHOULDs.



I absolutely didn't mean to be disrespectful.  I'm sorry that interpretation 
came up.  What I wanted to say is that our persistent attention toward this 
topic is probably not met by average readers, and any outcome will likely be 
unattended.  IOW, I perceive our continuing this discussion as a waste of time, 
not because I don't respect the value of interoperability, but because the 
discussion doesn't seem to be productive.  Getting back to addressing the 
issues with indirect mail flows, for example, would be more fruitful than 
philosophizing on who is permitted to use DMARC.


As for domain policing exceptions, let me mention internal mailing lists which 
can manage to be fully interoperable notwithstanding DMARC.  I also believe 
that it is possible to automate per-user whitelisting of all forwarded traffic, 
relying on ARC, so as to avoid the much abhorred From: munging.  Domains within 
such an environment can certainly deploy p=reject without worries.  In general, 
people should balance interoperation needs and security requirements.



There may be rough consensus for a good faith SHOULD, but definitely not for 
overt disrespect of interoperability in the name of some brave new "today's 
reality".



If there is rough consensus, we can just move on, without further polishing 
Section 8.6.  There is no disrespect, just clearance.



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

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) further?
>>
>> ...or...
>>
>> 2. Do we have what we need to finish up the DMARCbis document, and
>> should the chairs cancel the session at 118?
>>
>
>A few questions, but they don't demand in-person time if we want to just
>deal with them on the list:
>
>* Is there consensus on moving ahead with the idea of a way to indicate
>which authentication method(s) the Domain Owner wants Receivers to use?  If
>so, it doesn't seem to be in the document yet.

I haven't seen any valid case for it yet.  It adds complexity to little or no 
benefit.  Although sometimes it seems like complexity for complexities' sake is 
the IETF's stoke and trade, I believe we ought to try and avoid adding any more 
than we have to in order to meet our chartered mandate.


>* Given some of the stuff we're hearing in the wings about the utility of
>ARC, do we want to talk about it in -bis at all?  The original plan (I
>thought) was that if it turned out to be high signal, we could add it as a
>third supported method.  I'm hearing positive value from a couple of
>operators, but nothing of the form "Yes, this solves the DMARC problem with
>lists."

ARC solves nothing on its own.  ARC plus a list of senders I trust not to lie 
to me is quite useful.  I don't think it can be raised to a more formal part of 
DMARC since its utility if entirely dependent on non-standardized (and almost 
certainly non-standardizable) special sauce.


>* Any open issues in the tracker that would benefit from face time?
>
>I'm happy to repeat my 117 rant at 118.  I don't think much has changed
>since then, which makes some of those points more urgent... ;-)
>
>-MSK, participating

I don't think a meeting would help with either of those.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Murray S. Kucherawy]

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 DMARCbis document, and
> should the chairs cancel the session at 118?
>

A few questions, but they don't demand in-person time if we want to just
deal with them on the list:

* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use?  If
so, it doesn't seem to be in the document yet.

* Given some of the stuff we're hearing in the wings about the utility of
ARC, do we want to talk about it in -bis at all?  The original plan (I
thought) was that if it turned out to be high signal, we could add it as a
third supported method.  I'm hearing positive value from a couple of
operators, but nothing of the form "Yes, this solves the DMARC problem with
lists."

* Any open issues in the tracker that would benefit from face time?

I'm happy to repeat my 117 rant at 118.  I don't think much has changed
since then, which makes some of those points more urgent... ;-)

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Hector Santos]

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
should the chairs cancel the session at 118?


I think #2  is best, imto.DMARC and DMARCbis will remain a processing 
overhead for logging, but no honoring of policies. I have yet to see 
any consistency. No faith in this protocol. It can not be considered a 
deterministic protocol. With all the debate on lookup, I still don't 
understand what is expected. Would be nice to see some simple pseudo 
code for the new logic. But why? Nothing deterministic about it to say 
- REJECT with confidence.


SPF is still king here though .


Oh, and...

3. Is there something else (such as the reporting documents) that we
should use the time at 118 to discuss?  Or can we continue with those
on the mailing list for now?  My sense is that aggregate reporting, at
least, is just about ready to go and doesn't need the face-to-face
time.


Primary technical problem is inconsistency in reading the report formats.

I want to know the following in a report:

Which domain? Who try to use it?  What was return path, the IP and 
principle DKIM identities, if you got that far?


I still won't know what I will gain but I do hope the receivers honor 
my policies especially for SPF because I am honoring SPF rejects on 
the receiver side.


SPF remains the only protocol I honor 100% and according to my 
business site sites, this month total rejects are 34% SPF!


If anything, I get DMARC reports but I learn nothing from them.

--
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Brotman, Alex]

+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 forward

+1 for SHOULD NOT.
On Tue, Oct 24, 2023, 12:14 PM Matt V 
mailto:40emailkarma@dmarc.ietf.org>>
 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 
mailto:dotz...@gmail.com>> 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" 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 issues resulting from deviating from the normative 
"SHOULD NOT" deserve a fuller discussion in a separate document.

Much of the discussion has been focused on the impact to mailing lists but the 
impacts can involve a wider range of issues depending on the nature of the 
domain/organization and users involved. A discussion of those wider impacts in 
the context of a "SHOULD NOT" would be useful in educating domain owners, 
administrators and (even) users. There are differences in control and impacts 
between a corporate/organizational domain, government domains, domains which 
offer free or paid accounts to the public and personal domains for example. 
Advice to one of these groupings may not reasonably address the concerns and 
impacts for domains or constituencies in other groupings.
Michael Hammer


On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
I have been asked by Murray to assist with a consensus evaluation on the 
discussion that has been going on for a while about the dmarcbis document and 
how to move forward.

I have made an attempt to evaluate consensus on the topic, trying to look at it 
from a complete outsider’s point of view and trying not to let my personal 
opinion bias my assessment. This is a summary of that evaluation. It is based 
on several threads in the mailing list: [1], [2], [3] and recordings of the 
IETF 117 wg meeting [4]. I also tried to pay attention to chronology of 
comments, because some people have expressed different support for different 
proposals, in which case I consider the latest email I can find as the person’s 
latest opinion.
Although that was mentioned, I believe there is no consensus to move the 
document status to Informational. I believe there is a rough consensus that a 
change needs to be made in the text to include stronger requirements 
admonishing operators against deploying DMARC in a way that causes disruption. 
The mails go in many directions, but the most contentious point I could 
identify is if there ought to be some normative MUST NOT or SHOULD NOT text. 
Many people have suggested text (thank you!). I believe the ones with more 
tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal 
[3]. I believe most people who’d prefer just descriptive text have stated that 
they can live with the SHOULD NOT text, but they have stronger objections 
towards the MUST NOT text. There also a number of people who strongly believe 
MUST NOT is the way to go, but these people have not objected strongly to 
Barry’s latest proposed text in the mailing list (although they have made their 
preference clear during the meeting [4]). As a consequence, I believe there is 
a stronger (very rough) consensus for going with Barry’s SHOULD NOT text. I 
also believe there is consensus to add some non-normative explanatory text (be 
it in the interoperability or security consideration sections, or both) around 
it.
I suggest the authors and the working group start with Berry’s text and 
fine-tune the details around it.
In particular, as another AD that might have to ballot on this document, I 
suggest that you pay particular attention to the text around the SHOULD NOT, as 
also Murray suggested in [5]. I have often blocked documents with the following 
text: “If SHOULD is used, then it must be accompanied by at least one of: (1) A 
general description of the character of the exceptions and/or in what areas 
exceptions are likely to arise.  Examples are fine but, except in plausible and 
rare cases, not enumerated lists. (2) A statement about what should be done, or 
what the considerations are, if the "SHOULD" requirement is not met. (3) A 
statement about why it is not a MUST.”.
I appreciate everybody’s patience and constructive discussion.
Francesca, ART AD
[1]: 
https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch

[dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Barry Leiba]

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, and...

3. Is there something else (such as the reporting documents) that we
should use the time at 118 to discuss?  Or can we continue with those
on the mailing list for now?  My sense is that aggregate reporting, at
least, is just about ready to go and doesn't need the face-to-face
time.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Mark Alley]

+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 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 issues resulting from deviating from the normative
>> "SHOULD NOT" deserve a fuller discussion in a separate document.
>>
>> Much of the discussion has been focused on the impact to mailing lists
>> but the impacts can involve a wider range of issues depending on the nature
>> of the domain/organization and users involved. A discussion of those wider
>> impacts in the context of a "SHOULD NOT" would be useful in educating
>> domain owners, administrators and (even) users. There are differences in
>> control and impacts between a corporate/organizational domain, government
>> domains, domains which offer free or paid accounts to the public and
>> personal domains for example. Advice to one of these groupings may not
>> reasonably address the concerns and impacts for domains or constituencies
>> in other groupings.
>>
>> Michael Hammer
>>
>>
>> On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini > 40ericsson@dmarc.ietf.org> wrote:
>>
>>> I have been asked by Murray to assist with a consensus evaluation on
>>> the discussion that has been going on for a while about the dmarcbis
>>> document and how to move forward.
>>>
>>>
>>>
>>> I have made an attempt to evaluate consensus on the topic, trying to
>>> look at it from a complete outsider’s point of view and trying not to let
>>> my personal opinion bias my assessment. This is a summary of that
>>> evaluation. It is based on several threads in the mailing list: [1], [2],
>>> [3] and recordings of the IETF 117 wg meeting [4]. I also tried to pay
>>> attention to chronology of comments, because some people have expressed
>>> different support for different proposals, in which case I consider the
>>> latest email I can find as the person’s latest opinion.
>>>
>>> Although that was mentioned, I believe there is no consensus to move the
>>> document status to Informational. I believe there is a rough consensus that
>>> a change needs to be made in the text to include stronger requirements
>>> admonishing operators against deploying DMARC in a way that causes
>>> disruption. The mails go in many directions, but the most contentious point
>>> I could identify is if there ought to be some normative MUST NOT or SHOULD
>>> NOT text. Many people have suggested text (thank you!). I believe the ones
>>> with more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD
>>> NOT proposal [3]. I believe most people who’d prefer just descriptive text
>>> have stated that they can live with the SHOULD NOT text, but they have
>>> stronger objections towards the MUST NOT text. There also a number of
>>> people who strongly believe MUST NOT is the way to go, but these people
>>> have not objected strongly to Barry’s latest proposed text in the mailing
>>> list (although they have made their preference clear during the meeting
>>> [4]). As a consequence, I believe there is a stronger (very rough)
>>> consensus for going with Barry’s SHOULD NOT text. I also believe there is
>>> consensus to add some non-normative explanatory text (be it in the
>>> interoperability or security consideration sections, or both) around it.
>>>
>>> I suggest the authors and the working group start with Berry’s text and
>>> fine-tune the details around it.
>>>
>>> In particular, as another AD that might have to ballot on this document,
>>> I suggest that you pay particular attention to the text around the SHOULD
>>> NOT, as also Murray suggested in [5]. I have often blocked documents with
>>> the following text: “If SHOULD is used, then it must be accompanied by at
>>> least one of: (1) A general description of the character of the exceptions
>>> and/or in what areas exceptions are likely to arise.  Examples are fine
>>> but, except in plausible and rare cases, not enumerated lists. (2) A
>>> statement about what should be done, or what the considerations are, if the
>>> "SHOULD" requirement is not met. (3) A statement about why it is not a
>>> MUST.”.
>>>
>>> I appreciate everybody’s patience and constructive discussion.
>>>
>>> Francesca, ART AD
>>>
>>> [1]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>>>
>>> [2]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>>>
>>> [3]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>>>
>>> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>>>
>>> [5]:
>>> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
>

Re: [dmarc-ietf] Dmarcbis way forward

[Murray S. Kucherawy]

[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 document
> itself but I believe the issues resulting from deviating from the normative
> "SHOULD NOT" deserve a fuller discussion in a separate document.
>

What's the likelihood that a separate document would be consulted if it
existed?

I think I'd prefer to see exposition on this topic in an appendix of the
-bis document.  I'm not convinced the WG has the energy to produce another
Informational just about this, covering the stuff you listed.

I'm also wondering whether documents like RFCs 6377 and 7960 already
sufficiently cover the issues we're talking about here.  I suppose we
haven't discussed the mitigations that are in play already (even though
people don't like them).

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Matt V]

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" 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 issues resulting from deviating from the normative
> "SHOULD NOT" deserve a fuller discussion in a separate document.
>
> Much of the discussion has been focused on the impact to mailing lists but
> the impacts can involve a wider range of issues depending on the nature of
> the domain/organization and users involved. A discussion of those wider
> impacts in the context of a "SHOULD NOT" would be useful in educating
> domain owners, administrators and (even) users. There are differences in
> control and impacts between a corporate/organizational domain, government
> domains, domains which offer free or paid accounts to the public and
> personal domains for example. Advice to one of these groupings may not
> reasonably address the concerns and impacts for domains or constituencies
> in other groupings.
>
> Michael Hammer
>
>
> On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini  40ericsson@dmarc.ietf.org> wrote:
>
>> I have been asked by Murray to assist with a consensus evaluation on the
>> discussion that has been going on for a while about the dmarcbis document
>> and how to move forward.
>>
>>
>>
>> I have made an attempt to evaluate consensus on the topic, trying to look
>> at it from a complete outsider’s point of view and trying not to let my
>> personal opinion bias my assessment. This is a summary of that evaluation.
>> It is based on several threads in the mailing list: [1], [2], [3] and
>> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
>> chronology of comments, because some people have expressed different
>> support for different proposals, in which case I consider the latest
>> email I can find as the person’s latest opinion.
>>
>> Although that was mentioned, I believe there is no consensus to move the
>> document status to Informational. I believe there is a rough consensus that
>> a change needs to be made in the text to include stronger requirements
>> admonishing operators against deploying DMARC in a way that causes
>> disruption. The mails go in many directions, but the most contentious point
>> I could identify is if there ought to be some normative MUST NOT or SHOULD
>> NOT text. Many people have suggested text (thank you!). I believe the ones
>> with more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD
>> NOT proposal [3]. I believe most people who’d prefer just descriptive text
>> have stated that they can live with the SHOULD NOT text, but they have
>> stronger objections towards the MUST NOT text. There also a number of
>> people who strongly believe MUST NOT is the way to go, but these people
>> have not objected strongly to Barry’s latest proposed text in the mailing
>> list (although they have made their preference clear during the meeting
>> [4]). As a consequence, I believe there is a stronger (very rough)
>> consensus for going with Barry’s SHOULD NOT text. I also believe there is
>> consensus to add some non-normative explanatory text (be it in the
>> interoperability or security consideration sections, or both) around it.
>>
>> I suggest the authors and the working group start with Berry’s text and
>> fine-tune the details around it.
>>
>> In particular, as another AD that might have to ballot on this document,
>> I suggest that you pay particular attention to the text around the SHOULD
>> NOT, as also Murray suggested in [5]. I have often blocked documents with
>> the following text: “If SHOULD is used, then it must be accompanied by at
>> least one of: (1) A general description of the character of the exceptions
>> and/or in what areas exceptions are likely to arise.  Examples are fine
>> but, except in plausible and rare cases, not enumerated lists. (2) A
>> statement about what should be done, or what the considerations are, if the
>> "SHOULD" requirement is not met. (3) A statement about why it is not a
>> MUST.”.
>>
>> I appreciate everybody’s patience and constructive discussion.
>>
>> Francesca, ART AD
>>
>> [1]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>>
>> [2]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>>
>> [3]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>>
>> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>>
>> [5]:
>> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> __

Re: [dmarc-ietf] Dmarcbis way forward

[Dotzero]

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 issues resulting from deviating from the normative
"SHOULD NOT" deserve a fuller discussion in a separate document.

Much of the discussion has been focused on the impact to mailing lists but
the impacts can involve a wider range of issues depending on the nature of
the domain/organization and users involved. A discussion of those wider
impacts in the context of a "SHOULD NOT" would be useful in educating
domain owners, administrators and (even) users. There are differences in
control and impacts between a corporate/organizational domain, government
domains, domains which offer free or paid accounts to the public and
personal domains for example. Advice to one of these groupings may not
reasonably address the concerns and impacts for domains or constituencies
in other groupings.

Michael Hammer




On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini  wrote:

> I have been asked by Murray to assist with a consensus evaluation on the
> discussion that has been going on for a while about the dmarcbis document
> and how to move forward.
>
>
>
> I have made an attempt to evaluate consensus on the topic, trying to look
> at it from a complete outsider’s point of view and trying not to let my
> personal opinion bias my assessment. This is a summary of that evaluation.
> It is based on several threads in the mailing list: [1], [2], [3] and
> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
> chronology of comments, because some people have expressed different
> support for different proposals, in which case I consider the latest
> email I can find as the person’s latest opinion.
>
> Although that was mentioned, I believe there is no consensus to move the
> document status to Informational. I believe there is a rough consensus that
> a change needs to be made in the text to include stronger requirements
> admonishing operators against deploying DMARC in a way that causes
> disruption. The mails go in many directions, but the most contentious point
> I could identify is if there ought to be some normative MUST NOT or SHOULD
> NOT text. Many people have suggested text (thank you!). I believe the ones
> with more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD
> NOT proposal [3]. I believe most people who’d prefer just descriptive text
> have stated that they can live with the SHOULD NOT text, but they have
> stronger objections towards the MUST NOT text. There also a number of
> people who strongly believe MUST NOT is the way to go, but these people
> have not objected strongly to Barry’s latest proposed text in the mailing
> list (although they have made their preference clear during the meeting
> [4]). As a consequence, I believe there is a stronger (very rough)
> consensus for going with Barry’s SHOULD NOT text. I also believe there is
> consensus to add some non-normative explanatory text (be it in the
> interoperability or security consideration sections, or both) around it.
>
> I suggest the authors and the working group start with Berry’s text and
> fine-tune the details around it.
>
> In particular, as another AD that might have to ballot on this document, I
> suggest that you pay particular attention to the text around the SHOULD
> NOT, as also Murray suggested in [5]. I have often blocked documents with
> the following text: “If SHOULD is used, then it must be accompanied by at
> least one of: (1) A general description of the character of the exceptions
> and/or in what areas exceptions are likely to arise.  Examples are fine
> but, except in plausible and rare cases, not enumerated lists. (2) A
> statement about what should be done, or what the considerations are, if the
> "SHOULD" requirement is not met. (3) A statement about why it is not a
> MUST.”.
>
> I appreciate everybody’s patience and constructive discussion.
>
> Francesca, ART AD
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
>
> [2]:
> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
>
> [3]:
> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
>
> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
>
> [5]:
> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Murray S. Kucherawy]

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 technical objections have been addressed.
>

"addressed" doesn't always mean "fixed".  So long as the working group can
claim that it made an informed decision (versus, say, not even
acknowledging a raised issue), we can say it's been addressed.  In this
instance, it's pretty clear (to me, at least) that the working group did
discuss this at length and appears to have reached rough consensus.

Pete Resnick authored RFC 7282 which does a pretty thorough job of laying
out the ethos.  An important point is the distinction between unanimous
assent (which, though nice to have when possible, is not required) and a
broad "I can live with this".

That said, I understand why we're where we are.


+1.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Trent Adams]

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 about intermediary breakage 
“SHOULD NOT” necessarily publish a DMARC “reject” policy without clearly 
understanding the ramifications (as described in the spec and/or addressed by 
ancillary supporting documents).  I believe more tweaking to the text is 
warranted to hit all the right notes, but this is definitely the direction I 
support.

- Trent


From: dmarc  on behalf of Francesca Palombini 

Date: Monday, October 23, 2023 at 2:06 AM
To: "dmarc@ietf.org" 
Cc: "dmarc-cha...@ietf.org" , "art-...@ietf.org" 

Subject: [dmarc-ietf] Dmarcbis way forward

I have been asked by Murray to assist with a consensus evaluation on the 
discussion that has been going on for a while about the dmarcbis document and 
how to move forward. I have made an attempt to evaluate consensus on the topic, 
trying to

I have been asked by Murray to assist with a consensus evaluation on the 
discussion that has been going on for a while about the dmarcbis document and 
how to move forward.

I have made an attempt to evaluate consensus on the topic, trying to look at it 
from a complete outsider’s point of view and trying not to let my personal 
opinion bias my assessment. This is a summary of that evaluation. It is based 
on several threads in the mailing list: [1], [2], [3] and recordings of the 
IETF 117 wg meeting [4]. I also tried to pay attention to chronology of 
comments, because some people have expressed different support for different 
proposals, in which case I consider the latest email I can find as the person’s 
latest opinion.
Although that was mentioned, I believe there is no consensus to move the 
document status to Informational. I believe there is a rough consensus that a 
change needs to be made in the text to include stronger requirements 
admonishing operators against deploying DMARC in a way that causes disruption. 
The mails go in many directions, but the most contentious point I could 
identify is if there ought to be some normative MUST NOT or SHOULD NOT text. 
Many people have suggested text (thank you!). I believe the ones with more 
tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal 
[3]. I believe most people who’d prefer just descriptive text have stated that 
they can live with the SHOULD NOT text, but they have stronger objections 
towards the MUST NOT text. There also a number of people who strongly believe 
MUST NOT is the way to go, but these people have not objected strongly to 
Barry’s latest proposed text in the mailing list (although they have made their 
preference clear during the meeting [4]). As a consequence, I believe there is 
a stronger (very rough) consensus for going with Barry’s SHOULD NOT text. I 
also believe there is consensus to add some non-normative explanatory text (be 
it in the interoperability or security consideration sections, or both) around 
it.
I suggest the authors and the working group start with Berry’s text and 
fine-tune the details around it.
In particular, as another AD that might have to ballot on this document, I 
suggest that you pay particular attention to the text around the SHOULD NOT, as 
also Murray suggested in [5]. I have often blocked documents with the following 
text: “If SHOULD is used, then it must be accompanied by at least one of: (1) A 
general description of the character of the exceptions and/or in what areas 
exceptions are likely to arise.  Examples are fine but, except in plausible and 
rare cases, not enumerated lists. (2) A statement about what should be done, or 
what the considerations are, if the "SHOULD" requirement is not met. (3) A 
statement about why it is not a MUST.”.
I appreciate everybody’s patience and constructive discussion.
Francesca, ART AD
[1]: 
https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/__;!!ORgEfCBsr282Fw!q90cVmFWuQeuQBgnMXUw1ZV5V-QNpax4K_pDKVqvPekqkbHeRVjb5hI8FHspbC7KOyUrUXzi2tkXxeHYogTWn3LkYWQnoV-Y$>
[2]: 
https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/__;!!ORgEfCBsr282Fw!q90cVmFWuQeuQBgnMXUw1ZV5V-QNpax4K_pDKVqvPekqkbHeRVjb5hI8FHspbC7KOyUrUXzi2tkXxeHYogTWn3LkYU4Bf5B1$>
[3]: 
https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/__;!!ORgEfCBsr282Fw!q90cVmFWuQeuQBgnMXUw1ZV5V-QNpax4K_pDKVqvPekqkbHeRVjb5hI8FHspbC7KOyUrUXzi2tkXxeHYogTWn3LkYRvdLUA1$>
[4]: 
https://www.youtube

Re: [dmarc-ietf] Dmarcbis way forward

[Scott Kitterman]

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
>> about it.
>>
>
>Two things to say about that:
>
>(1) This is Francesca's determination of the consensus of this WG.  It is
>not a determination of the consensus of the IETF or anyone else at this
>point, nor has any determination been made about that position as viable
>IETF output (which, I would argue, is for the IESG to decide).
>
>(2) For an appeal to be sustained, you'd need to present evidence that her
>evaluation of WG consensus is in error.  The question here is not whether
>WG consensus aligns with the IETF's mandate.

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 
technical objections have been addressed.

That said, I understand why we're where we are.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Murray S. Kucherawy]

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 determination of the consensus of this WG.  It is
not a determination of the consensus of the IETF or anyone else at this
point, nor has any determination been made about that position as viable
IETF output (which, I would argue, is for the IESG to decide).

(2) For an appeal to be sustained, you'd need to present evidence that her
evaluation of WG consensus is in error.  The question here is not whether
WG consensus aligns with the IETF's mandate.

-MSK, ART AD
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Baptiste Carvello]

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 mailing lists SHOULD NOT publish p=reject. Domains
  that choose to publish p=reject SHOULD implement policies that
  their users not post to Internet mailing lists.

The exceptions to the latter SHOULD are rather obvious.  Do we really 
need to formally specify domain policing?


I for one would be interested in hearing what you believe those 
exceptions are. When reading your aggressive next paragraph, I'm lead to 
think that in your view, "technologies dating from the 80s deserve no 
respect" is reason enough to break both SHOULDs.


There may be rough consensus for a good faith SHOULD, but definitely not 
for overt disrespect of interoperability in the name of some brave new 
"today's reality".


Cheers,
Baptiste

My perception is that Section 8.6 puts the issue in very clear terms.  
It is even overly clearly and thoroughly explained for average readers.  
Only IETF purists longing for email as it was in the 80s consider it 
important to point out how DMARC is unjustly oppressing email 
forwarding, including mailing lists.  The rest of the world just use it 
as needed.  In today's reality, we should just move forward, and devise 
further protocols to fix forwarding after DMARCbis is out.


By contrast, the last paragraph of Section 7.6 contradict this point and 
should be removed.



Best
Ale


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Laura Atkins]

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 language. 

laura 


> On 23 Oct 2023, at 09:03, Francesca Palombini 
>  wrote:
> 
> I have been asked by Murray to assist with a consensus evaluation on the 
> discussion that has been going on for a while about the dmarcbis document and 
> how to move forward.
>  
> I have made an attempt to evaluate consensus on the topic, trying to look at 
> it from a complete outsider’s point of view and trying not to let my personal 
> opinion bias my assessment. This is a summary of that evaluation. It is based 
> on several threads in the mailing list: [1], [2], [3] and recordings of the 
> IETF 117 wg meeting [4]. I also tried to pay attention to chronology of 
> comments, because some people have expressed different support for different 
> proposals, in which case I consider the latest email I can find as the 
> person’s latest opinion.
> Although that was mentioned, I believe there is no consensus to move the 
> document status to Informational. I believe there is a rough consensus that a 
> change needs to be made in the text to include stronger requirements 
> admonishing operators against deploying DMARC in a way that causes 
> disruption. The mails go in many directions, but the most contentious point I 
> could identify is if there ought to be some normative MUST NOT or SHOULD NOT 
> text. Many people have suggested text (thank you!). I believe the ones with 
> more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT 
> proposal [3]. I believe most people who’d prefer just descriptive text have 
> stated that they can live with the SHOULD NOT text, but they have stronger 
> objections towards the MUST NOT text. There also a number of people who 
> strongly believe MUST NOT is the way to go, but these people have not 
> objected strongly to Barry’s latest proposed text in the mailing list 
> (although they have made their preference clear during the meeting [4]). As a 
> consequence, I believe there is a stronger (very rough) consensus for going 
> with Barry’s SHOULD NOT text. I also believe there is consensus to add some 
> non-normative explanatory text (be it in the interoperability or security 
> consideration sections, or both) around it.
> I suggest the authors and the working group start with Berry’s text and 
> fine-tune the details around it.
> In particular, as another AD that might have to ballot on this document, I 
> suggest that you pay particular attention to the text around the SHOULD NOT, 
> as also Murray suggested in [5]. I have often blocked documents with the 
> following text: “If SHOULD is used, then it must be accompanied by at least 
> one of: (1) A general description of the character of the exceptions and/or 
> in what areas exceptions are likely to arise.  Examples are fine but, except 
> in plausible and rare cases, not enumerated lists. (2) A statement about what 
> should be done, or what the considerations are, if the "SHOULD" requirement 
> is not met. (3) A statement about why it is not a MUST.”.
> I appreciate everybody’s patience and constructive discussion.
> Francesca, ART AD
> [1]: https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
> [2]: https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
> [3]: https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
> [5]: https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
> ___
> dmarc mailing list
> dmarc@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
The Delivery Expert

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Delivery hints and commentary: http://wordtothewise.com/blog






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Barry Leiba]

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 given the deployment already the value of publishing the standard with
at least this level of warnings overrides the desire to be more strict,
knowing that such a greater level of strictness won’t be obeyed.

I wish it weren’t so: I wish that major email platforms would value
interoperability over an oddly loose sense of brand protection.  But it is
so, and they don’t.

Barry

On Tue, Oct 24, 2023 at 6:07 AM Scott Kitterman 
wrote:

> On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
> > I have been asked by Murray to assist with a consensus evaluation on the
> > discussion that has been going on for a while about the dmarcbis document
> > and how to move forward.
> >
> > I have made an attempt to evaluate consensus on the topic, trying to
> look at
> > it from a complete outsider’s point of view and trying not to let my
> > personal opinion bias my assessment. This is a summary of that
> evaluation.
> > It is based on several threads in the mailing list: [1], [2], [3] and
> > recordings of the IETF 117 wg meeting [4]. I also tried to pay attention
> to
> > chronology of comments, because some people have expressed different
> > support for different proposals, in which case I consider the latest
> email
> > I can find as the person’s latest opinion. Although that was mentioned, I
> > believe there is no consensus to move the document status to
> Informational.
> > I believe there is a rough consensus that a change needs to be made in
> the
> > text to include stronger requirements admonishing operators against
> > deploying DMARC in a way that causes disruption. The mails go in many
> > directions, but the most contentious point I could identify is if there
> > ought to be some normative MUST NOT or SHOULD NOT text. Many people have
> > suggested text (thank you!). I believe the ones with more tractions are
> > Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3]. I
> > believe most people who’d prefer just descriptive text have stated that
> > they can live with the SHOULD NOT text, but they have stronger objections
> > towards the MUST NOT text. There also a number of people who strongly
> > believe MUST NOT is the way to go, but these people have not objected
> > strongly to Barry’s latest proposed text in the mailing list (although
> they
> > have made their preference clear during the meeting [4]). As a
> consequence,
> > I believe there is a stronger (very rough) consensus for going with
> Barry’s
> > SHOULD NOT text. I also believe there is consensus to add some
> > non-normative explanatory text (be it in the interoperability or security
> > consideration sections, or both) around it. I suggest the authors and the
> > working group start with Berry’s text and fine-tune the details around
> it.
> > In particular, as another AD that might have to ballot on this document,
> I
> > suggest that you pay particular attention to the text around the SHOULD
> > NOT, as also Murray suggested in [5]. I have often blocked documents with
> > the following text: “If SHOULD is used, then it must be accompanied by at
> > least one of: (1) A general description of the character of the
> exceptions
> > and/or in what areas exceptions are likely to arise.  Examples are fine
> > but, except in plausible and rare cases, not enumerated lists. (2) A
> > statement about what should be done, or what the considerations are, if
> the
> > "SHOULD" requirement is not met. (3) A statement about why it is not a
> > MUST.”. I appreciate everybody’s patience and constructive discussion.
> > Francesca, ART AD
> > [1]:
> > https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
> > [2]:
> > https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
> > [3]:
> > https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
> > [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
> > [5]:
> > https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
>
> 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.
>
> Scott K
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Scott Kitterman]

On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
> I have been asked by Murray to assist with a consensus evaluation on the
> discussion that has been going on for a while about the dmarcbis document
> and how to move forward.
> 
> I have made an attempt to evaluate consensus on the topic, trying to look at
> it from a complete outsider’s point of view and trying not to let my
> personal opinion bias my assessment. This is a summary of that evaluation.
> It is based on several threads in the mailing list: [1], [2], [3] and
> recordings of the IETF 117 wg meeting [4]. I also tried to pay attention to
> chronology of comments, because some people have expressed different
> support for different proposals, in which case I consider the latest email
> I can find as the person’s latest opinion. Although that was mentioned, I
> believe there is no consensus to move the document status to Informational.
> I believe there is a rough consensus that a change needs to be made in the
> text to include stronger requirements admonishing operators against
> deploying DMARC in a way that causes disruption. The mails go in many
> directions, but the most contentious point I could identify is if there
> ought to be some normative MUST NOT or SHOULD NOT text. Many people have
> suggested text (thank you!). I believe the ones with more tractions are
> Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal [3]. I
> believe most people who’d prefer just descriptive text have stated that
> they can live with the SHOULD NOT text, but they have stronger objections
> towards the MUST NOT text. There also a number of people who strongly
> believe MUST NOT is the way to go, but these people have not objected
> strongly to Barry’s latest proposed text in the mailing list (although they
> have made their preference clear during the meeting [4]). As a consequence,
> I believe there is a stronger (very rough) consensus for going with Barry’s
> SHOULD NOT text. I also believe there is consensus to add some
> non-normative explanatory text (be it in the interoperability or security
> consideration sections, or both) around it. I suggest the authors and the
> working group start with Berry’s text and fine-tune the details around it.
> In particular, as another AD that might have to ballot on this document, I
> suggest that you pay particular attention to the text around the SHOULD
> NOT, as also Murray suggested in [5]. I have often blocked documents with
> the following text: “If SHOULD is used, then it must be accompanied by at
> least one of: (1) A general description of the character of the exceptions
> and/or in what areas exceptions are likely to arise.  Examples are fine
> but, except in plausible and rare cases, not enumerated lists. (2) A
> statement about what should be done, or what the considerations are, if the
> "SHOULD" requirement is not met. (3) A statement about why it is not a
> MUST.”. I appreciate everybody’s patience and constructive discussion.
> Francesca, ART AD
> [1]:
> https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
> [2]:
> https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
> [3]:
> https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
> [4]: https://www.youtube.com/watch?v=8O28ShKGRAU
> [5]:
> https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/

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.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

[Alessandro Vesely]

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 mailing lists SHOULD NOT publish p=reject. Domains
 that choose to publish p=reject SHOULD implement policies that
 their users not post to Internet mailing lists.

The exceptions to the latter SHOULD are rather obvious.  Do we really need to 
formally specify domain policing?


My perception is that Section 8.6 puts the issue in very clear terms.  It is 
even overly clearly and thoroughly explained for average readers.  Only IETF 
purists longing for email as it was in the 80s consider it important to point 
out how DMARC is unjustly oppressing email forwarding, including mailing lists. 
 The rest of the world just use it as needed.  In today's reality, we should 
just move forward, and devise further protocols to fix forwarding after 
DMARCbis is out.


By contrast, the last paragraph of Section 7.6 contradict this point and should 
be removed.



Best
Ale


On Mon 23/Oct/2023 10:03:36 +0200 Francesca Palombini wrote:
I have been asked by Murray to assist with a consensus evaluation on the 
discussion that has been going on for a while about the dmarcbis document and 
how to move forward.


I have made an attempt to evaluate consensus on the topic, trying to look at it 
from a complete outsider’s point of view and trying not to let my personal 
opinion bias my assessment. This is a summary of that evaluation. It is based 
on several threads in the mailing list: [1], [2], [3] and recordings of the 
IETF 117 wg meeting [4]. I also tried to pay attention to chronology of 
comments, because some people have expressed different support for different 
proposals, in which case I consider the latest email I can find as the person’s 
latest opinion.


Although that was mentioned, I believe there is no consensus to move the 
document status to Informational. I believe there is a rough consensus that a 
change needs to be made in the text to include stronger requirements 
admonishing operators against deploying DMARC in a way that causes disruption. 
The mails go in many directions, but the most contentious point I could 
identify is if there ought to be some normative MUST NOT or SHOULD NOT text. 
Many people have suggested text (thank you!). I believe the ones with more 
tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal 
[3]. I believe most people who’d prefer just descriptive text have stated that 
they can live with the SHOULD NOT text, but they have stronger objections 
towards the MUST NOT text. There also a number of people who strongly believe 
MUST NOT is the way to go, but these people have not objected strongly to 
Barry’s latest proposed text in the mailing list (although they have made their 
preference clear during the meeting [4]). As a consequence, I believe there is 
a stronger (very rough) consensus for going with Barry’s SHOULD NOT text. I 
also believe there is consensus to add some non-normative explanatory text (be 
it in the interoperability or security consideration sections, or both) around it.


I suggest the authors and the working group start with Berry’s text and 
fine-tune the details around it.


In particular, as another AD that might have to ballot on this document, I 
suggest that you pay particular attention to the text around the SHOULD NOT, as 
also Murray suggested in [5]. I have often blocked documents with the following 
text: “If SHOULD is used, then it must be accompanied by at least one of: (1) A 
general description of the character of the exceptions and/or in what areas 
exceptions are likely to arise.  Examples are fine but, except in plausible and 
rare cases, not enumerated lists. (2) A statement about what should be done, or 
what the considerations are, if the "SHOULD" requirement is not met. (3) A 
statement about why it is not a MUST.”.


I appreciate everybody’s patience and constructive discussion.

Francesca, ART AD

[1]: https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/ 



[2]: https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/ 



[3]: https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/ 



[4]: https://www.youtube.com/watch?v=8O28ShKGRAU 



[5]: https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/ 




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


_

[dmarc-ietf] Dmarcbis way forward

[Francesca Palombini]

I have been asked by Murray to assist with a consensus evaluation on the 
discussion that has been going on for a while about the dmarcbis document and 
how to move forward.

I have made an attempt to evaluate consensus on the topic, trying to look at it 
from a complete outsider’s point of view and trying not to let my personal 
opinion bias my assessment. This is a summary of that evaluation. It is based 
on several threads in the mailing list: [1], [2], [3] and recordings of the 
IETF 117 wg meeting [4]. I also tried to pay attention to chronology of 
comments, because some people have expressed different support for different 
proposals, in which case I consider the latest email I can find as the person’s 
latest opinion.
Although that was mentioned, I believe there is no consensus to move the 
document status to Informational. I believe there is a rough consensus that a 
change needs to be made in the text to include stronger requirements 
admonishing operators against deploying DMARC in a way that causes disruption. 
The mails go in many directions, but the most contentious point I could 
identify is if there ought to be some normative MUST NOT or SHOULD NOT text. 
Many people have suggested text (thank you!). I believe the ones with more 
tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal 
[3]. I believe most people who’d prefer just descriptive text have stated that 
they can live with the SHOULD NOT text, but they have stronger objections 
towards the MUST NOT text. There also a number of people who strongly believe 
MUST NOT is the way to go, but these people have not objected strongly to 
Barry’s latest proposed text in the mailing list (although they have made their 
preference clear during the meeting [4]). As a consequence, I believe there is 
a stronger (very rough) consensus for going with Barry’s SHOULD NOT text. I 
also believe there is consensus to add some non-normative explanatory text (be 
it in the interoperability or security consideration sections, or both) around 
it.
I suggest the authors and the working group start with Berry’s text and 
fine-tune the details around it.
In particular, as another AD that might have to ballot on this document, I 
suggest that you pay particular attention to the text around the SHOULD NOT, as 
also Murray suggested in [5]. I have often blocked documents with the following 
text: “If SHOULD is used, then it must be accompanied by at least one of: (1) A 
general description of the character of the exceptions and/or in what areas 
exceptions are likely to arise.  Examples are fine but, except in plausible and 
rare cases, not enumerated lists. (2) A statement about what should be done, or 
what the considerations are, if the "SHOULD" requirement is not met. (3) A 
statement about why it is not a MUST.”.
I appreciate everybody’s patience and constructive discussion.
Francesca, ART AD
[1]: https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/
[2]: https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
[3]: https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
[4]: https://www.youtube.com/watch?v=8O28ShKGRAU
[5]: https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc