Re: [plasma] why not web portal mail?

Trevor Freeman <> Tue, 12 April 2011 22:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C145FE087D for <>; Tue, 12 Apr 2011 15:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0jfYwiU1IefN for <>; Tue, 12 Apr 2011 15:52:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C6EFE091B for <>; Tue, 12 Apr 2011 15:52:26 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 12 Apr 2011 15:52:25 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 12 Apr 2011 15:52:25 -0700
Received: from ([fe80::7c94:4036:120:c95f]) by ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.01.0218.012; Tue, 12 Apr 2011 15:52:25 -0700
From: Trevor Freeman <>
To: Phillip Hallam-Baker <>
Thread-Topic: [plasma] why not web portal mail?
Thread-Index: AQHL+Ug51oJEPZwodEWIarS6m5uzOpRa0X0w
Date: Tue, 12 Apr 2011 22:52:24 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D339DC3C2DFM1412exchange_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [plasma] why not web portal mail?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Apr 2011 22:52:29 -0000

Policy does not distinguish in what form the data is held. So information persisted in email is subject to the same policy as the same information persisted in a word document.

Yes we have to bind data to some set of policies. The semantics for email and documents are the same.

Overall the Alice case you cited is too simple. A more realist example is

Alice has some data and wants to apply policy X and Y to her data
Bob has some data and wants to apply policy Z to his data

Policies X, Y and Z each defines a set of authorized recipients.

Alice and Bob's data had become comingled so now policies X Y and Z have to be enforced.

In an ideal world we would want to identify Alice's and Bob's data and bind it to its respective polices.

In a less than perfect world we may enforce access at the container level which is an incremental improvement on what we have today.

From: Phillip Hallam-Baker []
Sent: Tuesday, April 12, 2011 12:31 PM
To: Trevor Freeman
Cc: Leif Johansson;
Subject: Re: [plasma] why not web portal mail?

If we consider the Word, Excel and Diplomatic cables examples, the data is static and to be controlled under a policy regardless of what channels it might be transferred or transmitted through.

The protocol requirement here in my view is to enable applications to determine how to apply the security policy identified as X to the data object Y.

On Tue, Apr 12, 2011 at 2:41 PM, Trevor Freeman <<>> wrote:
If you consider XMPP case it is easier because there is no expectation of data persistence. It's a synchronous protocol where all parties are online together exchanging information and that information is not persisted one the session is ended.

-----Original Message-----
From:<> [<>] On Behalf Of Leif Johansson
Sent: Tuesday, April 12, 2011 7:21 AM
Subject: Re: [plasma] why not web portal mail?
Hash: SHA1

On 04/06/2011 09:33 PM, Trevor Freeman wrote:
> Stephen Farrell asked why not use Web portal mail? Why do we need to develop plasma?

Maybe that question is easier to answer if we consider plasma for XMPP and not just for email. There are important differences between XMPP and email that make it much more challenging to build web-only versions of the XMPP.

       Cheers Leif
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

plasma mailing list<>
plasma mailing list<>