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

Hector Santos <hsantos@isdg.net> Sat, 29 March 2014 18:13 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 D62C21A07F4 for <ietf@ietfa.amsl.com>; Sat, 29 Mar 2014 11:13:16 -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 jZztnWMzII-k for <ietf@ietfa.amsl.com>; Sat, 29 Mar 2014 11:13:15 -0700 (PDT)
Received: from ntbbs.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1A31A07EC for <ietf@ietf.org>; Sat, 29 Mar 2014 11:13:15 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=780; t=1396116784; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xv5+e8kRmHikB1SewI4nfk76/VI=; b=OVaDksRmvF51ISVt0/bs DBII0HkrAA6WvaKECbPESKv4h0hQZrRSzx5JNAqWuTBig6sw2x0uUhVPYBcL9Lq5 1T2bjFHQkp/N0hbSfClb3MFZCDeifNsAwyi2GGvxHPNJEbjYqwW+6upCUiPzzspK dUbrwkdWol4vrlB7C8SdNd8=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 29 Mar 2014 13:13:04 -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 1104245817.8462.5120; Sat, 29 Mar 2014 13:13:03 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=780; t=1396116747; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3+rOGSk 0vvOWvVyD3PN8Z5uS/aL/keF8tHqedfHxYVA=; b=bPkbbtDxs0EJ2lC1iasz8Nw 1rbtQrb0uECxSSqh/4knYEiF/kLiW9Z26+e1x4+cWSB05znh/BE6qP6Vqzorbop5 1hHBMowYq/86jGIf580OLB1BXbd/7haIEVduiL0nKRvv9qsRTh1quRgeW0jmvF9B mvd54U5W3hWlBwFScbyA=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sat, 29 Mar 2014 14:12:27 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 550502600.9.17736; Sat, 29 Mar 2014 14:12:25 -0400
Message-ID: <53370D34.8020605@isdg.net>
Date: Sat, 29 Mar 2014 14:13:08 -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: <mailman.1570.1395964793.2468.ietf@ietf.org> <53366F34.8050501@ageispolis.net> <5336F93D.6000009@isdg.net> <alpine.LRH.2.01.1403291001331.19664@egate.xpasc.com>
In-Reply-To: <alpine.LRH.2.01.1403291001331.19664@egate.xpasc.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/PcILqUcn9zQWWX50FusaYu9qssM
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:13:17 -0000

On 3/29/2014 1:03 PM, David Morris wrote:
>
>
> On Sat, 29 Mar 2014, Hector Santos wrote:
>
> ...
>
>> was pruned.  If there was a support need, you enabled the preservation of the
>> full RFC headers and told the user "try it again."
>
> ...
>> headers. Thats information you certainly don't need 80% (pareto) of the time.
>
> The problem with the "try it again" approach is that there is no assurance
> the failure will repeat. Information lost, is just lost, making end user
> support on the 20% (your number) of the cases where there is a problem
> impossible. Etc.

Sure. No doubt, that these days, as oppose to days where mail volume 
STORAGE was a premium and overhead was pruned, preservation RFC/MIME 
is the first consideration.

Thanks

-- 
HLS