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