2 ms·

ok. I see what you mean. 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 itsel

by pilif 16y ago

ok. I see what you mean. 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.

derefr 16y ago
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 robj@example.com, 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 robj@example.com, 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.
- pilif 16y ago
  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 http://github.com/pilif/tempalias)
  - turtle4 16y ago
    This is a really nice feature. Also a way to market it, because other services could use something like this. See craigslist for an example. So offer the service free to users looking to avoid spam, and sell to businesses looking to provide anonymous communications.

by pilif 16y ago

derefr 16y ago

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 robj@example.com, 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 robj@example.com, 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.

pilif 16y ago
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 http://github.com/pilif/tempalias)
- turtle4 16y ago
  This is a really nice feature. Also a way to market it, because other services could use something like this. See craigslist for an example. So offer the service free to users looking to avoid spam, and sell to businesses looking to provide anonymous communications.