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

Brandon Long <> Thu, 02 April 2020 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5F053A1BBB for <>; Thu, 2 Apr 2020 16:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id we2N6By70E2r for <>; Thu, 2 Apr 2020 16:00:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA98B3A1BB3 for <>; Thu, 2 Apr 2020 16:00:24 -0700 (PDT)
Received: by with SMTP id o3so3756098vsd.4 for <>; Thu, 02 Apr 2020 16:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8CEkjPUfst48h9Msnipp9bXfOkpF+EojlY0Jt2Vhjfo=; b=m9OjycTTbfuSdwetiquA+/MHLZYQZONpbQKesCHWoTVyhi9mJ0xO1cTg7GqKKqtgxE MLykmQyghKMyPnRkziJN6q/VrF1Uw2zxp0YsbHE0H0kDrEgOvq/Ko1JtaU/AtA0riwIm 8tBiMrUKtYvzHk1In+JQBaq0Q9AU6+Hc1i9ibv6LCqfnFFRnLRlqok71CBVrXixmKpzK 59ejlPW6z7tL1rwwd2G04LIE3e21jab8IVNINk1cIvY3+ZYUVc5i9JL7qfpDd8Rsm2aN KpRe0jh5wS9yExf4VUuBOWG31PYil4AjcXL0nkIwIXwyZx/DbfuRlLUKPuCXm6rGGOOY W/aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8CEkjPUfst48h9Msnipp9bXfOkpF+EojlY0Jt2Vhjfo=; b=fLJ8oUE5YpX6knZsGvt3722fB/rFDUO0nO2s5t33rfTqQgVr6XovDeT95oAoeJXNMw d4f1XrFblfvRwqAjzJ54uZ4HVoHSQRGZjVweIXo/WrXnGAU2CR5ds798cuDExnEb+WV1 iZAKO4o70/Rnx3ielo5DCwFAY7BZishvITiPT2SBVjMeGBbF6bbFz6Fi26QaXjZsWDw9 wJFoQi7sDX/AAXNMe2vhdHEWTLiwMXfvt2rHDTKtacGb3jbtS+CA5X5Uab7sE0SnHAMA HIG6/rajCgdLanLNy76E+39IHKohTCCSOieJxSMBIA/97CPBwan6tRffP6QW736K97Bu JdkQ==
X-Gm-Message-State: AGi0Pua2glh9Ro5icCN6+g+r7mYUD+TkOeNbSWNRnc98Qv2lgx4ttpcB OJYs/VqOY0eVMNC75Fxtp11AQoP0wrm6uJ4UZ0xC
X-Google-Smtp-Source: APiQypIroqlB2vcZRO7FtBREaEMiCnnLaJwAhpRjCuTV/+rGlZh2J03ezXyUreHp4q1JAz9qvxOWJOFRSLAUVI/VTjw=
X-Received: by 2002:a67:7d93:: with SMTP id y141mr4043243vsc.124.1585868423214; Thu, 02 Apr 2020 16:00:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <20200402003211.0B8AA16E4B5A@ary.qy>
In-Reply-To: <20200402003211.0B8AA16E4B5A@ary.qy>
From: Brandon Long <>
Date: Thu, 2 Apr 2020 16:00:10 -0700
Message-ID: <>
To: John Levine <>
Cc: IETF DMARC WG <>, Damian Lukowski <>
Content-Type: multipart/alternative; boundary="0000000000000741f405a256c405"
Archived-At: <>
Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Apr 2020 23:00:27 -0000

On Wed, Apr 1, 2020 at 5:32 PM John Levine <> wrote:

> In article <> you write:
> >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.
> In systems that keep ASCII and EAI mail separate, that info will be in
> the metadata, whether it arrived in an SMTP session with the SMTPUTF8
> option.

Does anyone implement it that way?

We just upgraded our parser to handle EAI mail, and the parser returns
requested data
in UTF8, decoding 5322 mail or going straight from 6532 mail as necessary,
specific accessors needing to know what the possible encodings could be.
We then check
when we go to send mail whether we should specify SMTPUTF8 on the output..
as for input...

We see plenty of mail transferred without SMTPUTF8 that contains UTF8 (or
8-bit characters, but the majority of that became UTF8 probably close to a
decade ago), and we
just handle it.

Unfortunately, everybody thinks they can just make their own emali messages
because its a text-like
format, and they're very often wrong.