Re: DMARC: perspectives from a listadmin of large open-source lists

Hector Santos <hsantos@isdg.net> Tue, 08 April 2014 19:21 UTC

Return-Path: <hsantos@isdg.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 4EE7E1A0702 for <ietf@ietfa.amsl.com>; Tue, 8 Apr 2014 12:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.137
X-Spam-Level:
X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
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 gnDA4726Xcu0 for <ietf@ietfa.amsl.com>; Tue, 8 Apr 2014 12:21:11 -0700 (PDT)
Received: from secure.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 661371A06FA for <ietf@ietf.org>; Tue, 8 Apr 2014 12:21:07 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3352; t=1396984865; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IdCoBR4wTcwBlSllnI+rWFqC9s0=; b=EiFtCxLJIVovtJqxP0N+ xav6n67X7H9yeHTjx4wRPMt65z6a1aKfgk90G5Znjb0vg19zTWxS8vMfiXgtJTKZ vZNyzlMVDjnRfas3UOiJPLQoRTUQUNIQ3YEXGZSbPoR+ADY9q1D8tyTAMc6C9Sce UykOZuNmxG6DD+jzoN9xCxI=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Tue, 08 Apr 2014 15:21:05 -0400
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 (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 93448374.3.2132; Tue, 08 Apr 2014 15:21:04 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3352; t=1396984807; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HaE5Klw /OVCVj03Jrxq0YTSWrpc5Ro0i+grIHh75kJQ=; b=jlc+6+jsy9UUuAnupsD5NAc egUyvB3l1z+hXHmZdytcwXCJeFV/hlASzmKOYkfp2M/m5mzCNFJnzn1sRnMJR85o xMym/G5D+Kk494+pYiBBGgEfK6P1PYjJw7jAZLFBNAY2Gj6sUZpIHkjmH4RMvGC6 vev5y70RC4fiS6tTOnQ4=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Tue, 08 Apr 2014 15:20:07 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 112983687.9.2428; Tue, 08 Apr 2014 15:20:06 -0400
Message-ID: <53444C1C.5080506@isdg.net>
Date: Tue, 08 Apr 2014 15:21:00 -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.3.0
MIME-Version: 1.0
To: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
References: <robbat2-20140408T031810-279861577Z@orbis-terrarum.net> <alpine.BSF.2.00.1404072357400.73388@joyce.lan> <01P6EEIPML6600004W@mauve.mrochek.com> <6.2.5.6.2.20140408101346.0ccb5e88@resistor.net>
In-Reply-To: <6.2.5.6.2.20140408101346.0ccb5e88@resistor.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/m80aF-P8lFFG5BRI6IJzFyIfh0w
Cc: ietf@ietf.org, "Robin H. Johnson" <robbat2@gentoo.org>, zwicky@yahoo-inc.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <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, 08 Apr 2014 19:21:15 -0000

Really?

You knew that our software was the first to suggest and document in 
the 2006 DSAP I-D on how to a MLS will need to handle restrictive 
domain security policies.  RFC 6377 (BCP 167) notes on this came from 
my I-D and the DKIM WG discussions about it whether directly or not.

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

   3.3.  Mailing List Servers

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

    Subscription Controls

       MLS subscription processes should perform a DSAP check to
       determine if a subscribing email domain DSAP 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 DKIM 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.

Our MLS was the first supports this.

During development of RFC6377, the potential interop issues was well 
known. I was able to show this when the middle ware ignores DKIM 
signature controls.

DMARC will not resolve the problem, but .....

Part of the problem has been with the DKIM mindset to make it a 3rd 
party signature framework where the LIST or 'central' mail distributor 
has full control of signatures.  Remember, in the original DKIM, 
making it work with LIST system was a secondary chartered concern. 
That charter changed (or did it?) and not for the better with a lesser 
focus on the author domain policies, and eventually dismantling of 
ADSP, but replaced with DMARC.

Restrictive 1st party controls are by design not to work in the 3rd 
party environment. That was the purpose and intent of the original SSP 
policies, and the reduced ADSP proposal.  DSAP attempted to bring back 
that idea. You could only implement it as described above or by simply 
following the policy in some fashion to not cause downlink issues. 
Intentionally ignoring it was not an option if you wanted to support DKIM.

But DKIM and its deployment documents are in conflict.  It says follow 
ADSP, but it allows for the 3rd party DKIM signing system to ignore it.

Can't have it both ways.

---
HLS


On 4/8/2014 1:19 PM, S Moonesamy wrote:
> Hi Ned,
> At 09:52 08-04-2014, ned+ietf@mauve.mrochek.com wrote:
>> Actually, mailing lists *can* implement DMARC, just not that way: Do
>> a DMARC
>> check on all incoming messages, and if the domain policy is one that is
>> incompatible with the list's own policies - whatever they are -
>> either change
>> the list's policies to conform to that message or reject it outright,
>> preferably with a nasty "find another a better mail provider" sort
>> of message.
>
> There is some Mailman code which does the above.
>
>> If the IETF wants to take a leadership position in regards to this
>> issue,
>> perhaps someone could set this up.
>
> I did a search before asking this question; I did not find any
> answer.  Does anyone know whether the IETF adheres to BCP 167?
>
> Regards,
> S. Moonesamy
>
>
>