Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list?

Dave Crocker <dhc@dcrocker.net> Tue, 06 May 2014 16:00 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BE61A0779 for <ietf@ietfa.amsl.com>; Tue, 6 May 2014 09:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3UsIV62vaC6 for <ietf@ietfa.amsl.com>; Tue, 6 May 2014 08:59:58 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 339B91A03C3 for <ietf@ietf.org>; Tue, 6 May 2014 08:59:58 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s46FxnYg022312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 May 2014 08:59:52 -0700
Message-ID: <536906F2.3060008@dcrocker.net>
Date: Tue, 06 May 2014 08:59:46 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list?
References: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> <53682B10.2070000@meetinghouse.net> <1BB8A9AB-C7C1-4959-B8C2-C649AB4EA19D@cisco.com> <53682C4B.80301@meetinghouse.net> <C92FEFD4-06B7-48CD-A1F3-CF6F3DB259DE@cisco.com>
In-Reply-To: <C92FEFD4-06B7-48CD-A1F3-CF6F3DB259DE@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 06 May 2014 08:59:52 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/vIgj98QLj2_nN5EVDAOWrVQ8cUY
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 16:00:01 -0000

On 5/5/2014 5:37 PM, Fred Baker (fred) wrote:
>>> I guess we’re running it. I was hoping to avoid the “everything
>>> around broke” part.
>> 
>> Well.. I can certainly tell you that, as someone who supports a
>> couple of dozen email lists, an awful lot broke
...
> And what comes quickly to mind is the comment, earlier in this
> thread, that “we have been running it for nine years.”
> 
> Running it, perhaps, but not learning from it. Kind of “Really Not
> The Point”.


I might be a bit confused about the 'it' being referenced, so it's worth
ensuring some clarity:

     1.  DKIM and SPF have been fielded for perhaps 12 years.  DKIM in
its original-but-similar form, DomainKeys, and then its initial
'consortium' form, preceded the 2006 published DKIM RFC by several
years.  SPF appeared around that time too.  So the reference to 6 years
of operational experience is really on the very low side.

     2.  Use of DKIM and SPF is reasonably well understood and does not
cause interesting email operations problems.  I'm starting to hear some
unfortunate stories about DKIM signature breakage in scenarios that I'd
have hope would not have it, but the breakage of the signature is not
breaking legitimate email scenarios.

     3.  DMARC's functions and limitations have been reasonably well
understood since it's inception.  It works comfortably in specific
scenarios and causes problems in others.  Again, there are no surprises
about these now.  They've been clearly understood by those working on
the spec.

     4.  SPF actually has the potential for causing similar operational
problems.  It has a strict mode that will cause receiver-side rejections
if honored, and they will occur for any multi-hop sequence.  In the case
of SPF, multi-hop means /any/ sequence that produces a new client smtp
IP address, presented to the evaluating receiver.  In the case of DMARC,
given the use of DKIM, the problem is multi-hop for scenarios that break
DKIM signatures.

     5.  The reason SPF's strict mode hasn't been problematic is that
virtually no one uses it.


So what's different now is not technical, its operations policy.  A
couple of large providers chose to apply DMARC to scenarios known to
cause problems for some of their users and groups their users work with.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net