[dmarc-ietf] DMARC marketing
This: On 7/21/20 12:29 PM, Joseph Brennan wrote: > > My understanding of DMARC's purpose was to protect transactional > messages from sources like banks, credit card issuers, online shopping > venues, and the like. It supposed that those messages should pass only > directly from the source to the end point, and that that was so > important to security that transport through any intermediary should > be rejected as possible forgery. For example my bank statements come > from a different domain than mail from a person at the bank. and: On 7/21/20 1:17 AM, Laura Atkins wrote: > But I would argue that much of the marketing and justification around > DMARC has been around end users and improving their trust in brands > and protecting them from phishing. > [...] > > That is not how I’ve seen DMARC being sold. Most of the marketing I’ve > seen about DMARC is all about user experience and the user being able > to trust mail is “from who it claims to be from.” And now people are > explicitly layering on another protocol that is all about what the > user sees in the MUA. and also: On 7/20/20 5:31 AM, Dotzero wrote: > You have left out one significant way of convincing receiver domains > and their admins. We used to have our CSRs (customer service) tell > people who received spoof emails (resulting in phishing, malware > compromise, etc.) from emails claiming to be from our domains that > they should contact their mail provider or email admin because the > problem could have been avoided if DMARC were being checked. We would > even provide them with the details and a form with all the information > in non-technical terms. It is amazing how quickly a provider pays > attention when their customers/users are complaining to them that the > provider could have prevented the heartache and grief but chose not > to. Again, this was for domains sending transactional mail with only a > limited number (intentionally) of role and support accounts. These get to the heart of the problem: DMARC policy was designed for official mail that is about business transactions. If that was the way it is actually used, we wouldn't be having this problem. But it was oversold, and it is being used in use cases (like on domains that have mailing list users) that were not intended. I'm not convinced that this is a problem that has a satisfactory technical solution. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On Wed, Jul 22, 2020 at 6:38 PM Jesse Thompson wrote: > On 7/22/20 12:05 PM, John Levine wrote: > > I don't believe we have a charter to tell mailing list operators what > > to do, even if we believed, against all experience, that they would > > take our advice. > > https://cyber.dhs.gov/bod/18-01/ references > https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F > > Who should be giving them advice? > Probably not a technical standards group. > > > > As may have been pointed out a few times, mailing lists had been > > serving their users perfectly well for decades before AOL and Yahoo made > them > > DMARC roadkill. > > Given that the email security industry's marketing now shames domain > owners for not adopting DMARC, I think that the statute of limitations for > AOL and Yahoo has passed. > Despite my personal opinions regarding mailing lists, DMARC and anti-abuse, this working group is not the running dog for the email security industry's marketing efforts to shame domain owners. Perhaps you would like to submit an Internet Draft on how to resist feeling shamed. I have a feeling it would be informational at best. I would also suggest that this group, lacking significant representation of MUA providers, should also refrain from thinking it reasonable that this group should tell MUA providers how they should go about their business. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/22/20 12:05 PM, John Levine wrote: > I don't believe we have a charter to tell mailing list operators what > to do, even if we believed, against all experience, that they would > take our advice. https://cyber.dhs.gov/bod/18-01/ references https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F Who should be giving them advice? > As may have been pointed out a few times, mailing lists had been > serving their users perfectly well for decades before AOL and Yahoo made them > DMARC roadkill. Given that the email security industry's marketing now shames domain owners for not adopting DMARC, I think that the statute of limitations for AOL and Yahoo has passed. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
In article <002201d6602d$8b87dca0$a29795e0$@bayviewphysicians.com> you write: >Since the conflict between DMARC and Mailing Lists is related to the changes >that Mailing List apply >to a received message, it may be useful to review the purposes that each of >those changes serve, with >a goal of eliminating unnecessary changes. I don't believe we have a charter to tell mailing list operators what to do, even if we believed, against all experience, that they would take our advice. As may have been pointed out a few times, mailing lists had been serving their users perfectly well for decades before AOL and Yahoo made them DMARC roadkill. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
Since the conflict between DMARC and Mailing Lists is related to the changes that Mailing List apply to a received message, it may be useful to review the purposes that each of those changes serve, with a goal of eliminating unnecessary changes. Specifically, this list adds a footer to every message. Is the footer a "trust indicator" which serves an imaginary purpose, or a necessary addition for other reasons? If it is added as a trust indicator, perhaps it could be dropped. I would be willing to format my submissions to IETF specifications, if it would protect the integrity of my signature. But IETF has not disclosed a way for that to be done. What I can determine is that the footer addition is currently unconditional, as evidenced by reply messages with multiple copies of the footer, and therefore I cannot prevent my signature from being invalidated. DF -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker Sent: Wednesday, July 22, 2020 9:24 AM To: IETF DMARC WG Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations On 7/21/2020 1:08 AM, Laura Atkins wrote: > When we’re basing a protocol on “what the user sees” and “what the > user can trust” then I think we have to. DMARC says “users can trust > that mail from @domain.example is really from @domain.example” but if > the user never sees that, how do they know? I think this can be connected to the query about threats that DMARC is intended to respond to, by virtue of suggesting clarity about /where/ the responding takes place. My contention is that it takes place in a receiving filtering engine and does not take place at the user level. Further, it's one more data point in that engine's analysis process, rather than being in any simple way definitive. In any event, work here really should make a point of creating text that is clear about threats DMARC is intended to respond to, and clear about where such responding takes place. To the extent any of that text makes assertions about the performance of end users, it needs to cite the basis for the assertions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/21/2020 1:08 AM, Laura Atkins wrote: When we’re basing a protocol on “what the user sees” and “what the user can trust” then I think we have to. DMARC says “users can trust that mail from @domain.example is really from @domain.example” but if the user never sees that, how do they know? I think this can be connected to the query about threats that DMARC is intended to respond to, by virtue of suggesting clarity about /where/ the responding takes place. My contention is that it takes place in a receiving filtering engine and does not take place at the user level. Further, it's one more data point in that engine's analysis process, rather than being in any simple way definitive. In any event, work here really should make a point of creating text that is clear about threats DMARC is intended to respond to, and clear about where such responding takes place. To the extent any of that text makes assertions about the performance of end users, it needs to cite the basis for the assertions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
