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

Damian Lukowski <rfc@arcsin.de> Wed, 01 April 2020 23:10 UTC

Return-Path: <rfc@arcsin.de>
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 B59BC3A12BD for <dmarc@ietfa.amsl.com>; Wed, 1 Apr 2020 16:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=arcsin.de
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 WTBZoqNq__FK for <dmarc@ietfa.amsl.com>; Wed, 1 Apr 2020 16:10:08 -0700 (PDT)
Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823973A12B9 for <dmarc@ietf.org>; Wed, 1 Apr 2020 16:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585782605; x=1587597006; bh=W/6GkNH7mgSQCe95jrI7oTkGxLIjO+bwnj4 CICJSfkg=; b=oC8HfiexY5cA1a9g4pk+4dZg4Ztu4EIGMwKWcp1cUYrCgmhgwaH GGTUYghYHIZlhdgCw3ac8GFGpIiuFAA7RJpMewIU3FZAG+a89Z9b9aNMwxXaPxcP hC7p03OZrnOPgSU/BbhJOx+zHwer8XaWbbc9/p8/FdQ2zbQGSaoQXaNI=
X-Amavis-Category: scalar.arcsin.de; category=CleanTag
To: dmarc@ietf.org
References: <20200401210549.AFA6C16E323F@ary.qy> <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de>
From: Damian Lukowski <rfc@arcsin.de>
Message-ID: <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de>
Date: Thu, 2 Apr 2020 01:10:46 +0200
MIME-Version: 1.0
In-Reply-To: <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/V6wbY-St_GqAXCjZk0jCNAU795Y>
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: Wed, 01 Apr 2020 23:10:11 -0000

>>> It's the one you found.  If the authserv-id has a non-ASCII UTF-8 character,
>>> it's invalid under 5321 and valid under 6531.
>> I thought we established that as soon as the authserv-id has non-ASCII
>> UTF-8 characters, the mail is automatically - by definition - a 6531 mail:
> Sorry if it seemed like I said that.  It's either a potentially valid
> EAI message or a definitely invalid ASCII message.  If your system
> doesn't handle EAI mail, it's invalid.

Let's say the system is capable of handling EAI mail. RC6531 sec 3.6:

> An SMTPUTF8-aware SMTP client or server
> that requires accurate knowledge of whether a message is
> internationalized needs to parse all message header fields ...

If I understand the section and your new authserv-id definition
correctly, an EAI capable system can process plain-ASCII messages, such
that with then definition of

> authserv-id = sub-domain *("." sub-domain)
>    ; Where sub-domain is imported from 5321 for ASCII mail
>    ; and 6531 for EAI mail.

, sub-domain comes from RFC5321.

If that is so, then this looks to me like a dependency cycle.

To decide for an authserv-id whether to pull sub-domain from 5321 or
6531, one needs to know if the message is internationalized. But to
obtain that information, one must have parsed all message header fields,
per 6531 sec 3.6, including A-R, that is still waiting to be parsed.