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?