I've been thinking about this. It might be useful to offer a plugin implementing this hashcash, since it'd offer a good way to come up with an unforgeable FORGED_MUA_OUTLOOK rule.
However, we'd have to be sure that the CSRI algorithm really is sufficiently open, and not patent-encumbered, since this *is* MS we're talking about :( --j. Matt Kettler writes: > 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.
