Linus Nordberg linus@nordberg.se writes:
We want a way of charging lots of hash cash for accepting keys. Accepting as non-tentative, that is. We also want accepting of keys to depend on other criterias. But this is all policy.
What should the draft say and what are the ideas on how to implement some of the foreseeable policies?
There are several questions which must be answered.
1. How are MTA:s identified? That's section four of the draft, I really appreciate comments on that.
2. If you want hash cash challenges outside of the mail transaction, how should the challenge string be constructed?
But I'm not yet conviced the large one-time payment need be explicit in the protocol. Let me think loud...
Perhaps it works just as well to charge a large amount the first few times any given MTA wants to send email? (The theory is that if a new MTA is highly abusive to it's environment, it is likely to be shut down within a few days). And then the new MTA's are also the ones you're not sharing keys with.
Say you have the following policy:
1. Sending MTA does not share a key with you: => Challenge difficulty 10 minutes cpu time.
2. Sending MTA shares a key with you, and uses it properly to authenticate itself. However, the key is not trusted by your local receiver: => Challenge difficulty 30 seconds of cpu time.
3. Sending MTA shares a key with you, authenticates porperly, and key is trusted by local user: => No challenge.
Does that make sense to you? Do you see any advantage of an additional charge for the key exchange?
One simple consequence is that in the mail transaction, the client should tell the mailserver which keyid it is going to use before asking for a challenge (and the server should remember it when the client comes back).
/Niels