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

John C Klensin <john-ietf@jck.com> Sat, 17 December 2016 20:29 UTC

Return-Path: <john-ietf@jck.com>
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 65C2412995D for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 12:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 ODAQmxbXciMS for <ietf@ietfa.amsl.com>; Sat, 17 Dec 2016 12:29:44 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F5D129957 for <ietf@ietf.org>; Sat, 17 Dec 2016 12:29:44 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cILbw-0007i4-2V; Sat, 17 Dec 2016 15:29:40 -0500
Date: Sat, 17 Dec 2016 15:29:34 -0500
From: John C Klensin <john-ietf@jck.com>
To: S Moonesamy <sm+ietf@elandsys.com>, Ted Lemon <mellon@fugue.com>, ietf@ietf.org
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
Message-ID: <A087FD45F16AB4DEB6C520F0@PSB>
In-Reply-To: <6.2.5.6.2.20161217081922.0b4350e0@elandnews.com>
References: <25431.1481725548@obiwan.sandelman.ca> <6.2.5.6.2.20161217022643.0e830e78@elandnews.com> <60C5B0E2-95E6-4AE5-87FA-5C438F146181@fugue.com> <6.2.5.6.2.20161217081922.0b4350e0@elandnews.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/D6YknAoKiIdP9GP4GYm5jEYnLew>
Cc: Michael Richardson <mcr@sandelman.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: Sat, 17 Dec 2016 20:29:45 -0000


--On Saturday, December 17, 2016 08:39 -0800 S Moonesamy
<sm+ietf@elandsys.com> wrote:

> Hi Ted,
> At 07:56 17-12-2016, Ted Lemon wrote:
>> Yes.   And changing it to the mailing list also has problems
>> in  terms of readability.   How about:
>> 
>> For First Last via Listname <listaddress@example.com>
>> 
>> This is brief, avoids the autocomplete fail, and gets the job
>> done.
> 
> The above adds a string to prevent the auto-complete feature
> from adding an email address which is not the author's email
> address.  At this stage it is worthwhile to consider the idea.
> 
> The bounce problem [1] is a case of the IETF violating an IETF
> "standard".

Maybe this is what you meant by the scare quotes, but the IETF
has been fairly clear -- in RFC 5321 and 5322 and elsewhere--
that 

(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
unchanged.

(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
"white".

(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 <evil-SM@example.com>

See my other message about the principle at work here.

    john