Re: SMTP RFC: "MUST NOT" change or delete Received header

Hector Santos <hsantos@isdg.net> Sat, 29 March 2014 18:10 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975241A07EC for <ietf@ietfa.amsl.com>; Sat, 29 Mar 2014 11:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.138
X-Spam-Level:
X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 fMA4Nr3urz5T for <ietf@ietfa.amsl.com>; Sat, 29 Mar 2014 11:10:45 -0700 (PDT)
Received: from ntbbs.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 95AC41A07F1 for <ietf@ietf.org>; Sat, 29 Mar 2014 11:10:45 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1179; t=1396116639; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=14W4DDfkwtsKl2zW9h8hMaRt03E=; b=cDxsGdbUOB2F7Craehqv tEmGpXRnlr8SRY7xXg4VcnYJbghsDpxY+Dcnh1HlzciUrJZln24uOvEKLAHUxFxa c+LXg34Z67wWA3ejwNPbtHsyag4CB8cr7gmeczNnvWc3uAJYiXsMH9vBgT2PbKuB hwJFPUO3bcZGhQUoxrumUjQ=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 29 Mar 2014 13:10:39 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1104100751.8462.5312; Sat, 29 Mar 2014 13:10:38 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1179; t=1396116602; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=W548fLm jYQK9xsqatZNKU654c/seZch7ub9evgepMZo=; b=NmjmVNWh9+3il+Yq2QFiAHR aNG1URlEHq0wF54Shi6pmoAMDMgtwBwQbIvIql+Ldm8kvpkGrTQfNO39HUdEikmE VTAkmR8BLMWly/jts5TcD9j9ufkMgvsB2ThMr8FrEu0jQrjSeQqfQG2tNlLydQYt Ul1Rqq9C+dxdjAqQt7lk=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 29 Mar 2014 14:10:02 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 550358335.9.16172; Sat, 29 Mar 2014 14:10:01 -0400
Message-ID: <53370CA3.9030208@isdg.net>
Date: Sat, 29 Mar 2014 14:10:43 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: SMTP RFC: "MUST NOT" change or delete Received header
References: <20140329171600.2591.qmail@joyce.lan>
In-Reply-To: <20140329171600.2591.qmail@joyce.lan>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/fIclvq1Y6XCfvEi9v3RHwiyPJ7o
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Sat, 29 Mar 2014 18:10:46 -0000

This isn't new for mail processing software developers. US EPCA. 
Product liability concerns.  You will pay more in commercial 
insurance.   Tamper with passthru, routing mail, you are at more risk, 
more so than others that don't. There were court precedence not only 
with tampering, but related to ownership and privacy issues. Google, 
yahoo, now facebook, etc, have all relied on the middle ware ownership 
legal concept to help get away with the privacy, tampering related 
borderline ethical issues. Congress has relaxed the laws to allow for 
"Good Samaritan" provisions, where you are allowed to do more, but 
don't go overboard. Of course, push come to shove, the devils would be 
the details.

Remember, its not just about protecting yourself, but protecting your 
customers are well.

On 3/29/2014 1:16 PM, John Levine wrote:
> In article <CAPv4CP9nFmYfondSrqA7ETkhvCMe4YrqRjOdGZuPiLz2kZzXrw@mail.gmail.com> you write:
>> I think the privacy beach from exposing intermediate steps is small,
>
> agreed
>
>> and in some cases knowledge of the routing may be required by law.
>
> That seems unlikely.  Got any citations?
>
> R's,
> John
>
>
>

-- 
HLS