Re: [Jmap] Secdir last call review of draft-ietf-jmap-mdn-16

Barry Leiba <> Wed, 06 January 2021 02:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B7713A046B; Tue, 5 Jan 2021 18:57:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qO8B3u2XFxlq; Tue, 5 Jan 2021 18:57:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F4B33A044A; Tue, 5 Jan 2021 18:57:42 -0800 (PST)
Received: by with SMTP id h205so3396295lfd.5; Tue, 05 Jan 2021 18:57:42 -0800 (PST)
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=/v3fpY9vMZLeAlGjJr13VEJtKXsmWn4fRROoYhd5i/E=; b=SOxMLhiyEIY7ZO1B1K6bI1G03UuqChzmTYxP3EfmrPFC+OvydzwLZGCwizzcJ+1lm6 khXyaoVhEwOy+bT3khLHjIaJmJkPcLHNtuhmT6GtZNjLRfiC7d10tVQyXw5vANpyzige 7MhFLluANLQGJ742a0A0KY4xcPPGvgncznc7wvcYlC8uqHdbMaj7wVqQRvuWyPubzAC5 4narxPubYTj6dkgWb9w9C81n2T3wE+weMIOQFmdZ9UXW6qHbODAqBXASYcnJeZEjHi2c noW626A8j5CqfC8VqP025+orlhcl9PgFtXx1VKdCioRKnIQW/RGi9BZ6mnbVzhpnpBVr 3GGg==
X-Gm-Message-State: AOAM530EoTplNx4rXuquxByEtUIkfAISMBvuOB72YdxsZPwAiLZ+pV3y 7h+ls6B9ukZ0Jf3ywW88rfZ6nX4moDHc9VCf5mA=
X-Google-Smtp-Source: ABdhPJxpAr6TPWoxzWRKYLFOJb7kucZUGOKayRtuijV9W20bzf2qqU2BbpZIPJ67rGnT1RC9qUI0vsgbEe5jfzQVrWU=
X-Received: by 2002:a05:651c:28d:: with SMTP id b13mr1195248ljo.75.1609901860171; Tue, 05 Jan 2021 18:57:40 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Tue, 5 Jan 2021 21:57:29 -0500
Message-ID: <>
To: Daniel Franke <>
Content-Type: multipart/alternative; boundary="0000000000007fb36105b8327caa"
Archived-At: <>
Subject: Re: [Jmap] Secdir last call review of draft-ietf-jmap-mdn-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2021 02:57:47 -0000

Daniel, thanks for the review.  And yes, MDNs themselves, no matter how
they conveyed, are privacy-intrusive.  That’s why I have them disabled in
my user agent, and most, if not all standards-compliant MUAs allow that.

And that’s not accidental: it actually is written into the MDN spec, RFC
2298.  From Section 2.1:

   While Internet standards normally do not specify the behavior of user
   interfaces, it is strongly recommended that the user agent obtain the
   user's consent before sending an MDN.  This consent could be obtained
   for each message through some sort of prompt or dialog box, or
   globally through the user's setting of a preference.  The user might
   also indicate globally that MDNs are never to be sent or that a
   "denied" MDN is always sent in response to a request for an MDN.

There’s more there, as well, and I think it covers things reasonable well,
even if it doesn’t explain what the threats are.  If we should ever do an
update of the MDN spec, we would definitely add that.

Barry, ART AD

On Tue, Jan 5, 2021 at 9:41 PM Daniel Franke via Datatracker <> wrote:

> Reviewer: Daniel Franke
> Review result: Ready
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
> This document's Security Considerations section is appropriately brief
> because
> it doesn't introduce much in the way of new ones: the security model for
> MDN isn't essentially different from the security model for the analogous
> functionality. But had I reviewed RFC 8098, I would have urged some
> changes to
> the Privacy Considerations section of that document. It's not that
> anything is
> wrong or overlooked, but its emphasis is odd. It focuses mostly on leakage
> of
> impersonal details like OS version and network topology, with nothing but a
> parenthetical mention given to the significant personal intrusion of
> monitoring
> message read times. Every abusive boss knows this trick: send your
> subordinates
> an email at 5:00 AM on Saturday and watch when the delivery receipts come
> in. I
> wish that something in the corpus of MDN-related RFCs would do a better
> job of
> acknowledging this, even if this one in particular is not the most
> appropriate
> place for it.