Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03

Alessandro Vesely <vesely@tana.it> Wed, 07 November 2018 12:43 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A340612EB11 for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 04:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 9euViKtC7KHG for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 04:43:01 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36821274D0 for <dmarc@ietf.org>; Wed, 7 Nov 2018 04:43:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541594580; bh=DQXCvDClgMt7r8y2RAJqQsh4RtxltIju9LIzu8f48w0=; l=1357; h=To:References:From:Date:In-Reply-To; b=Ag4dBmxwpIiMyFye+iK5I22/M6Pixo/seeu+jC2Ctr/J6YeNdXSITPUXb4uJdrKJP HxlKMJ1Yf11gpEggR6YEV4VNrHqAfmqWSD3WkEML59OZuM5PGCEPxshp2IArj3kJ8y lvXcXu2DQGuOPJaazqAFFG5SBgZDvmW2gwOQvbM2eMfbKNaDwvrMTg8tP+vGd
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 07 Nov 2018 13:42:59 +0100 id 00000000005DC033.000000005BE2DDD3.000010D2
To: dmarc@ietf.org
References: <154100859354.5360.795312478907721541@ietfa.amsl.com> <CAL0qLwYoPy5FNx4rEW4NOKPHyPjfmW6OCYANnkeFUjjuvZQHrg@mail.gmail.com> <CAGL6ep+sX8sWf=G20gXMmKHAPua82gT+mwBq9cLSr46rC9tApg@mail.gmail.com> <CAL0qLwaeorZD4KphPR15ccPeQ8JcGvH3ADGTqBUeAekTy-QSWw@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <1ee67064-9d9a-5edb-c07c-eaa587e8fcea@tana.it>
Date: Wed, 7 Nov 2018 13:42:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwaeorZD4KphPR15ccPeQ8JcGvH3ADGTqBUeAekTy-QSWw@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ROihmAZTVrNZAZ0hCvJhNYAvlWo>
Subject: Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 12:43:04 -0000

On Mon 05/Nov/2018 05:04:04 +0100 Murray S. Kucherawy wrote:

>> 7.3.  Header Field Position
>>>> This section explains that headers fields are *not* guaranteed to be
>>>> in a specific order. The section then states that "there will be
>>>> *some* indication...">>>>
>>>> Since the order is not guaranteed, what do you expect an implementer
>>>> to take away from this?>>>>
>>> "in the general case" and "but most do not".
>>>
>>> So: Most of the time, you can rely on header field ordering to determine
>>> the sequence of handling.  You are at least certain about whether you can
>>> trust the tail end of that, because you know your own environment from the
>>> ingress point.
>>>
>>>
>> Fair enough; I think it is worth adding this sentence to make it clear.
>>
> Doesn't the last sentence of that paragraph already say exactly that?

I think Rifaat means, literally:

OLD
         Thus, in the general case, there will be some indication of
   which MTAs (if any) handled the message after the addition of the
   header field defined here.

NEW
         Thus, in the general case, there will be some indication of
   which MTAs (if any) handled the message after the addition of the
   header field defined here, because operators know their own
   environment from the ingress point.


That doesn't seem to be a bad change to me.

Best
Ale