On Mon, Dec 26, 2016 at 11:13:37PM -0500, Viktor Dukhovni wrote: > Right and DMARC has put an end to email phishing, and this progress > is in serious jeopardy of being undone if a bad guy can send an email > > From: Bobby Phisher <rf@notbank.example> on behalf of Joe Banker <joe@bank.example> > > and is at no risk with: > > From: Joe Banker <joe@bank.notbank.example> > > Reminds me of "Yes minister", we've to do *something* about > phishing and DMARC is something... My point was that if Phishing is this unmitigated evil that justifies doing anything, including inflicting pain on mailing lists, and the big mail providers will not be moved, then there are only so many choices available to development groups/organizations which rely on mailing lists. (1) Acquiesce and transition to using bulletin board web fora that don't work when you are reading mail off-line, and require you to periodically remember to go to a particulra web site to catch up on the latest mailing list discussion. (2) Acquiesce and inflict pain on mailing list users: (a) Inflicting the pain on everyone, and give people who know that they are using mail systems that don't conform to DMARC to opt-out of the pain. (b) Require users who know they are using a DMARC-system (perhaps with hueristics to automatically set the default correctly) to opt-in to DMARC-required from field mangling. (3) Decide that perhaps mailing lists for developers are incompatible with mass-market consumer-grade mail systems. (a) Make it the problem of those mail users whose mail system has an involuntary DMARC policy to know they need to switch to another mail system. (I'm surprised there are actually that many Google employees that are still sending from google.com addresses to IETF lists, although admittedly I've been working more to make sure that Google engineers participating in open source mailing lists use their personal gmail.com addresses --- or sending from their kernel.org addresses --- instead of their google.com addresses.) (b) Make it the problem of those mail users who mail systems honor DMARC policies as a receiver to switch to another mail system. (c) For those mail systems that don't really honor DMARC policies, but rather treat it as a strong SPAM signal, make it the problem of the mail users to dig e-mails out of the Spam folder, and hopefully this will cause the machine learning systems of said mail systems to figure things out eventually --- or those mail users can switch to a developer- friendly mail system. All of the various solutions have downsides, or fit into the category of, "in the long term, it will allow for easier phishing, so the people who have inflicted DMARC on e-mail will have a some other non-standard change that will screw over mailing lists *again*" --- some of the MUA changes proposed fall into this latter category; if they are done on a wide scale, they *will* inspire the big mail providers to disallow List-ID: or Sender: headers. It may be that ARC will help, somewhat, but I suspect it will not be a silver bullet, and to some extent, we will have to choose one of the three solutions in the end anyway, because it won't be a complete solution. In the best case, ARC may make (3) a more palatable alternative, in that the failure modes caused by DMARC plus ARC are small enough that people are willing to live with (c), or where the failure modes are enough to force users to switch to mail systems where (c) is practical, and so the IETF might have enough courage in its own strength and economic importance not to knuckle under to the big mail providers, because the number of dropped messages to due DMARC and ARC not being a complete solution is small enough --- certainly a few messages are lost to SPAM filters today, and we live with this. I will again remind people that the incentive to participate in Linux Kernel development was enough for IBM to allow its engineers to use IMAP clients instead of Lotus Notes --- and not even standards-violating Domino servers for which corrupting whitespace in the body is a mandatory behavior that can't be disabled --- but instead using honest, standards-compliant open source IMAP servers. This was a non-trivial achievement, to go up against IBM Software Group. Standing up for your principles *does* work as a strategy, even when the company that needed to be influenced was a big company like IBM. If a company really wants to participate in an external standards or open source activity, because there is a strong business case, it will find a way. If it doesn't, then issues relating to the mail system probably won't make a difference in the long term. Certainly the IETF has shown its impotence with respect to mail standards... - Ted