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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 16 December 2016 20:39 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 1C6BC1296CB for <ietf@ietfa.amsl.com>; Fri, 16 Dec 2016 12:39:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 e-yTInk5q5m4 for <ietf@ietfa.amsl.com>; Fri, 16 Dec 2016 12:39:07 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644461294F6 for <ietf@ietf.org>; Fri, 16 Dec 2016 12:39:07 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 394A4284B55; Fri, 16 Dec 2016 20:39:06 +0000 (UTC)
Date: Fri, 16 Dec 2016 20:39:06 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: 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: <20161216203905.GD13486@mournblade.imrryr.org>
References: <25431.1481725548@obiwan.sandelman.ca> <5EF6F271-1CF7-4981-8E83-C7A7B49DB8F2@gmail.com> <CDE8A76C-ECD7-4370-9823-3C78144A8850@nohats.ca> <24005.1481827604@obiwan.sandelman.ca> <alpine.LRH.2.20.1612151513060.15183@bofh.nohats.ca> <20161216202704.glz5vgu773gqqgvm@thunk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161216202704.glz5vgu773gqqgvm@thunk.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KuuvZilIUDNyY65ZrTjxpUR9QXs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: ietf@ietf.org
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: Fri, 16 Dec 2016 20:39:09 -0000

On Fri, Dec 16, 2016 at 03:27:04PM -0500, Theodore Ts'o wrote:

> The real problem with all of these schemes is as they make life easier
> for the user, it also makes life user for the phishers.  So for
> example, if we start adding a mail header field "this is *really* the
> sender", or there is a standard way to parse it out of the comments of
> the from field, then it will also provide a better user experience and
> a better user interface to display that as the summary line of the
> e-mail, and in the mail headers that are displayed for the user.
> 
> And the moment you do that, the phishers will use that to exploit
> stupid uesrs, and then there will be a DMARCv2 that will break that
> field, and perhaps, break mailing lists again.  :-(

The real problem that DMARC "solves" is reducing the work-load of
the abuse desks of the domains publishing DMARC records.  DMARC
has nothing to do with protecting end-users from phishing.

When it is more difficult to forge an email from a Yahoo user, it
is more convenient for the phisher to fake an address from some
other domain, and then Yahoo deals with fewer complaints.

The RFC2822.From field is not a particularly important element in
determining whether a phishing email is effective.  What matters
is sufficiently compelling message content.  

There too little correlation between the purported (in message
content) sending organization and the RFC2822.From in a large
fraction of legitimate email, for users to carefully check or rely
on that field.

-- 
	Viktor.