Re: DMARC-4-ML: Can the IETF call a demonstration?

Alessandro Vesely <> Wed, 14 May 2014 17:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 771AC1A0329 for <>; Wed, 14 May 2014 10:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.073
X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lRsy5-_LOPhi for <>; Wed, 14 May 2014 10:20:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 358DC1A0323 for <>; Wed, 14 May 2014 10:20:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; t=1400088027; bh=aSfoIB0kCNXQpINHWHu93Uko4Z3PRs4zmVrdXfxCwbM=; l=4220; h=Date:From:To:References:In-Reply-To; b=h7RqG93FMIS/0vIPvHzxmFOh9H4LJ5Dp0L+VWGS1HQhRW7PoyqwAYY8ZruowREWYA f0MftEunZHe18TYYS8vGCQDNcUQw8033oWAcXt/FeaBkJDSMeHMMsNoOF5VBSek9Fj GZfrEVe9PHrp7dX0An549dV6bxywUrwUyuw9Y2lE=
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA; Wed, 14 May 2014 19:20:27 +0200 id 00000000005DC035.000000005373A5DB.0000322D
Message-ID: <>
Date: Wed, 14 May 2014 19:20:26 +0200
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0
MIME-Version: 1.0
To: John C Klensin <>,
Subject: Re: DMARC-4-ML: Can the IETF call a demonstration?
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 May 2014 17:20:54 -0000


On Wed 14/May/2014 14:39:40 +0200 John C Klensin wrote:
> --On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely wrote:
>> Will the admins go marching in?
> At the risk of repeating myself...
> (1) I think it is a bad idea for the IETF to be formally
> spending effort to work around damage caused by a non-IETF
> protocol.   I note that, if this were a protocol that was
> specified in the IETF and over which the IETF had change
> control, we would be trying to fix the protocol itself or would
> withdraw or depreciate it because of the damage caused.

That sounds like yet another instance of the not-invented-here
syndrome.  FWIW, much the same solutions were put forward for ADSP.
IETF or non-IETF, the difference seems to be that DMARC currently has
more traction and deployment than ADSP ever had.

> (2) I believe it is unacceptable for a new protocol or
> capability to impose costs on operators of other systems in the
> absence of clear and broad consensus about why the changes are
> needed and appropriate. That consensus may well exist for DMARC
> and its policy statements among the contributors/ supporters of
>, but it is fairly clear to me that it does not exist
> in the IETF.   Contrast that with, e.g., privacy issues about
> which there have been consensus statements in the IETF, perhaps
> even statements strong enough to justify some additional costs.

Getting a rough gauge of consensus is exactly the reason why I wrote.
 I'm less confident than you on the opinion of DMARC people, since a
change in DMARC is implied.  I noted some inclination toward
reasonable changes from a few ML admins on this list, though.

Let me make explicit it is not consensus on DMARC we're talking about.
 It is consensus on the workaround and the demonstration.

> (3) Since I mentioned privacy, I should note that developing,
> keeping, and maintaining the database you mention could have
> significantly more privacy risks than simple recording of
> envelope information in server logs.  If IETF is now committed
> to privacy as a significant goal, that question needs careful
> evaluation.

That's why the DB has to be build by hand.  Although I doubt it is
realistic for users to hide out from their mailbox providers, I agree
special care is needed.  For those who trust their mailbox provider,
it is convenient to have it control their subscriptions.  A possible
method to automate that task was called water-tight-opt-in[1].


>> Doing nothing will result in a mix of three reactions.  1, ML
>> admins changing the From: of domains who publish strict DMARC
>> policies;  2, some users changing mailbox provider; and 3,
>> less domains publishing strict DMARC policies.  
> There are two more options you didn't mention: (4) more systems
> either not implementing DMARC or ignoring strict policy
> specifications, and (5) driving some users and activity away
> from the use of mailing lists entirely in favor of using more
> "social network" web sites and activities.

Thanks to you and Ned for completing the analysis.

> I note that some people believe that DMARC and strict policies are
> part of a business model to force that result.  I don't believe
> that personally, but the optics are unfortunate.

Me too.  Spam is the selective pressure.

>> The combined effect seems to weaken both DMARC and mailing
>> lists.
> So?  Perhaps we should be focusing more on strategies that
> weaken DMARC to the degree necessary or appropriate without
> weakening mailing lists or imposing added costs on those who
> operate or subscribe to them.  

I'm not sure it would be good to go for a head-on collision, even if
we were granted getting out safe.  For another inexact analogy, we let
SPF die down that way.  Had we agreed on a viable compromise, perhaps
we would have enjoyed less spam, who knows?  Now DMARC comes harder.
The question is when the next will come, and whether it will be so
better as to be worth the while.


> The analogy is obviously not exact, but, if some external group
> came up with a protocol that weakened TCP [...]