Re: [dmarc-ietf] [] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Thu, 11 April 2019 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C376D1205FB; Thu, 11 Apr 2019 10:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y2fX4TFyRm06; Thu, 11 Apr 2019 10:52:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED4A01205B5; Thu, 11 Apr 2019 10:52:14 -0700 (PDT)
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x3BHq7ip008143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 13:52:10 -0400
Date: Thu, 11 Apr 2019 12:52:07 -0500
From: Benjamin Kaduk <>
To: John R Levine <>
Cc: The IESG <>,, Kurt Andersen <>,
Message-ID: <>
References: <> <alpine.OSX.2.21.1904051336300.4382@ary.qy> <> <alpine.OSX.2.21.1904051437500.4382@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.21.1904051437500.4382@ary.qy>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [dmarc-ietf] [] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)
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, 11 Apr 2019 17:52:18 -0000

[consolidating the postscript back in]

On Fri, Apr 05, 2019 at 02:45:33PM -0400, John R Levine wrote:
> On Fri, 5 Apr 2019, Benjamin Kaduk wrote:
> > The whole premise of rigorous specifications is that anyone can jump in to
> > the ecosystem and implement something that interoperates, and in my opinion
> > the current presentation is not very accomodating to such a participant.
> We seem to have a fairly basic disagreement of who "anyone" would be. 
> I'm assuming, and I think the WG is assuming, that the audience for this 
> document is people who are already somewhat familiar with SPF or DKIM or 
> DMARC.  It appears that you believe it is possible to add enough 
> mechanical detail that even someone who knows nothing about them could 
> make these changes.  That seems awfully optimistic.

Well, that wasn't really my intent in making the comment.  Rather, that it
feels sloppy to be so informal.  It may not cause problems here, but on
the other hand, even people who know things can have off days; sloppiness
can also become a habit and creep into places where it does have a real
impact.  I've seen plenty of those even in just one year on the IESG, and
try to exert some general backpressure, though I hope that I limit the
blocking backpressure to cases where it does actually matter.

In this particular case, I said "I would like to discuss" the topic, and we
have had a discussion.  Your and Barry's arguments have convinced me that
no change is needed here, so I will reballot and remove that point, since
the discussion has occurred.

> I don't fault you for not being an SPF or DKIM expert but I really don't 
> think it is useful to add a lot of stuff that any plausible reader already 
> knows.
> Regards,
> John Levine,, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.

On Fri, Apr 05, 2019 at 02:57:55PM -0400, John R. Levine wrote:
> PS:
> >>> Is there any risk that an intermediary will reencode the domain name and
> >>> cause the signature validation to fail?
> >>
> >> No more than there has been all along.  Intermediaries can do all sorts of
> >> bad stuff to mail messages althrough for the most part they don't.
> >
> > Right.  But we don't, say, know of any current implementations that try to
> > canonicalize the representation of the domain name, for example?
> Sure we do, some still replace CNAMEs with the target as described in RFC 
> 1123.  But what does that have to do with internationalized mail?  It 
> sounds like you're thinking that an intermediary will turn U-labels into 
> A-labels or the like, which would require an extremely perverse misreading 
> of the EAI RFCs.
> Again, I don't fault you for not being an EAI expert, but again, this is 
> stuff that anyone working in the area would know.

Well, that's why I am asking questions instead of telling you how to write
the document.  And when you keep making that sort of response to my
questions, it starts to come across like you're asking me to abdicate my
responsibility as an AD to apply faithful review to the documents in front
of the IESG, and instead just trust the experts in the WG to have done the
right thing.  I intend to continue to do my job, and I hope that the
community will support me in that, including by filling the gaps in my
knowledge as relevant.