I am really flattered to see this submitted by somebody that's not myself. Tempalias is a fun-project of mine I did to learn a bit about node.js and to scratch an itch I had basically since 2002.
But the service itself is only half of the project. During development, I also created a diary explaining some design decisions along the way and showing how I went from nothing to the completed service in around 44 hours.
A good starting point is my announcment which links to the various diary entries:
"If I don't "sign up", then how do I create an account?
You don't. Mailinator creates an email account as soon as email arrives for it. All you or anyone else needs to do is send email to the name you thought up and - Kazam! - it will be there waiting for you.
Um... how do I get the email then?
Visit mailinator.com and type in the email name where is says "Check your inbox!", then click "Go!", and Mailinator will display the list of email waiting."
I can imagine good uses for both. The beauty of Mailinator, in some cases, is that you don't receive that mail in your regular inbox. It all depends on what the mail is and why you don't want to give them your email address to begin with.
Thanks, one more such email server to block in my web site. I have a form where people can enter email to download something, and I block all such email hosts. Once a while, I look at emails list, and if I see some suspicions user email, I have a look at its server and block it. My list has already around 60 or more such domains. People can add as many as they like temporary emails domains per day. I can always update my blocking list faster (and less cost :).
Just allow anybody who has a domain to configure the tempalias MX as their MX (or an MX for a subdomain of theirs) and everyone (with a domain) can have their very own tempalias. Good luck blacklisting that.
Note:
this is not public yet - it's on a branch. I will implement domain name checking and maybe some kind of registration before putting something like this live - but you get the idea
If this is a trial version, wouldn't it be better to just let the users download it, rather than spamming them? Unless of course, you make the money from the spam end of it.
It is freeware, and I like to have something back in return for it. I have hundred thousands of email addresses collected already, something of no use at all for me - I never sell them or email to people. I just want to have them collected :).
The benefit this has over mailinator is that the email ends up in your regular email client, and can be managed the same way. It won't be deleted unless you delete it, and no one else can come across it (mailinator has intoduced something to combat this: http://mailinator.blogspot.com/2008/03/introducing-alternate...).
That's a damn good idea. Takes away the pain of the alternative (throwaway addresses). Good landing page too, I thought, as was the "what is this good for".
When I read "aliases", I was excited, because I was hoping it would work both ways: people get an alias they can use to e-mail you, with the messages transparently modified so that when you reply, you reply to them as the alias, and can carry on an extended conversation that way.
But nope, it's just a one-way temporary inbox service, not much different than spamgourmet or mailinator.
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. "reply-af389jgls9@tempalias.com"), 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 "reply-af389jgls9@tempalias.com" 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 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.
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)
If you have Gmail, you can actually use yourusername+someuniquestringidentifyingwhoyougaveyouraddressto@gmail.com which will still direct all email to your inbox. However, if you decide you no longer want email from a sender, you can simply add a filter that will auto-mark said emails as spam.
It's also pretty cool because you can easily tell who it was that sold your email. :)
The idea behind tempalias was to work without requiring an account, without encoding validity information into the email (thus providing spammers a way to reach you once they know how the encoding works - and trust me, they will know) and without forcing you to visit a web interface.
Of course this destroyed any credible possible source of revenue I could ever generate, but this was just a fun project and I wanted to create the most useful service, which IMHO is how this works.
Is this 100% safe in conjunction with SPF?
Sending an mail through tempalias leads to a SPF failure since tempalias.com isn't allowed to send mails in the name of the sender's domain. If the receiving mailserver doesn't accept mails with failed SPF check, the mail will be discarded.
agreed. And IMHO it's a bad idea for SPF to use the message headers instead of the envelope to do validation as that leads to issues not only with services like tempalias, but also mailing lists for example.
This is also why SPF failures usually are not treated as enough reason to discard an email.
Great idea! A design question: why is there a huge chunk of white space at the very top? On a 1280x800 monitor I had to scroll down to reveal the rounded rectangle and the shady character.
Hey there, designer speaking here:
The designer was drunk during the critical phase of white-space-consideration. I'm happy to inform you that he has since recovered well and upon re-evaluation submitted a tightend version to Pilif for implementation.
Seriously: thanks for your valuable input! Pilif: Work your magic!
:-)
if you would spend your time actually visiting the site instead of updating us on your general state of drunkenness then you would notice that the top margin is now 40px instead of the previous 90px.
Blimy! 50px in under 3 hours, on a Tuesday. Someone call the police! On a more solemn note: Did you notice that I also shrunk the paddings within the white frame, above and below the title "tempalias"? If implemented correctly and the weather plays along, Christmas actually might come early for real :-)
About paying for itself: The web bandwidth is negligible as all assets are static, transferred compressed and can be cached locally. The mail part is a bit harder to predict, but in theory, most of the time, the daemon would reject delivery due to expired aliases, so I think it's not that much of an issue either.
Bandwidth, hosting and connectivity is provided by my employer which honors my (and my coworkers) fun projects and lets them do them.
On the other hand, I am a co-founder, so that shouldn't be surprising (in July, we'll be celebrating our 10th anniversary. Bootstrapped and profitable since day 1)
Going back even further, to the 90's, it looks like tempalias is just a no-account version of http://mailexpire.com
My advice to the OP, now that you have your proof of concept, is get the heck out, running a disposable email address service is a nightmare. Welcome to a world of spammers, blocklists, backscatter, exploiters, calls from police, etc.
But the service itself is only half of the project. During development, I also created a diary explaining some design decisions along the way and showing how I went from nothing to the completed service in around 44 hours.
A good starting point is my announcment which links to the various diary entries:
http://www.gnegg.ch/2010/04/announcing-tempalias-com/