Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Alessandro Vesely <[e-mail]>]

On Mon 17/Aug/2020 16:00:42 +0200 Laura Atkins wrote:
>> On 17 Aug 2020, at 14:18, Dotzero <[e-mail]> wrote:
>>
>>
>> You raise an interesting point, Laura. Whatever "solutions" we put in place, the abusers/bad guys will evolve. One of the problems for the good guys (for some definition of good) is that standards work takes years (decades?)  while the bad  guys change their tactics at will. Crime existed before the Internet and will continue long after we are all dead and buried.
> 
> Totally agreed. The issue here is that DMARC is a fundamentally flawed model for preventing phishing. Phishers were adapting to mailbox provider filters even before DMARC and there was a lot of cousin and non-look-alike domain phishing even during the initial discussions. I know these issues were brought up during discussion of the protocol. Unfortunately, they weren’t sufficiently addressed and now we’re at a point where, to my mind, DMARC doesn’t fix anything while also breaking a lot of ways folks use mail.
> 
> It’s a little late now to go back.


That's what I meant by being stuck midstream.  Neither forward nor backward...


> I think this is an opportunity to think about the underlying technical problems as well as a chance to revisit the assumptions about how email is used. Discussing things like Dave’s drafts will give us a chance to talk about how people actually use email to communicate with one another. And how we can allow brands what they want without breaking email too much for the rest of us.


We have to fix the defects that cause DMARC collateral damage, if I may so roughly summarize our charter.  We have two ways to do that:

Forward:  Solve each specific problem.  For example, apply dkim-transform to MLM messages.

Backward:  Kill DMARC expansion.  For example, reaffirm that domains which host personal mailboxes must not publish strict policies.


Best
Ale
--