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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 05 May 2014 00:19 UTC

Return-Path: <mcr@sandelman.ca>
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 996071A01DB for <ietf-822@ietfa.amsl.com>; Sun, 4 May 2014 17:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.942
X-Spam-Level:
X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 2wWIQxkxmiZJ for <ietf-822@ietfa.amsl.com>; Sun, 4 May 2014 17:19:46 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id ECD861A0141 for <ietf-822@ietf.org>; Sun, 4 May 2014 17:19:45 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1579820030; Sun, 4 May 2014 20:21:06 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id DCB0C63ABD; Sun, 4 May 2014 20:19:40 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C78A463AB6; Sun, 4 May 2014 20:19:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: John Levine <johnl@taugh.com>
In-Reply-To: <20140504193742.2489.qmail@joyce.lan>
References: <20140504193742.2489.qmail@joyce.lan>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 04 May 2014 20:19:40 -0400
Message-ID: <6943.1399249180@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/OgIULLWTDVLc98sADPRyImliCJc
Cc: ietf-822@ietf.org
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: Mon, 05 May 2014 00:19:47 -0000

John Levine <johnl@taugh.com> wrote:
    >> If we had: p=reject-even-if-list-id

    > Won't work.  See previous message.

I think you are reading it wrong.
It's basically the same as p=reject is now.
The other one, would mean: there are some things that could change
by an intermediary.

    >> that would satisfy the paypal case. (But, wait, btw, paypal employees
    >> are @paypal.com.  They need corp.paypal.com or some such).

    > They're on top of this problem, and use paypal-inc.com.

right!

    >> To me, it seems that really we need an in-SMTP protocol by which
    >> senders are told that they are sending to a re-distributor, and their
    >> current policy won't do, but that they can do X.  That has to go back
    >> to the user.

    > Remember that there are other things that DMARC broke, that do not
    > involve forwarding.  That's what "WSJ/gmail" in the subject line are
    > about.

Yes, I understand.  I'm not sure that web sites sending on my behalf
is ultimately distinguishable from spam without some cryptographic route
through the browser/webserver into my MUA.

I can imagine such a channel, but I don't think we want to talk about that.
I think that we should list the various problems that we have discovered and
it may be that some we can fix, and some we can not.

Ultimately, in the space of end-to-end SMTP, lists are a form of
intermediary.  DMARC is a form of BCP38...


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-