Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (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"?
That's one possibility; identify the sending MTA with the domain part of the envelope addresses. It makes sense for the receiving MTA. But I think we need something different för the sending MTA (consider forwarding/relaying; then the envelope sender address is unrelated to the sending MTA).
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.
Hmm. I think the reason we need an id for the sending MTA is as follows:
1. Say a@a.com sends email to b@b.com for the first time. They exchange a key k, and now a.com knows that this key is associated with b.com, and it will try to use it next time it sends mail to b.com.
The problem is the reply; how can b.com know that it should use this key for email to a.com?
2. The sender MTA id is also used for XHASHADVISE: There may be several independent machines receiving mail for the same domain, not sharing key databases. Sending MTA:s will have several keys for this domain. Each time it connects, it uses XHASHADVISE, and the server will tell it the right keyid to use. For the server to be able to do that, it needs to know who it is talking to. (In case sending and receiving domains have n independent machines each, there will be n^2 keys, and XHASHADVISE will list n of them.
I like the idea to have bidirectional exchange of mail automatically imply some level of trust. But it doesn't work in the asymmetric case. Perhaps we have to give up on that, or at least provide some alternative.
With unidirectional keys, there is less need for sender MTA id, but (2) may still apply.
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!
The user table determines which keys are trusted when receiving mail for a particular user. The automatic mechanism just modifies the corresponding entry in the user table automatically when the same user sends email.
| 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?
No, the context was "Should XHASHCASHNEWKEY be accepted only after MAIL and before RCPT, as the draft says?". The challenge in the spec is constructed from the envelope addresses of the current mail transaction. If we want to to do hashcash challenges outside mail transactions (i.e. before MAIL FROM:), this way of constructing the challenge makes no sense.
| 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 properly, 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?
No. The transition 1 -> 2 is an execution of the XHASHCASHNEWKEY protocol. The transition 2 -> 3 is bidirectional exchange of mail, and it doesn't have to apply globally to all users.
As an alternative, a large payment might be wanted.
I agree that makes some sense. I'd like to see a motivation for the key-setup cost, though, I think there are some hidden assumptions there, like on the number of emails a spammer wants to send to the same user.
Say we allow a large payment C_3 as an alternative way to force the transition, and let the cost sending email be C_1 and C_2 in states 1 and 2 above. Then, if a spammer wants to send N messages each to M users on the same mailserver, depending on spammer's actions, the total cost, and cost per mail, can be
Spammer never establishes any key: N*M*C_1 per email: C_1
Spammer exchanges a key, but never gets to state 3: C_1 + (N*M-1)*C_2 = (C_1-C_2) + M*N*C_2 per email: C_2 + (C_1-C_2) / (N*M)
Spammer exchanges key, and pays to go to state 3: C_1 + M*C_3 per email: C_1 / (N*M) + C_3 / N
It seems clear that a large "one-time" cost, be that C_1 (per MTA) or C_3 (per receiver) is amortized over the number of mails sent. And I see no reason to believe that N will be small.
When speaking of client coming back, we mustn't forget to demand that the client connects to the very same MTA the second time.
What does "same" mean? Same A-record (IP address), or the same MX-record?
/Niels