Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

Dave Crocker <dhc@dcrocker.net> Tue, 01 December 2015 14:56 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5491A92F2; Tue, 1 Dec 2015 06:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 fvkjv6rrYQmD; Tue, 1 Dec 2015 06:56:41 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19D91A92F1; Tue, 1 Dec 2015 06:56:41 -0800 (PST)
Received: from [192.168.1.99] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tB1EufEd005486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2015 06:56:41 -0800
References: <20151130042819.10658.qmail@ary.lan> <1448858775386-ceecd236-8b11ac04-a03b4438@fugue.com> <glJrvFDUtDXWFA87@highwayman.com> <1448923888960-cb7e590f-f443f8dd-7ec594e1@fugue.com> <565CD58D.9080403@dcrocker.net> <1448924778159-4b16d8e4-631c41b1-52b0fbf2@fugue.com> <alpine.LSU.2.00.1512011351040.25050@hermes-2.csi.cam.ac.uk>
To: shutup@ietf.org, ietf-smtp@ietf.org
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <565DB532.70407@dcrocker.net>
Date: Tue, 1 Dec 2015 06:56:50 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <alpine.LSU.2.00.1512011351040.25050@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 01 Dec 2015 06:56:41 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/Bn4XAJ6lI2zh9NVWq4seP_Sh4Ao>
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 14:56:43 -0000

On 12/1/2015 6:05 AM, Tony Finch wrote:
> Ted Lemon <mellon@fugue.com> wrote:
>> Monday, Nov 30, 2015 6:02 PM Dave Crocker wrote:
>>> On 11/30/2015 2:51 PM, Ted Lemon wrote:
> 
>>>> Why would I be relaying mail on?  Only for a mailing list.
>>>
>>> The most obvious is mailbox aliasing, such as for vanity addresses such
>>> as university alumni associations provide.
>>
>> That's a mailing list with one subscriber.   Same scenario.
> 
> Not really. Mailing lists have very different administrative behaviour to
> aliases - they change the return path to an administrative address when
> forwarding the message whereas aliases do not. RFC 5321 section 3.9.


Yes.  And further...

They typically also have very different formal -- that's meant as
'official', not 'math' -- semantics.

Alias behavior tends to be /very/ close to pure relaying.  It changes
very little in the message, other than the rfc5321.Rcpt-To address.

Mailing lists tend to make massive changes to the original message; they
are taking formal delivery of the message and then post a new message.
For end users, the view is of a single message from original author to
final recipient.  To the email infrastructure it is two (or more)
post/deliver sequences.

Folks seeking to discuss email at this level should consider becoming
familiar with RFC 5598.  It will make careful discussion of email
behavior a lot more consistent...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net