Will mailing lists survive DMARC?

Alessandro Vesely <vesely@tana.it> Tue, 29 April 2014 11:11 UTC

Return-Path: <vesely@tana.it>
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 8CB011A082F for <ietf@ietfa.amsl.com>; Tue, 29 Apr 2014 04:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.574
X-Spam-Level:
X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Zfd1a9Be5UOH for <ietf@ietfa.amsl.com>; Tue, 29 Apr 2014 04:11:01 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D61A0821 for <ietf@ietf.org>; Tue, 29 Apr 2014 04:11:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1398769859; bh=ijwweVPsWuB4Vcv3WCCJJYFEgH9e7bnMFy8T2qXPG6k=; l=1515; h=Date:From:To; b=po4hay8mlkhQaKgGgNIuTfFpeyd/LVO3gDrqpKgt/bW/rxw62/7AdGt/8eHcnj6SI Gph/FE0pXuIq6x87lSOZ3ro/46ri3vGPOw8gcXmGEA147RtX2yhKyuXtp1445EiKeg uv0WBVdfGJxw/04LJxLAs2oDf0MInzanxQvHW/KI=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 29 Apr 2014 13:10:59 +0200 id 00000000005DC033.00000000535F88C3.00002C46
Message-ID: <535F88C3.4060002@tana.it>
Date: Tue, 29 Apr 2014 13:10:59 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0
MIME-Version: 1.0
To: ietf <ietf@ietf.org>
Subject: Will mailing lists survive DMARC?
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/YYso5X9IIBaeOTtDR4A0x8YV97I
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, 29 Apr 2014 11:11:03 -0000

There has been some discussion on what should the IETF do about the
collateral damage experienced by several mailing lists when major
mailbox providers switch their DMARC policies to p=reject.

Mailing lists used to be a legitimate use of email.  Albeit they are
the workhorse of many organizations which are vital for the Internet
itself, such as the IETF and several software projects, statistically
they are a minor Internet feature.  I can understand that after
decades of failed attempts to control email abuse, their disappearance
is not the main concern of "p=reject" proponents.

The discussion on ietf-822 brought some mailing list assumptions
--much needed, since ML were never formally standardized-- as well as
a few proposals.  Now the discussion seems to be fading out, even if
no actionable result was reached.  The solutions proposed, in order of
decreasing ease (IMHO), are:

* Whitelisting,
* weak signatures,
* permission to re-sign, and
* exchange of cryptographic data.

All of those solutions require that originators' relays know whether a
message is destined to a mailing list.  That is a delicate subject in
itself, as it involves privacy considerations --does a subscriber
consent to allowing her or his mailbox providers to know which lists
she or he is on?

The DMARC draft is currently in "AD Followup" state.  A review was
posted here last week, a process which doesn't seem to affect
deployment much.

How is the IETF going to proceed on this issue?

Ale