nisse@lysator.liu.se (Niels Möller) wrote 22 Oct 2004 10:49:27 +0200:
| 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?
a.com will suggest the key k in its response to XHASHCASHADVISE, based on the domain part of the envelope sender?
| 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.
I think we should keep it but provide alternative ways of establishing mutual trust. Ideas include manual configuration by sysadmins (of involved MTA:s), manual configuration by end users (MUA talks to MTA somehow) and large single payment (configured by user or admin).
It's tempting to throw in lots of stuff here but we should probably consider what happens if we get software that's hard to configure properly and we end up with something like the open relay problem of the old days.
| > | 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.
My ignorance. Please ignore.
| > | 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.
We should include Torbjörn here. He's been thinking about this more than I have.
| 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.
Unless the key is tied to originating IP address some way or another, perhaps through MX records.