Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 19 Jul 2020 08:13:37 -0400

Your comments mply that for non-MLM messages, the only purpose of rfc5322.From is trust.   A related action would be attribution:  after an attack, whom do I blame?  Domain owners do not want to be attributed to someone else's crime.But obviously, there are other purposes, such as searching and sorting.   These also depend on accurate values.   Consequently, spoofing affects multiple  functions which are important to domain owners and message readers.  You asserted again that nearly all MUAs hide the From address, then ignored contrary data.   Gmail and Outlook have significant user bases.   No one has identified the long list of MUAs that hide, or indicated the market share of those MUAs.What has also not been explained is:   why it is an uncoscienable burden for MLMs to use rfc5322.From addresses of the form user=domain@MLM?  Any such attempt is weakened by your assertions that From matters to no one.Any MLM can create their own rules by operating in a dedicated domain which issues domain accounts to its subscribers.  But as long as it chooses to operate in a shared realm, it must accommodate the needs of others within the shared realm.DF<div>
</div><div>
</div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Dave Crocker <[email-masked]> </div><div>Date: 7/18/20  9:32 PM  (GMT-05:00) </div><div>To: "Murray S. Kucherawy" <[email-masked]> </div><div>Cc: IETF DMARC WG <[email-masked]> </div><div>Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations </div><div>
</div>On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
> At some point in the past, Gmail decided to show the email address 
> only unless that address was in the recipient's contact list, or if 
> the recipient had replied to that address previously, or something 
> like that.  In those cases, the RFC5322.From address was trusted, and 
> so the display name was shown.  Is there logic like that still in place?

If end users do not reliably make trust decisions based on /any/ of the 
information in the rfc5322.From field, then how is this question 
important.  It seems to be seeking precise data about something that 
isn't even secondary.

The persistence of thinking that end users are influenced by trust 
indicators is pernicious.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 26 Jul 2020 13:57:31 -0400

Recipient domains determine what messages they will accept or reject.Fairness and precedence are not necessarily applicable.I suggest that the DMARC standards track be placed on hold for at least a year.   It is not clear to me, from this group's membership, that DMARC implementers feel an urgent need for standard status, so a delay should be tolerable to them.A Mailing List Protection WG should be formed to develop his ideas into an informational or experimental RFC.   Then that RFC can be promoted to see if it wins over any current users of DMARC Sent from my Verizon, Samsung Galaxy smartphone<div>
</div><div>
</div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Dave Crocker <[email-masked]> </div><div>Date: 7/26/20  9:50 AM  (GMT-05:00) </div><div>To: Brandon Long <[email-masked]> </div><div>Cc: IETF DMARC WG <[email-masked]>, Dotzero <[email-masked]> </div><div>Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations </div><div>
</div>On 7/21/2020 1:42 PM, Brandon Long wrote:
> Stricter validation is not an uncommon addition to protocols over the 
> last 45 years.

If there are examples of adding stricter validation in a way that 
essentially requires changing the semantics of the payload, in order for 
the payload to survive, I can't think of any. Not TLS, not DNSSec, not 
S/MIME or PGP.

DMARC essentially enforces a semantic on the From: field as a handling 
identifier, rather than an author identifier.

When activity that has a long history of semantic validity and a 
continued desire for operation is forced to break the denotational 
source of authoring information, in order to get the mail delivered, 
then we are in new territory.

d/

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 26 Jul 2020 17:49:13 -0400

The link provided by Laura Atkins on 7/21 is relevant and worth 
reading.Sent from my Verizon, Samsung Galaxy smartphone<div>
</div><div>
</div><!-- originalMessage --><div>-------- Original message 
--------</div><div>From: Dave Crocker <[email-masked]> </div><div>Date: 
7/26/20  2:35 PM  (GMT-05:00) </div><div>To: [email-masked] 
</div><div>Cc: [email-masked] </div><div>Subject: Re: [dmarc-ietf] Response 
to a claim in draft-crocker-dmarc-author-00 security considerations 
</div><div>
</div>On 7/26/2020 11:29 AM, Hector Santos wrote:
> Dave, for a number of years of practice, depending in the system or 
> service, users have been provided with trust-related decisions . Do 
> you need real examples? 

There is a difference between providing a signal, versus its getting 
received and use.

Please provide objective data that these signals are being perceived and 
used effectively by end users.

d/