Re: [ietf-822] WSJ/gmail/ML, was a permission to...

"Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl> Sat, 03 May 2014 20:31 UTC

Return-Path: <R.E.Sonneveld@sonnection.nl>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4A51A012F for <ietf-822@ietfa.amsl.com>; Sat, 3 May 2014 13:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 AAvdZ49bG2Dk for <ietf-822@ietfa.amsl.com>; Sat, 3 May 2014 13:31:35 -0700 (PDT)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id F2BAD1A012D for <ietf-822@ietf.org>; Sat, 3 May 2014 13:31:34 -0700 (PDT)
Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3gLhnG04T8z1L8fh; Sat, 3 May 2014 22:31:30 +0200 (CEST)
Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3gLhnF639jz1L8cK; Sat, 3 May 2014 22:31:29 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 65410122EBB; Sat, 3 May 2014 22:31:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at sonnection.nl
Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xz5jtBQg7Bfw; Sat, 3 May 2014 22:31:18 +0200 (CEST)
Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 4F767122E88; Sat, 3 May 2014 22:31:18 +0200 (CEST)
Message-ID: <53655215.2070301@sonnection.nl>
Date: Sat, 03 May 2014 22:31:17 +0200
From: "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl>
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Alessandro Vesely <vesely@tana.it>, John Levine <johnl@taugh.com>, ietf-822@ietf.org
References: <20140418123721.3610.qmail@joyce.lan> <5365357D.2020101@tana.it>
In-Reply-To: <5365357D.2020101@tana.it>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1399149090; bh=uWol6EfY8z2/ri2CDv3UMiMWeDNAoXbRlhM8hK2gzws=; h=Message-ID:Date:From:To:Subject:From; b=LSIfc5ISB3NAvNgpOdCVUTMNesNMHAygWHZDDQpISpGgyZKVnz2RePWdv4DsEGcdc UuAZd4r6FoDTgMqX3H8y1sFU+RFsmjWvrlpUOeZOy483UYp15J3eSbl6up85FTZbvf TdJHnIgN0bQ4GxLuSaL313atVscsK3Lw47YTWLSo=
DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3gLhnG04T8z1L8fh
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/tzIRzUUQvmkuCeLmEGsSXMliSaM
Subject: Re: [ietf-822] WSJ/gmail/ML, was a permission to...
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: R.E.Sonneveld@sonnection.nl
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 May 2014 20:31:37 -0000

On 05/03/2014 08:29 PM, Alessandro Vesely wrote:
> On Fri 18/Apr/2014 14:37:21 +0200 John Levine wrote:
>> I also note that this hack, with or without Ale's changes, does
>> nothing to solve the send from gmail and WSJ article problems.
> Those two problems can be solved in different ways.  Gmail could use a
> third party's submission server just like they use its pop/imap one.
> WSJ could write "WSJ.com" in the From: and the purported issuer in the
> Subject: (and possibly also Reply-To:) instead of their currently
> doing the other way around.

In your proposal one spam/phishing fighting technique (DMARC) requires 
(at least) three techniques to solve its problems (which in turn may 
require another 3^2 techniques to solve their problems, which ... 3^n 
techniques ... et cetera).

>
> We need to refine the spec specifically for mailing lists.  I'd love
> to read something like:
>
>     A mailing list MUST NOT tamper with the From: field.  Those who do
>     that are not mailing lists, and can work their own way out of
>     DMARC.
>
> Is it practical to mandate the same also for To:, Cc:, Date:?  Are
> there lists which alter them?
>
> Also:
>
>     In order to get weak signatures, a mailing list needs to let its
>     posters' domain admins know which posters post to which addresses.
>     It is advisable to ask for posters' permission to do so.
>
> That can be done manually for the time being.  Imagine lots of
> ML-admins writing to the relevant postmasters asking to apply
> low-profile signatures for specific MAIL FROM/RCPT TO pairs.  A
> postmaster can verify that those users really post to those addresses,
> and believe that it is a mailing list since its owner says so.  A
> couple of scripts would do.  Automation can later be improved.

This really doesn't scale. Maybe you have the few TBTI ESP's in mind, of 
which there are only a few. But each domain that starts using p=reject 
will introduce a new set of relations (ML-admins-postmaster), which in 
turn will grow exponentially.

>
> The same manual requests can be done for whitelisting, let's see the
> pros and cons.
>
> Either way, we have to do it at our expenses, since it's us who want
> mailing lists.  Or we may hope that users' rebuttal will discourage
> receivers from honoring DMARC policies, but that sounds like letting
> email problems grow.

I agree there is a need to solve the current problems, but let's come up 
with one solution, not many.

/rolf