linus at nordberg.se
Thu, 21 Oct 2004 23:05:50 +0200
firstname.lastname@example.org (Niels Möller) wrote
21 Oct 2004 15:49:11 +0200:
| 1. How are MTA:s identified? That's section four of the draft, I
| really appreciate comments on that.
Perhaps keys should be associated with the domain part of envelope
recipient and not with two "MTA names"? I'm not sure if this solves
any problems, I just came up with it when going through some of the
possibilities. Some thoughts follow.
Associating key to sending MTA (speaking of an MTA as a program
running on a single host) is not fruitful because a sending MTA may
serve multiple domains. It also poses great trouble with asymmetry
when sending and receiving MTA are separated, at least as long as we
consider mail going both ways to be a sign of mutual trust.
Or is it that I haven't grasped the concept of user policies yet?
Argh, this is hard!
| 2. If you want hash cash challenges outside of the mail transaction,
| how should the challenge string be constructed?
Are you referring to the i'll-be-back-later-with-the-answer thing?
| But I'm not yet conviced the large one-time payment need be explicit
| in the protocol. Let me think loud...
The protocol should allow it, that's all.
| 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?
Criteria for transition from 1 to 2 is still that mail has been going
both ways between the MTA:s? As an alternative, a large payment might
| 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).
When speaking of client coming back, we mustn't forget to demand that
the client connects to the very same MTA the second time. We don't
want to replicate the database with outstanding challenges between all
MX hosts for domain. The time span might be short.