mouss wrote:
- The x-cr-hashedpuzzle header contains the recipients. There is a
serious privacy issue.
- the algorithm isn't open. If every company starts adding proprietary
headers, we will no more have a place for the body.
Followup: I've recently discovered that both of these are non-issues.
First, as others have pointed out, the algorithm is quite open:
http://www.openspf.org/caller-id/csri.pdf
Second, as for the recipients, they are in there, but in the case of
BCC'ed recipients (where the privacy issue exists), the standard calls
for a completely separate message to be generated, with its own hashed
puzzle, for each BCC recipient. The To: and Cc: recipients can all share
one message, as there's no privacy issue because those addresses are
already readable in their respective headers. This is documented in
section 11.5 of the spec above.
"Dealing with BCC message delivery warrants special attention in order
to avoid inadvertent information leakage.
Specifically, a message containing a puzzle solution computed on behalf
of a BCC’d recipient SHOULD be a
bifurcated copy of the original message that is delivered to that
recipient alone; in the original message, the
HashedPuzzle: header targeted at the BCC’d recipient MUST be omitted."
So, it's prohibited by the spec to include a HashedPuzzle: header for a
BCC recipient in a message sent to anyone but that BCCed recipient.
Generating the separate message is optional, ie: you can opt to not
generate puzzles for BCC recipients at all and still be in spec, but
controlling where such headers based on BCCs are sent is not optional.