Re: What I've been wondering about the DMARC problem

Miles Fidelman <> Tue, 15 April 2014 17:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7A2071A036F for <>; Tue, 15 Apr 2014 10:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 05OgzM3Ktcvk for <>; Tue, 15 Apr 2014 10:53:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6A17A1A01E7 for <>; Tue, 15 Apr 2014 10:53:06 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id E177DCC09B for <>; Tue, 15 Apr 2014 13:53:02 -0400 (EDT)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id kxw9TXWUNu+U for <>; Tue, 15 Apr 2014 13:52:58 -0400 (EDT)
Received: from new-host.home ( []) by (Postfix) with ESMTPSA id 43091CC093 for <>; Tue, 15 Apr 2014 13:52:58 -0400 (EDT)
Message-ID: <>
Date: Tue, 15 Apr 2014 13:52:57 -0400
From: Miles Fidelman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25
MIME-Version: 1.0
To: IETF Discussion <>
Subject: Re: What I've been wondering about the DMARC problem
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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: Tue, 15 Apr 2014 17:53:09 -0000

Hector Santos wrote:
> On 4/15/2014 11:49 AM, Dave Crocker wrote:
>> On 4/14/2014 6:45 PM, Brian E Carpenter wrote:
>>> I thought that standard operating procedure in the IT industry
>>> was: if you roll something out and it causes serious breakage to
>>> some of your users, you roll it back as soon as possible.
>>> Why hasn't Yahoo rolled back its 'reject' policy by now?
>> As the most-recent public statement from Yahoo, this might have some
>> tidbits in it that are relevant to your question:
> Thanks for the link.
> Yes, it does provide some insight, but it would be nice if YAHOO made 
> an official statement to provide vendors with planning decisions.
> This is GOOD NEWS.
> What it means that POLICY has won. I believe a policy-based DKIM 
> framework is best and I invested in ADSP and its extensions. Many 
> never believed in ADSP or policy based protocols but you have changed 
> your position and now promote DMARC as the way to go. Thats great Dave.
> But as I have been saying and largely ignored, it didn't still solve 
> the problem unless the MLM supported the handling of restricted 
> policies as well -- gracefully.  It doesn't matter if its ADSP or DMARC.
> Yahoo has FORCE the issue so in that way, I am happy.
> What it means is that I will now begin exploring DMARC implementation 
> into our already laid out DKIM framework using ADSP.  Maybe we can 
> finally get some payoff and value from all this DKIM work after all!!
> I have to note the impact on our system was low. The few 
> accounts in our support list was down to four and this was 
> going on since January with no complaints.  But the fact, Yahoo hasn't 
> roll back or relaxed its policy in over 4 months, DMARC is probably 
> here to stay now!!
> As the Jeff says:
>    "With stricter DMARC policies, users are safer, and the
>     bad guys will be in a tough spot. More importantly,
>     verified senders will unlock a massive wave of innovation
>     and advancement for all our inboxes."
> Its time for the IETF to support DMARC.  We can do this using DMARC 
> Extensions. Maybe Murray can consider writing DMARC extensions like 
> ATPS  but using DMARC as the base call.  It should be a minor change 
> to the ATPS specs.
> I can see additional DMARC extensions for other advancements, but the 
> main one is about managing 3rd party authorized domain to satisfy the 
> "signing/sent on behalf of" design need that yahoo says is required:
>    "Yahoo requires external email service providers, such as
>     those who manage distribution lists, to cease using unsigned
>     “sent from” mail, and switch to a more accurate “sent on
>     behalf of” policy."
> What is this so called "more accurate" method?
And more to the point - what is a standard for representing 
"sent-on-behalf-of" that software developers can rely on when making 
changes to list software and user agents.  (Or even better, a way to 
represent it that allows standard reply and address functions to 
continue working tranparently).

In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra