[apps-discuss] Stanzas of trace fields, was Adoption of draft-kucherawy-received-state

Alessandro Vesely <vesely@tana.it> Fri, 20 January 2012 17:39 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2703121F852D for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 09:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.624
X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZzY1eMyRYIZ7 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 09:39:14 -0800 (PST)
Received: from wmail.tana.it (mail.tana.it []) by ietfa.amsl.com (Postfix) with ESMTP id 018A621F8523 for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 09:39:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327081152; bh=X3bYKVBVlcSRXPgjeFvPMVZYL0S5+C+QHBCjNojb8NY=; l=2842; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WHc0gQhsMP65LuBz5ShykNtJBBs2OTS/JzASgUhi8NOdw8wfz3arPcrsoOOUghgGH yu3IokEnLZediBwyPwQsIsCwkX35sQ/c6OY7o5PZLeo8RqUMC2LMqlOfJXdDUo7jyZ ghxXjjpoxbAN/DW4YCk7h9V3faUVRqDWUjM+Q7Y8=
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 20 Jan 2012 18:39:12 +0100 id 00000000005DC048.000000004F19A6C0.00002B73
Message-ID: <4F19A6C0.4040602@tana.it>
Date: Fri, 20 Jan 2012 18:39:12 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[]> <01OAYHXGQ9VO0137RD@mauve.mrochek.com>
In-Reply-To: <01OAYHXGQ9VO0137RD@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Stanzas of trace fields, was Adoption of draft-kucherawy-received-state
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2012 17:39:15 -0000

(Subject changed according to topics separation)

On 19/Jan/12 12:44, Ned Freed wrote:
> Sieve is actually an example of this. Sieve can perform tests on
> all occurances of a given field or it can be restricted to look at
> the first, second, Nth, N-1th, etc. occurance. So as long as you
> have some idea of how many Received: fields are added prior to
> delivery in a given environment (and you usually do), you can write
> tests that check the correct field or fields and don't get confused
> by stuff provided by stuff outside the administrative domain (which
> is inherently unreliable).
> But there's no way to test something like "the Foo: field that
> appears after the Nth Bar: field". And an extension that does that
> is going to be very, very ugly, no matter how you slice it. And
> that ugliness is going to make using such an extension quite
> problematic, even for fairly experienced script constructors.

Good point.  However, we already have that situation: see e.g.
(Hey, I did get Murray's approval before posting that :-)

Perhaps, "the Foo: field of the Nth trace stanza" is easier.  We
should just convene that "Received:" fields delimit trace stanzas.

Of course, all the RFCs that mention "trace header fields" say that
these go at the top of the header.  Some of them explicitly mention
"Received:" (quotes below), but also RFC 5322 and RFC 5518 obviously
imply such positioning if we assume that "Received:" is always
present.  Thus, it seems feasible to introduce this concept, in one of
the trace- I-Ds, perhaps?

Quotes (emphasis added):
RFC 4408:
 The Received-SPF header field is a trace field (see [RFC2822] Section
 3.6.7) and SHOULD be prepended to the existing header, above the
 *Received*: field that is generated by the SMTP receiver.

RFC 5436:
                                 If the implementation retains the
 "Received" fields from the triggering message (see above), the "Auto-
 Submitted" field MUST be placed above those "*Received*" fields,
 serving as a boundary between the ones from the triggering message
 and those that will be part of the notification message.

RFC 5451:
     On the presumption that internal MTAs are fully compliant with
     Section 3.6 of [MAIL], and the compliant internal MTAs are using
     their own host names or the ADMD's DNS domain name as the
     "authserv-id" token, the header field proposed here should always
     appear above a *Received*: header added by a trusted MTA.

RFC 6376:
  INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this
  is to insert the DKIM-Signature header field at the beginning of
  the header block.  In particular, it may be placed before any
  existing *Received* header fields.  This is consistent with treating
  DKIM-Signature as a trace header field.