IETF Logo Mail Archive

Re: [dmarc-ietf] Definition of "value" in RFC8601

Alessandro Vesely <vesely@tana.it> Tue, 31 March 2020 17:36 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 968C23A259F for <dmarc@ietfa.amsl.com>; Tue, 31 Mar 2020 10:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lzmTTYZ9Tn7A for <dmarc@ietfa.amsl.com>; Tue, 31 Mar 2020 10:36:54 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F213A259E for <dmarc@ietf.org>; Tue, 31 Mar 2020 10:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1585676211; bh=OVYDJCwEys7tT6pWGgzDkb9PbjMy60Q1x25n3RSHHDw=; l=1198; h=To:References:From:Date:In-Reply-To; b=A3Ja69c4nkNKvtzst269eHs9DXSiPzCjFpS8yZ0xAhzUJvZ5+UE9GzeZmV5ykx/Fm HjZ9YsUptivzKJSkzWloERBuc9nV4Konhyjc8dGh/+8gz+q5Kz0ipBAs9S7FmG/qF7 pO5olISAZujJZafDzfphsHKrigwXdTxW6CeMh8O6CJNEQAf8iDngdnkv3bZEr
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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005E837FB3.0000207A; Tue, 31 Mar 2020 19:36:51 +0200
To: dmarc@ietf.org
References: <CABa8R6tTPAtEyPRSGbWKafZVZ4u8v8sN1VpTpMLQCia2_+5zRg@mail.gmail.com> <20200330212312.341EB16CFEA5@ary.qy> <CAL0qLwZ5c29gNG97gkGBsKW9mauKey+ftSNgqF51Mx=ZV0ABpw@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <f431b254-5241-3f52-03fc-13cac21e5ed4@tana.it>
Date: Tue, 31 Mar 2020 19:36:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwZ5c29gNG97gkGBsKW9mauKey+ftSNgqF51Mx=ZV0ABpw@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/HjoGZpS9qKkmWDIyUrIdOOowY7s>
Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601
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: Tue, 31 Mar 2020 17:36:57 -0000

On Tue 31/Mar/2020 00:38:51 +0200 Murray S. Kucherawy wrote:
> On Mon, Mar 30, 2020 at 2:23 PM John Levine <johnl@taugh.com> wrote:
> 
>> In article <
>> CABa8R6tTPAtEyPRSGbWKafZVZ4u8v8sN1VpTpMLQCia2_+5zRg@mail.gmail.com> you
>> write:
>>>-=-=-=-=-=-
>>>
>>>Hmm, we didn't include this in RFC 8616 either, I could imagine that it
>>>should be punycoded also, though it really depends on whether in 6532 or
>>>5322.
>>
>> This is another mistake in the ABNF in 8601.  The point of 6532 is
>> that with the exception of Message-IDs, any header fields that used to
>> be limited to ASCII can now contain UTF-8 printable characters.
>>
> 
> Does someone have a fix in mind that could be submitted as an erratum?  The
> intent was indeed to make the authserv-id either a plain old ASCII domain
> name or an A-label which doesn't need quoting.  I missed that RFC 6532
> didn't update "value", unfortunately.


That seems to be an RFC 6532 Erratum.

By allowing UTF-8 in MIME tokens, we preserve the spirit of RFC 6532, maintain
that the definition in RFC 8601 is valid, and the headers reported by the OP
turn out to be valid, as they should be, shouldn't they?


Best
Ale
--

v2.23.0 | Report a Bug | By Email