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

Alessandro Vesely <vesely@tana.it> Sun, 04 May 2014 10:01 UTC

Return-Path: <vesely@tana.it>
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 5F96E1A018D for <ietf-822@ietfa.amsl.com>; Sun, 4 May 2014 03:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level:
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 m3QF2BFFBWvR for <ietf-822@ietfa.amsl.com>; Sun, 4 May 2014 03:01:06 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id AE7421A017B for <ietf-822@ietf.org>; Sun, 4 May 2014 03:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1399197663; bh=U7l0MNRov7UO+D6kVoSfgrwgxPGBWXUFpdhT2246dSs=; l=2429; h=Date:From:To:References:In-Reply-To; b=ciVZY6ODJVmRPUh9BuGz6kLpwM6KtcFvuASuR0wmRXxv4mgl5t5SkdzcRKTHA5B7O D7lEq0NZqtHJUFVhkcr74s76/1T9xQX5Src0Z18TKfxEkSAfq2vPsXXaF645Tu2M3j 2DqO+jUAXUCaSPowDe40GfUTyz+9Obrx7mlxkJIk=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sun, 04 May 2014 12:01:03 +0200 id 00000000005DC039.0000000053660FDF.000038A7
Message-ID: <53660FDF.7030407@tana.it>
Date: Sun, 04 May 2014 12:01:03 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0
MIME-Version: 1.0
To: ietf-822@ietf.org
References: <20140418123721.3610.qmail@joyce.lan> <5365357D.2020101@tana.it> <53655215.2070301@sonnection.nl>
In-Reply-To: <53655215.2070301@sonnection.nl>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/YwmufFH0vajRA113ZLYpfRXK2Qw
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
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: Sun, 04 May 2014 10:01:08 -0000

On Sat 03/May/2014 22:31:17 +0200 Rolf E. Sonneveld wrote:
> 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).

It is not going to be exponential since the number of techniques
needed to solve this particular problem is dominated by the total
number of techniques available at this time :-)

Seriously, I'm not inventing anything new here.

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

You're right, this is something of a hassle.  However, there are some
upper bounds, the number of users in a domain, the number of lists a
user is subscribed to,  the number of subscribers in a list.  By using
appropriate modes and formats, it won't be overwhelming.  When the
ball starts rolling it might become somewhat manageable, certainly
better than if each poster had to ask her/his postmaster the same
thing individually.

Those ML-admin-postmaster relationship are a plus, as they give an
occasion to meet and talk.  We may regard that happening as a
demonstration, which we call in order to drive the change.

Ale