[Cryptography] prism-proof email in the degenerate case

[Joe St Sauver]

Hi,

<smari at immi.is> commented:

#An alternative I've been considering is having e-mail clients support 
#bouncing messages if they are received for an incorrect envelope 
#address. So you can have an envelope address and a PGP encrypted blob, 
#and when you decrypt that blob there's a new RFC822 with a new envelope 
#address and another PGP encrypted blob. If e-mail clients honor a 
#forwarding agreement on this kind of message, it will be practically 
#impossible to tell who sent the original message and who is the final 
#recipient.
#
#The really hard bit about this is that there are a lot of e-mail clients 
#out there, and getting them all to support this - even optionally - is 
#may take some doing.

-- If you're checking the envelope address, the check really should
be happening on the MTA, not the mail client, because users
typically don't "get" envelope addresses (the don't get the whole
MAIL FROM or EHLO thing)

This makes me think of the extensive and protracted discussions
that the email community has had around SPF/Sender-ID and DKIM.
Nice starting point: http://www.openspf.org/SPF_vs_Sender_ID

-- If you're checking the message body address, that's something
that users DO see (and think they "get") but then the question
devolves to "which address is the 'right' one?" (see the
discussions of "Purported Responsible Address" in RFC4407, just to
get your toes wet)

-- Forwarding issues have dogged SPF for a long time; rewriting is
an option, but that obviously introduces new problems of its own.
(See http://www.openspf.org/SRS if interested)

-- I'll also say that I have real concerns about any protocol that
"bounces" unwanted/unaccepted email (rather than rejecting email at
connect time, while the remote MTA is still connected) because of
the potential for abuse (e.g., mail bounce attacks against innocent
third parties)

Anyhow, just a couple of thoughts on this,

Regards,

Joe