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

Damian Lukowski <rfc@arcsin.de> Wed, 01 April 2020 21:25 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 EF6353A0A15 for <dmarc@ietfa.amsl.com>; Wed, 1 Apr 2020 14:25:53 -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 6yMCoDvq7Q9h for <dmarc@ietfa.amsl.com>; Wed, 1 Apr 2020 14:25:52 -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 0151E3A0A1C for <dmarc@ietf.org>; Wed, 1 Apr 2020 14:25:51 -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= 1585776349; x=1587590750; bh=MZYCE8SoHNS0JJ8o5F6Ns8jNJDYeJ9dBUKE fp8EQWC4=; b=f5LzjjUysPDd5tAGC0iLV0USKg53+MLPsqz4yjK4OnB66+HpYzD FcHihzAeHovymgKUqTRbW5Mtb/FSlWz26ofA6inJ2NMPUnISxGQBJD742tjwQCo1 gOn1W+rSFQb4SJxN61Ex0D+F7RPKyUxdje/LFy80mwNs3i5l0nHRCNcE=
X-Amavis-Category: scalar.arcsin.de; category=CleanTag
To: dmarc@ietf.org
References: <20200401210549.AFA6C16E323F@ary.qy>
From: Damian Lukowski <rfc@arcsin.de>
Message-ID: <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de>
Date: Wed, 1 Apr 2020 23:26:30 +0200
MIME-Version: 1.0
In-Reply-To: <20200401210549.AFA6C16E323F@ary.qy>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/rEFUGu5dEoIC6waZaGylqSlf03A>
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 21:25:54 -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.

Ok, that is definitely an external factor, isn't it? The information, if
the system which processed the email, handles EAI, is not contained
within the A-R header. Is the information even available in the DATA
portion of an SMTP transaction? Can one look inside an .eml file and
decide if that email has been processed by an EAI capable system?

> If there are bytes with the
> high bit set but they're not a UTF-8 sequence, or they're not a UTF-8
> character allowed in an authserv-id it's invalid even if you handle
> EAI.

That part is fine, because this is decidable from the A-R header itself.