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
- SMTP RFC: "MUST NOT" change or delete Received he… Kevin M. Gallagher
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Randy Bush
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Dave Cridland
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Eliot Lear
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Ted Lemon
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Dave Aronson
- Re: SMTP RFC: "MUST NOT" change or delete Receive… David Morris
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John Levine
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Dale R. Worley
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Dave Crocker
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Scott Brim
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Hector Santos
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Hector Santos
- Re: SMTP RFC: "MUST NOT" change or delete Receive… David Morris
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Ted Lemon
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John Levine
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Dick Franks
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Hector Santos
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Hector Santos
- RE: SMTP RFC: "MUST NOT" change or delete Receive… Christian Huitema
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Phillip Hallam-Baker
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John Levine
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John C Klensin
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Phillip Hallam-Baker
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John C Klensin
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Randy Bush
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Randy Bush
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Ted Lemon
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John Levine
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John Levine
- Re[2]: SMTP RFC: "MUST NOT" change or delete Rece… mohammed serrhini
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Dave Crocker
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John C Klensin
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Dave Cridland
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Hector Santos
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Michael Richardson
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John C Klensin
- Re: SMTP RFC: "MUST NOT" change or delete Receive… John C Klensin
- Mail System Reliability [was: Re: SMTP RFC: "MUST… Hector Santos
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Phillip Hallam-Baker
- Re: SMTP RFC: "MUST NOT" change or delete Receive… Murray S. Kucherawy