for the replying as the alias to work, I would have to write my own web mail client or you would have to reconfigure your email client per message.
I don't want to do the former (gmail exists. I could never match them in terms of usability and features) and you don't want to do the latter (but certainly could right now)
Not so: when a given inbound sender first sent a message to a given alias address, your site would simply need to generate a session user (e.g. "[email protected]"), write it into the "Reply-To" field of the inbound message (leaving the "From" field intact) and resend it to the aliased user. Then, when the aliased user replies to the message, their reply will come back to you, you'll look up what inbound sender "[email protected]" maps to, and then send them a message yourself, seemingly originating from the original alias address. You'd be, effectively, a two-way proxy.
I am one of these old-school mail admins though that insist that they can do what ever they want with the envelope, but the mail itself should be left alone (with the exception of the received:-header).
Once you begin messing with the message, you risk breaking stuff - in your example: What would you do if the message already had a reply-to? Sure. Store that with the session, but what if two mails with different reply-to addresses are sent in the same session? Right. Index it by message id. What if that's missing?
We are talking can-of-worms here. This is breakage waiting to happen. Sure. It'll work in many (probably most) cases, but it could also fail badly.
It's not that complicated; it's certainly not a can of worms. You're imagining some complex "session" data structure—probably something working a bit like Gmail's conversation view—but all I really meant to imply was a set of (sender address, sender alias, receiver address, receiver alias) 4-tuples. No primary key or anything, even, just a constraint that each row is unique in total (i.e. that it forms a set, not a bag.)
The "sender address" is simply whatever return address will get a message back to the sender: read from the Reply-To of the message, if it has it, or the From field, if it doesn't. The "sender alias" is simply a temporary email address, generated from the hash of the sender address. That means, whenever you receive a message with a different return address, that you create a new, different 4-tuple. You don't need to involve message-ids; every message is processed idempotently to every other, with messages from the same sender to the same receiver just happening to generate the same 4-tuples.
Picture it like being a secretary. You get a message from [email protected], and you tell your boss "You have a message from your friend Bob." You read it to him. He never sees the original message—he only hears your transliteration of it into speech. Then, he tells you "reply to Bob with a photo of my kids." You don't try to send it to the first Bob on his contact list; you look in your own mental map (i.e. the server database) and turn "Bob" back into [email protected], and send what he tells you. In other words, you're not really acting as a blind relay; you're acting more as a personal agent.
As an extra aside, the system would even work in a completely symmetrical fashion: every sender could also be a receiver, and vice-versa, as long as there was only a single method for generating aliases, and it happened automatically (i.e. users didn't get to pick anything about their aliases; they were just generated from hashes, like I mentioned.) This is basically what switchboard operators did at the inception of telephone service.
I see what you mean - if there's no session to keep track of, it's easier.
Also, I would just have to alter tempalias just a tiny little bit to actually provide the service: I'd probably need an alias with unlimited validity (that's something I'm a bit concerned about because of spammers) and a small modification to the smtp proxy - something easily done.
I'll keep this in mind as a feature for the future - or you send me patches - tempalias is licensed under MIT and available on github (http://github.com/pilif/tempalias)
I don't want to do the former (gmail exists. I could never match them in terms of usability and features) and you don't want to do the latter (but certainly could right now)