IETF Logo Mail Archive

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

Dave Cridland <dave@cridland.net> Mon, 31 March 2014 07:36 UTC

Return-Path: <dave@cridland.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 6E0F41A0886 for <ietf@ietfa.amsl.com>; Mon, 31 Mar 2014 00:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 31luJiiLXzCk for <ietf@ietfa.amsl.com>; Mon, 31 Mar 2014 00:36:27 -0700 (PDT)
Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 283F11A0793 for <ietf@ietf.org>; Mon, 31 Mar 2014 00:36:27 -0700 (PDT)
Received: by mail-ob0-f175.google.com with SMTP id uy5so8673999obc.34 for <ietf@ietf.org>; Mon, 31 Mar 2014 00:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T00tmHZlzDAysbA/WVHtwgaJrsU6kcY6kbDCp5kcplc=; b=STOHIURSJYVEjYPajVi6CJVvRBojAyhdjsE4i1CpdJPIdMCvS4kNlNbaTEswKsznG0 fKpP+6/Z5nVDE+DwBI0w7/HUx9k0MzWkPoK17ksADe9jTGZMLLvT41YAZd0u8BkJNMuH rceWOb+g8yGVtSUEsDXd17ZviNK4CsZ1Me3NE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T00tmHZlzDAysbA/WVHtwgaJrsU6kcY6kbDCp5kcplc=; b=VTx1xoAjSC16YglbBf9eLU/JjOKCHm5HWqx0BGnWrh3LY6zaoRu+zs8W08bLERPgRI s7C6MexaCitsLIUdkBJ50hh1hH1286ky/rNiIsWcRF72BfPaXF5vWPEkR6+Lu8Gpum1K Ubs2n86GbrD4GoKh+J3oDj76A/l2bqxAZiUTGgua3xKM2G6BZ8A3D0R4wo5C8+QtLJth R4Z1uPCgj5O0gabWlcGBgdBVJmv3MhWuy609wH2G22VqhtRlL0a3ALOmtOQZ4azfcy00 tZmfOc+KV/nPVcfC8Hfhmvvp7ioCvMWsnFDULMNN6oPJNQzPjdaDtwp21F5GPYH0BjPY SEzg==
X-Gm-Message-State: ALoCoQlvgA5vlU5aW+NnWZ8qQxJmzX22/LPfCvZXtaOUCHfTx09m/+fFSihKzRixNFh/8HMMQGGi
MIME-Version: 1.0
X-Received: by 10.182.42.3 with SMTP id j3mr20271799obl.30.1396251383971; Mon, 31 Mar 2014 00:36:23 -0700 (PDT)
Received: by 10.60.58.41 with HTTP; Mon, 31 Mar 2014 00:36:23 -0700 (PDT)
In-Reply-To: <m28urr9rcp.wl%randy@psg.com>
References: <20140330151432.2721.qmail@joyce.lan> <A3DE810811F791EDC532BDFB@JcK-HP8200.jck.com> <m28urr9rcp.wl%randy@psg.com>
Date: Mon, 31 Mar 2014 08:36:23 +0100
Message-ID: <CAKHUCzyznOsDBEi7KYipNrEpKLgBO6MfAqS=g0Nm2dGpbtgMvg@mail.gmail.com>
Subject: Re: SMTP RFC: "MUST NOT" change or delete Received header
From: Dave Cridland <dave@cridland.net>
To: Randy Bush <randy@psg.com>
Content-Type: multipart/alternative; boundary="f46d044786ddc256bf04f5e21b7e"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/YaiDSM3P-38OX-P-W0Y0u3Oqzzw
Cc: John C Klensin <john-ietf@jck.com>, "ietf@ietf.org Discussion" <ietf@ietf.org>
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: Mon, 31 Mar 2014 07:36:28 -0000

On 31 March 2014 00:52, Randy Bush <randy@psg.com> wrote:

> the truth is, i have not used received: headers to authenticate/debug
> [0] since yesterday.  but it's not yet 09:00, so there is still time
> today.
>

I'm assuming you realise that nobody is arguing that all received header
fields be stripped?

The problem I've run into is generally machine [~auto] submitted email,
where the network itself is "sensitive" (let's pretend it's a big bank),
and the administrators don't wish to reveal anything about the network
location of said machine.

The trace fields stripped would be limited to (probably) one - that of the
original {trans|sub}mission. It'll also be (in practise) a constant modulo
the timestamp.

Does this change your point of view? If not, why would knowing about a
machine that's likely on private IP address space or otherwise on an
unrouted network be useful to you for debugging purposes?

If there's a problem with the mail, the big bank can track down what
happened easily enough, and you can point your finger at the correct big
bank.

Dave.

v2.23.0 | Report a Bug | By Email