How does forwarding fork, and why is it a problem?
Assume that mail for fred@f.com forwards mail (via a .forward or aliases file) to ron@r.com, and stay stan@s.com sends an email to fred.
There will be two smtp transactions. The first between the s.com and f.com MTA's, which will use
MAIL FROM stan@s.com RCPT TO fred@f.com
The next is between the MTA's for f.com and r.com, which will use
MAIL FROM stan@s.com RCPT TO fred@f.com
The problem here is that the f.com MTA sends mail on behalf of a user that "really" belongs to a different MTA, for s.com. So this is just a special case of relaying.
So which keys should be involved? The first transaction involves a key for <s.com, f.com>, no problem there. The second transaction, between f.com and r.com, must use a key shared by those two mail servers (since the key for <s.com, r.com> is not known to f.com).
So we use a key that has no obvious relation whatsoever with the address given in MAIL FROM. And we must make this case work.
We also need to make more general relaying work. Consider the organization "Telia home users" which have a border MTA telia.com or some such, handling all out-going email. The users have arbitrary from addresses, unrelated to telia.com, which acts as a relay or "smarthost".
The natural conclusion is that we must drop the notion that the keys can be used to authenticate the from address. A key can only be used to authenticate the MTA which owns it.
And following this way of thinking, we have no use for per-user keys. (End-to-end per-user authentication is still a nice thing to do, but it can't work out-of-the-box with forwarding. When setting up a forward, the user must transfer his or her keys from the old place to the new place. Fortunately, that's not the MTA's problem).
And one more forwarding comment: It would make sense to have an SMTP reply code that means "temporary redirect",
451 address forwarded to some@where.else
and make it the clients responsibility to contact the right MTA server. This is analogous to 251 and 551, which are rarely used, and to HTTP redirects, which are used quite a lot.
This could be done independently from our hash cash work, but I don't think it is worth the effort, since (i) it helps forwarding, but it can't replace general relaying, (ii) nobody uses 251 and 551 anyway, why would they use 451?, and (iii) it's probably too common with forwards that go to internal addresses and mail servers that aren't reachable from the Internet
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 07 Oct 2004 18:21:42 +0200:
| How does forwarding fork, and why is it a problem? | | Assume that mail for fred@f.com forwards mail (via a .forward or | aliases file) to ron@r.com, and stay stan@s.com sends an email to | fred. | | There will be two smtp transactions. The first between the s.com and | f.com MTA's, which will use | | MAIL FROM stan@s.com | RCPT TO fred@f.com | | The next is between the MTA's for f.com and r.com, which will use | | MAIL FROM stan@s.com | RCPT TO fred@f.com | | The problem here is that the f.com MTA sends mail on behalf of a user | that "really" belongs to a different MTA, for s.com. So this is just a | special case of relaying. | | So which keys should be involved? The first transaction involves a key | for <s.com, f.com>, no problem there. The second transaction, between | f.com and r.com, must use a key shared by those two mail servers | (since the key for <s.com, r.com> is not known to f.com). | | So we use a key that has no obvious relation whatsoever with the | address given in MAIL FROM. And we must make this case work. | | We also need to make more general relaying work. Consider the | organization "Telia home users" which have a border MTA telia.com or | some such, handling all out-going email. The users have arbitrary from | addresses, unrelated to telia.com, which acts as a relay or | "smarthost". | | The natural conclusion is that we must drop the notion that the keys | can be used to authenticate the from address. A key can only be used | to authenticate the MTA which owns it.
Unless we could come up with some working (!) way of delegating the right to authenticate a sender.
Theoretically, f.com could show r.com some proof that it's entitled to speak for stan@s.com. Perhaps f.com got something from s.com during their transaction that serves as such a proof?
Another way would be if r.com asked s.com about f.com's rights to speak for stan. This breaks some basic properties of the store-and-forward nature of mail, I'm afraid. I don't know whether that's a problem or not.
The obvious downside with dropping the coupling of sender and recipient is that as soon as anyone@a.com and anyone@b.com have exchanged mail, the road is open for all users at a.com to spam all users at b.com and vice versa. Maybe that's acceptable? Or do you have any other smart ideas up your sleeve?
Linus Nordberg linus@nordberg.se writes:
For hashcash payments, you could do it by removing the salt, and instead make the response depend only on the envelope receiver and the message contents. Might work, but I'm not sure what security holes that might introduce.
For authentication, it's different. With MTA keys, it basically works like this: The receiving MTA r.com trusts the forwarding MTA not to spam, or at least take all reasonable precautions. The forwarding MTA, f.com, trusts the sending MTA, s.com, not to send spam (or else it requires s.com to make a hash-cash payment).
Hmm, it strikes me that f.com may need to accept and forward email that uses no authentication. I think we should let f.com tell r.com what level of authentication it had when accepting the email. Not necessarily on the SMTP-level though, it may be sufficient to let f.com add a header to the message contents line expressing that (analogous to received: lines).
One may be able to do something more sophisticated of we replace the MAC:s by digital signatures, but I think that will add too much overhead (imagine a list server with a few 1000 subscribers, which needs to sign every copy of the message).
Bottom line: I think MTA keys is the simplest and lightest cryptographic infrastructure we can get away with.
One can associate local per-user information with the keys. b.com can tell a.com that "sure, we have a shared key, but for email to user@b.com, you have to provide hash cash anyway".
It's quite hard to predict how all these things will work out in practice, so I think it is appropriate to specify the protocol with the "mechanism, not policy"-principle in mind.
Regards, /Niels
mta-hashcash@lists.lysator.liu.se
-
Linus Nordberg -
nisse＠lysator.liu.se