Re: [perpass] Another mail-related proposal

Jim Fenton <> Sun, 18 August 2013 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7FDD11E8224 for <>; Sat, 17 Aug 2013 23:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cGUapjw8Qo9t for <>; Sat, 17 Aug 2013 23:05:58 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by (Postfix) with ESMTP id 1037A11E821E for <>; Sat, 17 Aug 2013 23:05:57 -0700 (PDT)
Received: from [] (localhost []) by (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7I65pBU003229; Sat, 17 Aug 2013 23:05:52 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=supersize; t=1376805952; bh=/DrozxSJwg/bQA7ASMnJLHPrqD0U5f7qpD2kFcjGn5g=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=JpZhCtAy85cZa3L95DFPUViYJRFF+H5TZTWubPIke8ow/DcxjOq248z6gPLE/3umD 6FVRsCBBnlkToYy0Mg6bhEbl9XBz6vQWjhRdVTqqg7FGhmooQOr34Vtf/31eEr42mj rSwhEdqiOBIY+IP77FoLhwUPcgTKdXrhtI1hItSk=
Message-ID: <>
Date: Sat, 17 Aug 2013 23:05:51 -0700
From: Jim Fenton <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Paul Wouters <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [perpass] Another mail-related proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Aug 2013 06:05:59 -0000

On 08/17/2013 02:25 PM, Paul Wouters wrote:
> On Sat, 17 Aug 2013, Jim Fenton wrote:
>> There might be times when I'm interested in sending a message that I'd
>> rather not be in the clear on the wire, and I'd rather that the message
>> bounce rather than be sent in the clear. How about an SMTP option that
>> allows a sender to specify whether the message transmission requires (1)
>> TLS and (2) that the receiving MTA also enforce this option. It could
>> also specify whether the recipient MTA is required to have a certificate
>> trusted (e.g., via trust chain) by the sending MTA, or whether any TLS
>> negotiation (e.g., self-signed cert) is OK.
> I'd argue it the other way. If you publish a OPENPGPKEY/SMIMEKEY record,
> then you ONLY want to receive encrypted email. The problem is trying to
> prevent receiving it, as most email servers are message based and they
> have to accept the full message before rejecting it, at which point the
> cleartext has gone over the network and the NSA has a copy even if you
> don't.
> The postfix TLSA record fails hard for this reason - but that's the
> transport security, not data security.

I was, in fact, thinking about transport security, not data security. 
And I was thinking about being to set the preference on a
message-by-message basis. If I'm sending a message to my neighbors
announcing a block party, I would want the (existing) bias toward
message delivery. OTOH, if I'm sending a message to my accountant, I
might want to make sure it goes over a TLS-encrypted transport.

I'm having more trouble coming up with use cases where I'd want to
reject messages that don't use PGP or S/MIME. The originator of a
message is in a better position to decide whether it contains sensitive
information. And as the receiver you can't generally protect against the
message traversing the network in the clear -- SMTP is often more than
one hop and an earlier hop (or submission) could have been in the clear,
even if you did require TLS for the last hop.