Re: [perpass] Another mail-related proposal
Jim Fenton <fenton@bluepopcorn.net> Sun, 18 August 2013 06:05 UTC
Return-Path: <fenton@bluepopcorn.net>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id E7FDD11E8224 for <perpass@ietfa.amsl.com>;
Sat, 17 Aug 2013 23:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGUapjw8Qo9t for
<perpass@ietfa.amsl.com>; Sat, 17 Aug 2013 23:05:58 -0700 (PDT)
Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net
[IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with
ESMTP id 1037A11E821E for <perpass@ietf.org>;
Sat, 17 Aug 2013 23:05:57 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by kernel.bluepopcorn.net
(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; d=bluepopcorn.net;
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: <5210643F.8030709@bluepopcorn.net>
Date: Sat, 17 Aug 2013 23:05:51 -0700
From: Jim Fenton <fenton@bluepopcorn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Paul Wouters <paul@cypherpunks.ca>
References: <520FE08B.80005@bluepopcorn.net>
<alpine.LFD.2.10.1308171723400.14413@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1308171723400.14413@bofh.nohats.ca>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org
Subject: Re: [perpass] Another mail-related proposal
X-BeenThere: perpass@ietf.org
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. "
<perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>,
<mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>,
<mailto:perpass-request@ietf.org?subject=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. -Jim
- [perpass] Another mail-related proposal Jim Fenton
- Re: [perpass] Another mail-related proposal Paul Wouters
- Re: [perpass] Another mail-related proposal Jim Fenton
- Re: [perpass] Another mail-related proposal Randy Bush
- Re: [perpass] Another mail-related proposal Dan Schlitt
- Re: [perpass] Another mail-related proposal Jim Fenton
- Re: [perpass] Another mail-related proposal Stephen Farrell
- Re: [perpass] Another mail-related proposal Jim Fenton
- Re: [perpass] Another mail-related proposal Yoav Nir
- Re: [perpass] Another mail-related proposal Randy Bush
- Re: [perpass] Another mail-related proposal Jim Fenton
- Re: [perpass] Another mail-related proposal Jim Fenton
- Re: [perpass] Another mail-related proposal Randy Bush
- Re: [perpass] Another mail-related proposal Randy Bush
- Re: [perpass] Another mail-related proposal Jim Fenton
- Re: [perpass] Another mail-related proposal Randy Bush
- Re: [perpass] Another mail-related proposal Jim Fenton