x-cr-hashedpuzzle

[Michael Scheidell]

anyone looked at x-cr-hashedpuzzle?
(its the strange, 'hash cash', 'postage stamp' that Outlook 11+ adds to
emails it thinks might be blocked as spam)

What about a plugin to decode, score, validate it?
What about calculating it on outbound emails?

Would that require a license from Microsoft do you think?
--
Michael Scheidell, CTO
Main: 561-999-5000, Office: 561-939-7259

*| *SECNAP Network Security Corporation

Winner 2008 Technosium hot company award.
www.technosium.com/hotcompanies/ <http://www.technosium.com/hotcompanies/>

_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(tm).
For Information please see http://www.spammertrap.com
_________________________________________________________________________

[mouss]

Post by Michael Scheidell
anyone looked at x-cr-hashedpuzzle?
(its the strange, 'hash cash', 'postage stamp' that Outlook 11+ adds
to emails it thinks might be blocked as spam)
What about a plugin to decode, score, validate it?
What about calculating it on outbound emails?
Would that require a license from Microsoft do you think?

a license for what?
/x-cr/ REJECT Unacceptable header. Please upgrade your system.

[Michael Scheidell]

Thank you, as always, you have been !extremely helpful.
So, your proposal is to block all email from all modern outlook clients.
Brilliant plan. No, I don't worship MS, but I live in reality.

We should just block anything with the Thread header, X-Mailers with Outlook
in it, any outlook/ exchange generated message id's and any of the twits
that inject Outlook headers from their unix boxen that say things like
Warning Friends Don't let Friends Drive Outlook

Anyone have any HELPful suggestions?
How to validate it? If it is a hash cash type score, then it could be used
to validate senders and since it is 'expensive' to vend, it would almost
eliminate the possibility that it is bulk.

One of the fields is the number of recipients, so if you want to eliminate
bulk email signed by hashedpuzzle, you could read that value.

[mouss]

Post by Michael Scheidell
Thank you, as always, you have been !extremely helpful.

why attack me?

Post by Michael Scheidell
So, your proposal is to block all email from all modern outlook clients.
Brilliant plan. No, I don't worship MS, but I live in reality.

sorry, I'm not as brilliant as you are.

Post by Michael Scheidell
We should just block anything with the Thread header, X-Mailers with Outlook
in it, any outlook/ exchange generated message id's and any of the twits
that inject Outlook headers from their unix boxen that say things like
Warning Friends Don't let Friends Drive Outlook

Did I say so? I only spoke of the x-cr-mumble headers.

- 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.
- ...

Post by Michael Scheidell
Anyone have any HELPful suggestions?
How to validate it? If it is a hash cash type score, then it could be used
to validate senders and since it is 'expensive' to vend, it would almost
eliminate the possibility that it is bulk.
One of the fields is the number of recipients, so if you want to eliminate
bulk email signed by hashedpuzzle, you could read that value.

if you can't validate the header, you can't trust it.

[Matt Kettler]

Post by mouss
if you can't validate the header, you can't trust it.

And the whole point of the Michael's original message was to find out
if you can validate it, therefore trust it.

A simple "I don't think you can validate that" would have been
appropriate, but suggesting he use it as a block criteria is completely
contrary to his intentions.

[mouss]

Post by Matt Kettler

Post by mouss
if you can't validate the header, you can't trust it.

And the whole point of the Michael's original message was to find out
if you can validate it, therefore trust it.
A simple "I don't think you can validate that" would have been
appropriate, but suggesting he use it as a block criteria is
completely contrary to his intentions.

well, I forgot the smileys and I'm sorry for that. but even assuming
that my post was completely wrong, dumb, stupid, inappropriate, it
doesn't justify a personnal attack.

Note that in the case of outbound mail, I am concerned about the privacy
issue, and the block is not completely silly. Removing the headers may
be a better solution if that breaks nothing, but I am generally
reluctant to altering mail. I agree that blocking inbound mail because
of the x-cr- headers is not appropriate _if_ this becomes widely used.

[Matt Kettler]

Post by mouss
- 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.

[Justin Mason]

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.

Post by Matt Kettler

Post by mouss
- 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.
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.

[mouss]

Post by Justin Mason
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 :(

Indeed. I yet to see the IP part of the story. after all, callerId was
"open" too...

and I'll add few points:

- As Hamman and Matus said, and as already known, $postage is yet to be
proven effective in a zombie world. one thing that is known is that it
is unfair for legitimate bulkers. It is also globally suboptimal.

- If BCC results in separate mail, then an MSA will get more mail. not
critical, but this is not optimal. Also, there will be multiple
responses of the MSA. given that it is already confusing when an MSA
rejects few recipients (domain doesn't exist, .. etc), this will only
add to the confusion ("should I resend to everybody or only to few
people"...).

- if this becomes widely used, there is a risk that organizations will
require it, or at least setup different policies based on that. This
gives an unfair advantage to MS products. (after all, if everybody sends
"MS word" documents, it's because everybody believes that "everyboyd
uses MS word"...).

- outlook (and exchange) is a large pce of software. It had serious
vulnerabilities in the past. It is thus legitimate to think that there
may be serious bugs in the x-cr-* implementation. It would have been a
little better to implemnt the hash stuff in a standalone service (proxy,
...).

- Is there a problem with hashcash? why didn't MS chose it? If there's a
problem, it would be good to disclose it.

[Matus UHLAR - fantomas]

Post by mouss

Post by Justin Mason
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 :(

- If BCC results in separate mail, then an MSA will get more mail. not
critical, but this is not optimal. Also, there will be multiple
responses of the MSA. given that it is already confusing when an MSA
rejects few recipients (domain doesn't exist, .. etc), this will only
add to the confusion ("should I resend to everybody or only to few
people"...).

this can result in MUA eating more CPU when using Bcc:, thus lowering of
Bcc: usage. Of course it will cause the same problem to bots, but which
bots use Bcc? imho this would also cause more problems to users using Bcc
than bots...

[no-1]

http://www.openspf.org/caller-id/csri.pdf Chapter 11, pages 37 to 45
inclusive

[t***@aol.com]

http://www.openspf.org/caller-id/csri.pdf Chapter 11, pages 37 to 45 inclusive


________________________________________________________________________
More new features than ever. Check out the new AOL Mail ! - http://webmail.aol.com

[t***@aol.com]

http://www.openspf.org/caller-id/csri.pdf Chapter 11, pages 37 to 45 inclusive


________________________________________________________________________
More new features than ever. Check out the new AOL Mail ! - http://webmail.aol.com

[h***@t-online.de]

Post by t***@aol.com
http://www.openspf.org/caller-id/csri.pdf Chapter 11, pages 37 to 45 inclusive

interesting reading :)
I believe that, in a time where zombie armies powered by quad-core cpus pour spam over the
internet, compute-bound puzzles would not really be a hurdle for the spammers

Wolfgang Hamann

[Matus UHLAR - fantomas]

Post by t***@aol.com
http://www.openspf.org/caller-id/csri.pdf Chapter 11, pages 37 to 45 inclusive

interesting reading :) I believe that, in a time where zombie armies
powered by quad-core cpus pour spam over the internet, compute-bound
puzzles would not really be a hurdle for the spammers

I agree. Although some people may notice that their computer works hard, the
chance is quite small. lusers tend to ignore such problems. That's the
reason why I haven't turned on the hashcash plugin