Re: [IETF] DMARC methods in mailman

[Theodore Ts'o <[e-mail]>]

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 <[e-mail]> on behalf of Joe Banker <[e-mail]>
> 
> and is at no risk with:
> 
> 	From: Joe Banker <[e-mail]>
> 
> 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