Re: (DMARC) Why mailing lists are only sort of special

Dave Cridland <> Thu, 17 April 2014 13:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E7A631A015A for <>; Thu, 17 Apr 2014 06:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.368
X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ef4lBlyIPwa6 for <>; Thu, 17 Apr 2014 06:38:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::22b]) by (Postfix) with ESMTP id 154F91A010A for <>; Thu, 17 Apr 2014 06:38:57 -0700 (PDT)
Received: by with SMTP id eb12so451064oac.16 for <>; Thu, 17 Apr 2014 06:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u6p2dPN51LzexSXSSrO8e5ebWbxPulKZT3y5XHEHP0Q=; b=AAPQcRjMaAMKtCnT2Rxt/mm2r1hCiVAXXKGIDZHu0/bGlNvg/TbfMdHcfM9Zd5UZrt AfzFUGDi5imagTV5ZXvjiayZJcy1J7314wwr2SaSNUtTD31S5u215azc0IoZafOyFHLH Tf6l/Gmsvi3YLW5AMTIfy3jq78mIqm1dVPeaE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u6p2dPN51LzexSXSSrO8e5ebWbxPulKZT3y5XHEHP0Q=; b=ANRSGokbqymMgy5surEPgIhyOh4pXcb4JNv7PYW+EJkWOGYIxY/hrIUt924xoiZc4V AwdFqgxpDBbycnM3mztcYrl7zluAZLt4D91vrvBhumKc86QVOeHPexV87XP+/nYAFZHZ f+SMdRPvxDJVzdM9bB3+s924t0czNxreKQJH6i2muEVc2N1f3TU9ttqSXemwoUZrZGvZ GZfrEeUoahdG14P3rIfN91oWYOrPnqfcoUF22WyYstQ7BlLkkv7gGaaaJ4NsQIv2g3nX +HBGYdv5Fqaj7ybqjQQ3AVRR5h7r6WBEUfssY30NWsGFzQczbXKFIH/CqfXUVzmQQEPw neUg==
X-Gm-Message-State: ALoCoQlK+WSabjf04uo3D1dCU7eEvwkuFRMQYemNSuFOG4KzPVo2qs4i1Wln1kJphrUvuRKnpc7h
MIME-Version: 1.0
X-Received: by with SMTP id x1mr11897220oei.6.1397741933439; Thu, 17 Apr 2014 06:38:53 -0700 (PDT)
Received: by with HTTP; Thu, 17 Apr 2014 06:38:53 -0700 (PDT)
In-Reply-To: <>
References: <> <20140414214949.32126.qmail@joyce.lan> <> <alpine.BSF.2.00.1404142150430.32657@joyce.lan> <> <alpine.BSF.2.00.1404151832460.38826@joyce.lan> <> <> <> <alpine.BSF.2.00.1404161654430.2065@joyce.lan> <> <>
Date: Thu, 17 Apr 2014 14:38:53 +0100
Message-ID: <>
Subject: Re: (DMARC) Why mailing lists are only sort of special
From: Dave Cridland <>
To: Yoav Nir <>
Content-Type: multipart/alternative; boundary=089e0111bf726e41cf04f73d27b1
Cc: "" <>
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: Thu, 17 Apr 2014 13:39:01 -0000

On 17 April 2014 11:50, Yoav Nir <> wrote:

> Then perhaps this is what needs to change. John R Levine did not send you
> a message. He sent a message to the list. It is the list software that sent
> you a message. So perhaps the From field should have been “From: IETF
> Mailing list on behalf of John R Levine <>”g>”. The Reply-To
> could be set to either John’s real address or the mailing list address,
> depending on what we think users mean when they click “Reply” - reply to
> John or reply to the list.
What you're changing there, as Martin Rex hints, is not the semantics of
mailing lists, but the semantics of RFC 822 and successors. I could go
along with this if RFC 5322 were demonstrably broken; but in practise, it's

John R Levine, in this instance, did indeed not send me the message - which
is why the Sender header field doesn't have his name or email address

He did, however, write the message, which is why the From header field does.

If you want explicit handling, what we'd need to do is individually (and
visibly) authenticate each transaction - this has knock-on effects in how
we handle blind carbon-copies (in particular, we'd need to send them as a
separate transaction). This has some nasty implications for unsuspecting
MUAs; but some MUAs do this anyway for other related reasons. Also, I
suspect this model would have serious implications for DMARC - that is, I
don't think it fits the DMARC model closely enough to satisfy even
"minimal" changes to the deployed base.

But what this would do, loosely, is have a verifiable chain of
Levine->list; list->me. I would then look at the policies for Levine, and
for the list, and somehow combine them to a decision.