I looked at the specifications recently. There is certainly support for concealing the RFC822 From and To headers and the Subject line. There are two sets of metadata to consider:
1) The SMTP routing data (RFC821)
2) The Message headers (RFC822)
People with Outlook 2007 (say) who are happy with it are unlikely to want to spend $350 to upgrade so that they don't get mysterious encrypted messages that don't have sender names or subject lines.
--
Website: http://hallambaker.com/
There are two sets of issues, one is what the specifications say, the other is what the implementations do.
S/MIME does support concealing the RFC 822 header data because it is not used in routing. Only the RFC821 data is used for routing. The RFC822 header data is only used by the email client to decide how to respond.
I have successfully routed several SMTP messages with no RFC822 routing data at all. I plan testing support for 'full wrap' as described in the specs but not for a while. To give a useful answer would require a look at each and every email client including older versions.
The problem then is not how to achieve this particular capability in the specification, it is how to make use of it in a way that does not cause unpleasant user experiences when people have non-compliant software.
People with Outlook 2007 (say) who are happy with it are unlikely to want to spend $350 to upgrade so that they don't get mysterious encrypted messages that don't have sender names or subject lines.
On Mon, Feb 3, 2014 at 10:28 AM, Stephen Kent <kent@xxxxxxx> wrote:
I think the S/MIME tripe wrapping feature may already provide a way to conceal
header info not needed to delivery.
Steve
On 2/1/2014 6:44 PM, Stephen Farrell wrote:
If someone wanted to propose using PGP or S/MIME (aka CMS) formats
to provide closer-to-end-to-end confidentiality protection for email
messages that covered most headers in a way that might get deployment
then I think that would not match your description. I do suspect
that that is not likely to happen.
1. Very much not likely.
2. It's unrelated to the parts of such a service that appear to be the major barriers to large-scale use
3. It's the wrong level of design discussion, at this stage.
If OTOH, we spent a lot of time debating email message origin
authentication then I fully agree with you that we'd just be
distracting ourselves pointlessly.
+1
d/
Website: http://hallambaker.com/