It's a cool product that has a lot of great legitimate uses, no doubt. I just hope you've baked in security at the core, and that you have a contingency plan for when your IP's get blacklisted. I fear for your sanity, but wish you the best!
Thank you, hopefully I'll be able to stay sane!
It took several months or a large payment to the people maintaining the blacklist for my server to get unblocked (it wasnt critical so I didnt pay). Seemed like extortion to me, but Google and others respected this particular blacklist.
Im not sure if this list still exists. It was on the blacklist checking websites at the time
The fix is to configure your MTA so that it doesn't send backscatter
Alternatively attempt to send a message to a nonexistent address on your MTA using telnet which should throw an error after "RCPT TO" if the server is configured correctly
Steps to test SMTP via telnet: https://my.esecuredata.com/index.php?/knowledgebase/article/...
My understanding was that a backscatter uses an email that is not his, in order to deliver a message without sending it directly (and making the bounce server act like a spammer).
Am I missing something?
Unfortunately, mail delivery is far, far harder than it should be.
However, we still receive spam e-mails to our inboxes.
I already made this: https://idbloc.co/
Good luck! It's unlikely you'll be able to keep it free for long due to the volume of spammers who will dive in once they discover it (speaking from experience).
What this really is is an easy way of setting up email aliases. I think that should be the tag line.
There are already some services like this, however it seems they have a smallish pool of phone numbers. Eventually everyone uses those to sign up, one time, somewhere (like Imgur) and that number is then useless for that site.
Is there a better way?
Unfortunately today, however, many sites will detect VoIP numbers and refuse to send messages to them. There are two reasons: 1) The app detects that it is not a “real” number and blocks its entry, or 2) the number is accepted but no message is ever received. In the second case, the “call with a code” option does usually work though. The reason is that short code providers negotiate delivery outside of the normal framework that long code (“normal”) numbers use. Most apps like Unlisted are using Twilio as a provider and these agreements just aren’t in place.
I’ve been running Unlisted for over 6 years so have a bit of experience around this space. Am happy to answer any questions!
I admire the goal of trying to provide a convenient way to increase privacy when using SMS, but this feels a bit invasive. That's a lot of collected data. Unlisted has access to the entire history of all my conversations and calls. Why not encrypt most of the at-rest data with the user's password and decrypt it client-side? This is common practice for the more privacy-leaning email providers, such as ProtonMail. Similar SMS services have taken this approach as well, like crypton.sh.
You are leaving a lot of the privacy enthusiasts on the table (myself included). It may seem like a small market, but communities like /r/privacytoolsio are very active and constantly on the lookout for privacy preserving products.
The only issue is a lot of sites treat all VoIP numbers as second-class citizens and disallow them silently. You will be allowed to add the numbers, but the services will silently refuse to call or text them, locking you out of your account.
Let me know if anyone is interested in trying it out. I am relaunching PhonePrivacy after this weekend so lots of upgrades to come. :)
Or you could just get a pay as you go sim card and use a cheap phone to read messages (or use dual SIM if your phone supports it).
The main issue is the finite number of mobile numbers like you say.
So for example if you have an email (using a custom domain):
You obviously will receive emails as you give out your email. Say for example you get emails from the following senders:
It would be nice if the dashboard had something like the following (almost like meta emails):
Email Address Enable
firstname.lastname@example.org [ ]
email@example.com [ ]
firstname.lastname@example.org [ ]
The above, combined with intelligent grouping of emails and a uBlock Origin like curated list of "bad" emails could truly eliminate all spam.
You should introduce a 4th tier of payment if you have the above functionality, by the way as it's not that trivial.
The end result of this would probably look something like:
Your email (custom domain): email@example.com
- Azure Emails [ ]
- Microsoft Store [x]
- Google Cloud [x]
It would be convenient to be able to email your own forwarding email with the unsub email in the subject and a PIN in the body to turn off an of the forwarding.
I agree it would be great to be able to create a per alias blacklist of senders who the alias will block emails from.
That way like you said you don't necessarily have to deactivate the entire alias if you receive a couple of emails from an unexpected source.
I'll definitely add this to my to do list, thank you.
I believe that you will be better served being more like uBlock Origin and less like traditional email alias services.
Once you implement the above, you could add a rich "rules" API and then you could do all sorts of interesting things:
- Forward emails as "spam" to the anondaddy database
- Don't receive emails marked as "spam" by at least X users using the anondaddy database.
- Queue all mail by [GROUP] and combine and send at the 1st of the month, etc.
- Queue all mail with [SALE] in the title and combine and send at the 1st of the month with subject line [Sales Newsletter].
- Remove all pictures from email before sending
You can seriously make some money off this. Think beyond traditional email aliases and think more about why people use email aliases to begin with - control over what gets in their inbox.
I'd implement what I suggest myself, but you'll quickly see that it's not trivial. I got to the point you're at now pretty quickly (weekend MVP), but implementing these other features becomes more trivial than doing it over an email (though it's not impossible by any means).
I've been doing this exact same thing since march this year with my own domain using MailGun (Free) and custom forwarding rules.
Really amazing to see someone turn it into a product that can easily be set-up by the general folk. (And for a nice price!). Loved your UUID-alias idea.
May I ask however, how do you expect to handle a blacklist of your domains? I've had trouble in the past signing up to some websites that block any sort of custom domains (really bad) in an effort to block throw-away email, what happens if your domain gets blacklisted/categorized as a throwaway email? (Also forwarding to Google and such ends up in "email limbo").
To be honest the only true solution to that problem is to use your own domain. I will be adding more generic domains to use in the future so hopefully will be able to evade the majority of these blacklists.
That's why I added the additional username feature to compartmentalise aliases and also the UUID aliases.
The UUID aliases all share the same domain e.g anonaddy.me so it is not possible to link ownership of these to any particular user.
test@[2001:0DB8::0004] # or possibly
When I did an MVP of something similar to this, I encountered the same solution. The only solution really is the following:
- Use a reliable email, e.g. mymail@gmail.
- Encrypt forwarded email and send to firstname.lastname@example.org. So in this case, email@example.com goes to firstname.lastname@example.org.
- You then would have another email, email@example.com that would receive email from firstname.lastname@example.org (you would set up the forward in Google).
- However, email@example.com would actually send to firstname.lastname@example.org, which would decrypt and forward to email@example.com
TLDR: You need to encrypt the emails, pass through a service that won't be blocked, forward and decrypt to target destination.
You can then catch all for your domain and redirect to your inbox (or blacklist as needed and such).
It's literally a feature they provide.
It was shut down in the end, but I think some of the legal challenges it faced might be better handled now.
I agree that the OP / Service Provider - should read up on the legal issues surrounding a service like this... The Wikipedia link above is a good place to start. Ideally get a good lawyer and give that link to them...
If I had to make a choice, I would choose any other SaaS business, due to the historically contraversial nature of this type of service -- but that being said, I wish the OP good luck in his endeavor!
It would be far more honest and up-front to tell prospective users that their data will not be private in/under all conditions/circumstances...
If you lose would-be users because of this, well, at least you showed honesty and integrity...
I'll do some more research on the legal issues you've mentioned above too.
But then one day, you might get that one user, that one user, that just abuses all of that, and causes nightmarish legal problems...
So forewarned is forearmed, as they say...
Also, I would point out that your service is the only way to truly manage rogue emailers that don't respect unsubscribe requests. In other words, it has a very legitimate/lawful purpose other than mere privacy.
While rogue emailers might not exist so much in the U.S. due to laws, the rest of the world is open game -- there is no way (short of using your service!) to manage them appropriately.
If you should ever go to Court, that should be at least one of your arguments... basically ask the court/jury, "OK, well if a recipients email address can't be anonymized, then how else does someone manage spammers from other countries that get their real email address and keep mailing them from different addresses (and with different content) such that it bypasses their spam filter?" Simple answer: They can't! No one can! Done!
Disposable email addresses (for the recipient, when subscribing to various things on the Internet) are the only solution.
See, that's your legitimate/lawful purpose...
Anyway, wishing you luck!
I've been using Mailinator for this sort of thing but I'm finding most of their domains have been increasingly blacklisted on many lead capture forms. And their paid plan that allows custom domains is not priced for this kind of use case.
(Frankly I'm worried your pricing is too low.)
Looks like it's time to go dust off one of those domains I've been sitting on... :)
I did start the service with just the Pro plan at $36 per year or $4 per month.
I received quite a lot of feedback from users asking for a cheaper plan that would allow 1 custom domain etc. which is why I eventually added the Lite plan.
As long as it makes enough to pay for itself I'll be happy as I made it to solve a problem for myself initially.
I'm just getting started on something quite similar that will let you create disposable email addresses that forward mail to multiple recipients (for shared hotel/flight bookings, etc.). I see you have this feature to a lesser extent too, which is super cool.
Again, great work and good luck!
> Will people see my real email if I reply to a forwarded one?
> No, your real email will not be shown, the email will look as if it has come from us instead. Just make sure not to include anything that might identify you when composing the reply, i.e. your full name.
How does that work? Do replies actually go through your servers, so that to the outside world they appear to be a proper mail from someone at AnonAddy, with SPF and DKIM all in order?
> How do you prevent spammers?
> The following is in place to help prevent spam: [list of six things it does to fight incoming spam]
Can someone with an AnonAddy address send an outgoing mail to someone who has not previously sent a mail to that AnonAddy address? If so, how will you try to prevent outgoing spam?
If outgoing mail is limited to mail to people who have sent you mail, can you initiate new mail to those people, or must each outgoing mail be in reply to a previous incoming mail?
I will be adding the ability to send replies so that they come from a user's own custom domain soon. This will involve having to add an SPF and DKIM record as well as the MX one.
At the moment it is not possible to initiate an email conversation using an alias although it is a feature I would like to add. I'll have to think about the best ways to prevent spam when adding this.
Yes you could use the same Reply-To: name and email to reply to the same person more than once if you have already received a forwarded email from them.
The only note would be pricing? Margins look too low for the tech product? You need to sustainably acquire and maintain a very large user base in order to make it work, the larger the base the more expensive maintenance will be, can potentially be dangerous. Let me know if I'm missing something.
You're right as it scales I may need to upgrade the server etc. but I think it will cover its expenses quite easily.
Anyway, it's a bit unsolicited, but I could definitely see this being at least $4.99/month for Lite and $9.99/month for Pro. Congrats on the launch!
My main concern would be the fact that complete email solutions such as Tutanota, Posteo are very cheap at 1 euro a month or so.
So I'm not sure users who aren't as concerned about their privacy would think it was worth it for $4.99 per month+
I mean I could be completely wrong, just my thoughts from some of the feedback I've received so far.
What you need to do is effectively twist the knife, make the reader feel the pain. "Don't you think $10 / mo is worth your sanity and a clean inbox?" essentially.
$10 is basically nothing to your modern professional. That's 1 - 2 coffee runs.
$1 or free (!!!) is way too cheap for an indie maker. Ignore the people who complain about price. There are always going to be people complaining, fire them. Those types will always find something to complain and twist your arm about.
Even $10 / mo for me, someone who has set this up myself, might be worth it just for additional features and being able to easily add more domains.
EDIT: Save free forever for the VC-backed companies who are burning other people's money in the hopes of hockey stick growth.
Free trials are fantastic, but free forever is a losing gambit in my opinion.
The web app is built using Laravel, Vue.js and Tailwind CSS. Source code is available on GitHub, also mirrored on Gitlab. The server is running Postfix, MariaDB, Nginx and Redis.
I know that there are already a number of other services available that do a similar thing, but I wanted to address a few issues with them, such as:
- Proprietary source code
- Adverts, analytics and trackers used on the sites
- No option to encrypt emails using a GPG/OpenPGP key
- No option for multiple recipients
- No API
AnonAddy protects your real email address from spam and allows you to identify who has sold your data by using a different unique email address for every website.
Here's a highlight of some of the features so far:
- Add your own GPG/OpenPGP key per recipient to encrypt all forwarded emails
- Custom domains
- Anonymous email replies
- UUID aliases that look like - firstname.lastname@example.org
- Add multiple recipients per alias
- Add additional usernames to compartmentalise your aliases
- Browser extension for Firefox and Chrome
New features are added regularly, here are some potential future features:
- Tags/folders to help organise aliases
- Random word aliases e.g. email@example.com
- More brower extension functionality to manage existing aliases etc.
- Send from aliases e.g. initiate email conversation
- Send replies from custom domains as opposed to from an AnonAddy domain
One of the most frustrating challenges was sorting out CORS issues with the API whilst building the browser extension. I noticed that only Firefox seemed to be enforcing the policy and not Chrome (Brave) which caused some confusion. In the end I looked at this awesome package by Spatie - laravel-cors and was able to solve the issue. An important thing to note is that the Cors middleware needs to be included in Laravel's global middleware stack for it to work.
I've learnt a lot about Postfix, DAME, DNSSEC etc. whilst building this but I'm always looking to improve things so I'd love to hear if you have any suggestions or feedback at all.
Log files are only ever used to diagnose any errors/bugs.
Emails received are not e2e encrypted unless they have already been encrypted before arriving to the server.
Users can add their own PGP key to the site for each of their recipients and then the server will encrypt all forwarded emails with it.
Emails received are immediately piped through to the Laravel application by Postfix.
First "As a thank you for being an early beta tester..."
After that "If you have any more than 20 UUID aliases they will be deactivated"
Should I go with you anymore? Never treat your customers as beta testers. My data come with UUID are gone.
A picture is worth a thousand words
The message stated: "You are currently on a Free Pro Subscription as a thank you for being a beta tester. This free subscription will come to an end on 5th December 2019. You can still start a subscription now if you wish to support AnonAddy."
When the site's open beta came to an end I sent an email to all those who had signed up. As a thank you, this email let all users know that they would have an additional 3 months to continue using all the Pro features of the site for free.
I then sent 2 more emails shortly before this free subscription came to an end which is shown in your screenshot, giving users the choice to update their emails if they didn't wish to subscribe.
I have also offered all beta users a discount on both Lite and Pro plans.
Let me know if you have any other questions.
Thank you for putting this together. I love that you even have 2fa support.
I have no idea how big the traffic spike is from this post but the server appears to be coping very well so far!
All forwarding addresses (recipients) on the site must be verified in order to receive forwarded emails.
y.ou@gm yo.u@gm you@gm
I see some mention of a Tailwind template for the landing page, but how did you do the secondary pages and the admin interface? The blog?
Also, I see some mention of Vue. Did you do the admin interface differently than the main site?
The other pages e.g. the blog, FAQ, posts etc. are just very simple layouts along with the nav bar and footer.
I'm using Jigsaw which is a static site generator that allows you to use Laravel's blade templating engine, it's awesome.
The admin interface I made myself using a few Vue components, it is a reasonably simple layout to be honest.
Yes the account site where you login (everything at app.anonaddy.com) is completely separate from the landing page (anonaddy.com).
The first is a Laravel app, the second is a static site. They both have different repositories on GitHub. Feel free to browse through all the source code to get a better understanding of how it works. Just let me know if you have any more questions about it.
If you are looking for some help or inspiration with UI design I highly recommend the Refactoring UI book by Adam Wathan and Steve Schoger.
The best way to mitigate against the risk of a service shutting down is to use your own domain name. That way, by simply changing your MX records to another email provider, you can continue to receive emails as normal.
Someone suggested the idea of creating hashed aliases, that are generated and hashed on the client side so that even I do not know what they are, then incoming emails are compared against this hash to determine where to forward emails.
The only thing is there would probably need to be an additional column on the hashed alias that is client side encrypted so that the user can still view the actual alias in their dashboard.
I've thought about tokens or credits that get consumed by checking/sending on the hash, but I imagine they'd be most-used for fire-and-forget stuff...
Unfortunately the operator of the site is really sick and has talked about shutting the site down. Last I heard he'd found someone who seemed trustworthy to run the site when he isn't able to, so we'll see.
One thing that really stands out for me is the detail and effort you've put in to the help and privacy documents. Good job!
I based the help centre on Mullvad's as I really love how simple and easy to navigate their website is!
I think 1/4 of my signups are anonymous accounts.
Only upside is that they are a dead giveaway for non converting users so there’s that.
Be careful you don't run into legal issues here. I remember reading somewhere recently that silently dropping emails isn't allowed in some jurisdictions.
Super user friendly, great dashboard. Considering upgrading to the pro version - how long is your black friday offer available?
That would be great, it is valid until midnight this Friday PST. The coupon code is BLACKFRIDAY50
A few users have asked for me to create a Docker image that can easily be deployed, however I'm not familar with Docker so I'll have to learn how to do this first.
I agree with the anonaddy.com alias, and saw that you added another one for people on lite/pro plans.
I'm just unclear on how the bring-your-own-domain feature works.
When you create an account there is a page called domains, it provides instructions on how to add the correct MX record to your custom domain in order to allow the server to handle inbound emails.
There are instructions on the subscription page of your account.
Perhaps I could make this more clear?
Yes the size does include images and attachments.