Re: [dmarc-ietf] IETF Mailing Lists and DMARC

Hector Santos <hsantos@isdg.net> Fri, 04 November 2016 12:21 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9259129584 for <ietf@ietfa.amsl.com>; Fri, 4 Nov 2016 05:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.001
X-Spam-Level:
X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=fVEP1nQ7; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=p2+WtRam
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 EiMz_Gy77VI8 for <ietf@ietfa.amsl.com>; Fri, 4 Nov 2016 05:21:45 -0700 (PDT)
Received: from catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id ABC94129512 for <ietf@ietf.org>; Fri, 4 Nov 2016 05:21:45 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2225; t=1478262101; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=ed+s5KOgvIHQkehVCHnyu9lQjhs=; b=fVEP1nQ7z8EIZmQQ/mPBBwizyBnjPAp0UnZEdrjDPpXY60P0ybSxWxCaIT0tIS VwiFzwrK37sPtaupsV6sl6fJNAKgYk+KGWeOh51xYUgciyj0oJEIM7r4WAFZuo10 9wL5U5PAwqGxftNpCbO2Oi9Nsjp5diWKCOCr5nYfSNEB4=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for ietf@ietf.org; Fri, 04 Nov 2016 07:21:41 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 750609502.1.4880; Fri, 04 Nov 2016 07:21:39 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2225; t=1478262087; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2vRdrSK uHhydq1mqZS6TS4cGH8gkHjGPinhLRQt43/g=; b=p2+WtRam0OxPwQnQmTtV/Bf /u3ViqDFdm3XRW6FA0Vkl+YnRViJQeZrWN/S2pug5t7AR2f5fwY4FEzx/iHVNji+ Mab06QBTUnldn+DIvdUIxD4sbtLXp6Lazo1tsSE1FJC/Yt5NRIWD21QOn3XAbD4q uzy99WLAGq1QRLSM/tNM=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for ietf@ietf.org; Fri, 04 Nov 2016 08:21:27 -0400
Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 206166718.9.61888; Fri, 04 Nov 2016 08:21:26 -0400
Message-ID: <581C7D55.7080708@isdg.net>
Date: Fri, 04 Nov 2016 08:21:41 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Brandon Long <blong@google.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC
References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <CABa8R6vHdt75NFKW3s6xOzLcq=jmVAHDPX0tjLRdGpYSTP2cYA@mail.gmail.com> <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com>
In-Reply-To: <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/iaRCGJt3evpuIa_7yqiE2ly46kY>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>, IETF <ietf@ietf.org>, Cullen Jennings <fluffy@iii.ca>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 Nov 2016 12:21:52 -0000

On 11/2/2016 6:19 PM, Brian E Carpenter wrote:
>
> I think Michael Richardson made a very valid point. If our mailing
> list software detects a sender whose domain has p=reject, we *know*
> that the forwarded message will fail DMARC validation. So there's a
> strong case for rejecting the message immediately, so that the sender
> can be told about the problem and can choose a different sending address.

I had it in my 2006 DSAP proposal for MLM guidelines:

   http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3

The term DMARC can be swapped in the section since its really about a 
general DKIM+POLICY and it doesn't matter if it was SSP, ADSP, DSAP or 
DMARC:

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DMARC operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DMARC check to
       determine if a subscribing email domain DMARC policy is restrictive
       in regards to mail integrity changes or 3rd party signatures.  The
       MLS SHOULD only allow original domain policies who allow 3rd party
       signatures.

    Message Content Integrity Change

       List Servers which will alter the message content SHOULD only do
       so for original domains with optional DMARC signing practices and
       it should remove the original signature if present.  If the List
       Server is not going to alter the message, it SHOULD NOT remove the
       signature, if present.

Wow! 10 years and we still having this issue! Incredible. :(

But I did add the subscription controls for our ML software.

> Presumably, we'd only need to do this until ARC is deployable.

Can ARC resolve the downlink problem for the non-ARC compliant receivers?

I've always said that the MLM needs to "look up" the practices of the 
Author Domain.  What is its expectation?  Intentions?

If the MLM expects the receivers to do DMARC lookups, why shouldn't 
the MLM do the same prior to accepting a list submission or 
subscriber?   The MLM can also check/detect DMARC related SMTP error 
responses and minimize the erroneous automatic removals from list. 
All this requires MLM software change.


-- 
HLS