Re: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions

S Moonesamy <> Sun, 18 December 2016 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2358512955A for <>; Sun, 18 Dec 2016 02:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.89
X-Spam-Status: No, score=-4.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-3.1, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=g90qmI9b; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=ZastOB44
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TL9K15cW2AlR for <>; Sun, 18 Dec 2016 02:28:28 -0800 (PST)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id E98F8129451 for <>; Sun, 18 Dec 2016 02:28:27 -0800 (PST)
Received: from (IDENT:sm@localhost []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id uBIASF3n025206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Dec 2016 02:28:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1482056905; x=1482143305; bh=GFOSDTybDFVjyAJGZANenFKbiBVZ5rl7PZKba99OcDk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g90qmI9bggr9MTY8r8/YvDIYtCC9Cdts6Y7md670YuvhAW75jvZLVe6QmZK4tZjRc iSZ7CO1riMb+cwuZOQAuSItpDP+GjD65STVbgG4OaSAaQnYE8x7hAmrGLGGs9ctSO7 xwUlmN2yPebKQ5FA13SVF9TLSr0IMcb81ubvObkc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1482056905; x=1482143305;; bh=GFOSDTybDFVjyAJGZANenFKbiBVZ5rl7PZKba99OcDk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZastOB44WoH2ALOiMUK5vZVEU0aAAeE0iJrA8jI5LgPjp35zhUrBvNVYu6q17znsp bwz3lfPOKwDT21HVf1wcWrVJlMHjWHXBxtqp7E5q7EFUKGT6UAjAPZ5RIY8k56UtBd Pb74a6ygt+HHXYyI7Fhj9RwTRvstvNgjqTeP1dTs=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sun, 18 Dec 2016 02:15:24 -0800
To: John C Klensin <>,
From: S Moonesamy <>
Subject: Re: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions
In-Reply-To: <A087FD45F16AB4DEB6C520F0@PSB>
References: <> <> <> <> <A087FD45F16AB4DEB6C520F0@PSB>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <>
Cc: Michael Richardson <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Dec 2016 10:28:29 -0000

Hi John,
At 12:29 17-12-2016, John C Klensin wrote:
>Maybe this is what you meant by the scare quotes, but the IETF
>has been fairly clear -- in RFC 5321 and 5322 and elsewhere--

RFC 7960 states that: "To alleviate unsubscribes to the Mailing List 
due to the messages bouncing because of DMARC, the MLM needs to not 
act on notification messages due to message authentication 
issues".  That would entail interpreting the Enhanced Status Codes, 
specifically the ones related to message authentication failures and 
ignoring them for unsubscription purposes.

>(1) Mailing lists can be handled at MTA level, in which case the
>backward-pointing envelope address is changed to point to the
>list but that, other than adding trace information (including
>List identification), the headers and message body should be

Yes.  It is the message body change which indirectly causes the 
rejection for mail from those "p=reject" domains.

>(2) Mailing lists can also be handled at MUA level, in which
>case "Resent-" fields are added, possibly also with List
>information, but the header "From:" and "Sender:" fields are to
>be unchanged.


>(3) Because we deliberately do not have standards about what an
>MUA can do -- precisely because it is ultimately an agent acting
>on behalf of the end user -- such a system can plausibly
>construe such a message as being received, modified as desired,
>and then forwarded to a list of others.   Again, there is no
>standard, but treating mailing list traffic that way opens up a
>whole series of potential attacks because, if the "MUA can make
>changes" model is applied, nothing prevents such an MUA from,
>e.g., changing every instance of "black" in the message body to

The problem is that we are getting into what a MUA does, e.g. 
auto-completion.  We would also not be following RFC 5322 by making a 
change to the "From:" field [1].  In a way, this validates the 
argument that a whole series of potential attacks is being opened.

>(4) We have never encouraged anything that attributes semantics
>to either a name phrase (<display-name> in RFC 5322-speak).
>While we have never taken a position about auto-complete and
>populating address books based on those fields, doing the latter
>is fraught with risks, particularly if all I need to do to
>divert mail from Ted to you to an attacker is to send him a
>message with a "From:" header field of
>     S Moonesamy <>

Yes.  We might end up having to consider whether to attribute 
semantics to the <display-name> as a way to solve the problem.  Let's 
assume that 20% of IETF mailing list subscribers use a "p=reject" 
domain name in the "From:" field and that they are no longer allowed 
to post messages to the mailing list because of the policy advertised 
by that sending domain.  What should the mailing list moderator do in 
response to complaints from those subscribers?

S. Moonesamy

1. This is related to Point 2.