Hi all, creator here. I've been working on AnonAddy (short for anonymous email address) for the past few months with the vision of creating a privacy friendly, transparent and easy to use email forwarding service.
The web app is built using Laravel, Vue.js and Tailwind CSS. Source code is available on GitHub[1], also mirrored on Gitlab[2]. 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 - 94960540-f914-42e0-9c50-6faa7a385384@anonaddy.me
- Add multiple recipients per alias
- Add additional usernames to compartmentalise your aliases
- Browser extension for Firefox and Chrome
- API
New features are added regularly, here are some potential future features:
- Tags/folders to help organise aliases
- Random word aliases e.g. yellow.biker54@anonaddy.me
- 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[3] 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.
Cheers! Nginx access and error logs are kept which do record IP addresses. Default log settings are used for Postfix. The logs are rotated daily using logrotate and retained for 7 days, old log files are deleted.
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.
Have you included ARC support for forwarded email? This is pretty important for not getting blocked as spam when there's strict DMARC enforcement while also not getting your "friendly-from" blacklisted as a spammer.
At the moment received emails are piped to the application where they are then forwarded on as a new email from an AnonAddy domain. So they currently pass SPF and DKIM checks as my DMARC reports show.
Just a small tip - nobody outside of developers are going to know what UUID means. Maybe have a (?) hover explainer for that line on the landing page, with an example UUID-based email address, like you provided here.
Each time a new email is received Postfix calculates its size in bytes. A column in the database is then simply incremented by that size when the email is forwarded or a reply is sent. At the start of each month your bandwidth is reset to 0.
Do you find it impossible that someone would read a thread without an account, find a topic they want to comment on, create an account and then post a comment?
"Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email us and we'll look at the data."
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.
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.
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.
I went through a very similar process when building a product as an engineer (albeit B2B, but I think the same ideas apply here). When I first started, I wanted to undercut the market and charge what I felt was an extremely fair price (I was charging $8/month when competitors were charging $500/month). After scaling the product for a few years, it was eventually acquired, but one of the biggest regrets I've had is not charging more sooner, especially because the market could clearly support it.
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!
That makes sense. You (and your customers) definitely know the market, so data-backed decisions are best. Could also be an A/B opportunity for the future. Good luck, the product looks great!
You aren't selling to techies. This is super easy to set up for almost any engineer (beyond a few fantastic features you added).
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.
Fantastic looking product, and the first year of service for the price of a beer is a great value. Just hooked it up with my own domain to track spam offenders and eventually migrate off gmail entirely.
I agree. I will say the price was at a point that I didn’t even have to think about it at 1$/month.
I looked at the features, signed up promptly, and wired up a custom domain. The only thing I’m not excited about is rotating all my emails...
Thank you for putting this together. I love that you even have 2fa support.
There's a much harder problem, granted, but the world needs a throwaway SMS service. Even Imgur needs a phone to sign up now :(
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.
If you successfully manage to establish this, then you'll ruin the point of asking for SMS as an antispam measure, and eventually providers will move to something more intrusive.
So many companies are under the impression that a phone number is a unique, secure identifier for their users when in fact it's fairly easy for a knowledgeable attacker to hijack a phone number for calls and SMS.
Things are always fairly easy to the knowledgeable or experienced. It’s definitely a better practice then not asking. Lots of medium sized businesses can’t implement a cyborg biometric MFA solution. So they easily ask for a phone number. Most don’t make it mandatory, but I think generally it is the best current realistic solution.
Because disposable emails are trivially used by casual users and companies see phone number as harder to falsify (correctly, IMO). It's not impossible, obviously. We know SMS can be hijacked and spoofed, but the casual user won't be doing this, today.
If the point of requiring an ID is to prevent abuse, why do I care about what casual users are doing? What I care about is preventing signups from people who want to abuse the service, but presumably making things harder on casual users doesn't work toward that goal.
Not exactly throwaway per say, but I have a Google Voice VOIP number that I usually use when I'm signing up for services that require a phone number. Some services seem to be able to actually detect that it is a Google Voice number and will reject it, but it works the majority of the time, and I believe it has helped in keeping my main phone number from receiving as much spam. One plus about using Google Voice is that I can access it later if I need to use it to regain control of an account if I lose a password or whatever. That number predictably gets a fair amount of spam now, but another nice thing about Google Voice is that I can quickly use full text search on the entire call history, voicemail, and sent/received SMS messages.
Actually are there a lot of services like this in Russia [0][1] and their pools of numbers is nearly unlimited. It's also super cheap for local numbers, but obviously much more expensive for non-CIS countries. Obviously it's all shady stuff and used mostly for spam or all kind of social media automation.
I run a site [1] which is doing this, only more permanent. I am not nearly brave or rich enough to run a 10minutemail but for phone numbers.
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. :)
I’m the founder of Unlisted (https://www.unlistedapp.com) and this is exactly the problem I was aiming at when building our private number service.
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!
The worst offenders are the ones that block Google Voice; As I understand it, Google Fiber/Google Fi users can't use these apps since the number system goes through G Voice.
Hi, I have some questions regarding your privacy policy. It appears that Unlisted maintains records of IP addresses, calls, texts, contacts, voicemails and lots of other metadata.
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.
This looks interesting. For now I've been using the + suffix on my G Suite account: name+alias@example.com. The only downside to this is the fact that some websites don't have proper email validation and say that this email address is invalid.
Thanks, I wrote a blog post[1] recently about the benefits of using different aliases as opposed to plus-addresses and that was one of the issues I mentioned.
The reason for this is that rather than deal with the flaky "unsubscribe" you can just disable emails from that sender. With what you have now you could accomplish the same thing by creating aliases for each service, but the issue is that sometimes you receive emails from unexpected address (e.g. you give your email to Microsoft for billing but start receiving from their marketing department).
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): mail@example.com
Group Enabled
Microsoft [o]
- Azure Emails [ ]
- Microsoft Store [x]
Google [x]
- Google Cloud [x]
And you then would allow people to customize what emails constitute "Microsoft", "Azure Emails", etc.
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).
"The reason for this is that rather than deal with the flaky "unsubscribe" you can just disable emails from that sender."
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.
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).
Love the idea.
However, what happens if the anonymous email forwarding service disappears (e.g. shuts down)? Does it mean users won't be able to access any online service they signed up for with an anonymous email address?
Thanks, this will always be a concern for these types of services. I will be keeping this service running indefinitely as I use it myself everyday along with friends and family. I originally created the service to solve my own problem.
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.
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").
Nice! I also plan to add random word aliases soon e.g. yellow.biker57@anonaddy.me etc. just because some people think UUID aliases stick out a bit and look odd.
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.
A friend of mine was considering building an anonymous forwarding service and ran into this same question. He also considered allowing custom domains, but if a custom domain is used, is it really anonymous? Couldn't services coordinate to realize that all email addresses under whatever.com are owned by the same person?
Please explain me why? They got a permanently free plan, and they allow you to do a catch-all rule (it's an option in the dropdown!) for receiving emails.
You can then catch all for your domain and redirect to your inbox (or blacklist as needed and such).
Do you have a plan for when the anonaddy.com domain is added to the blacklisted emails? For example, I know on some websites will just straight up reject addresses from Mailinator or Sharklasers. Is there a way to prevent this from happening to you as well?
As I mentioned in another comment the only true solution to that problem is to use your own domain name. I will also be adding more generic domains to use in the future for users to choose from.
I know this is kind of a disparaging comment, but I would really like to hear their response to it. There have been numerous good services similar to them in the past and all have been placed on spam listings and blocked by most major services. Mixnet solutions have worked for over 30 years, they aren't particularly novel, what is novel is having an email service that allows reasonable privacy whilst not ending up on a spam listing.
I'll do my best to prevent spam being sent by the service and therefore avoid being placed on a blacklist in the first place. I know it may be difficult to avoid landing on any blacklists but the server does currently have some reasonably strict anti-spam measures in place and I'm constantly looking for ways to reduce any spam to a bare minimum.
All forwarding addresses (recipients) on the site must be verified in order to receive forwarded emails.
186 comments
[ 2.9 ms ] story [ 298 ms ] threadThe web app is built using Laravel, Vue.js and Tailwind CSS. Source code is available on GitHub[1], also mirrored on Gitlab[2]. 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 - 94960540-f914-42e0-9c50-6faa7a385384@anonaddy.me
- Add multiple recipients per alias
- Add additional usernames to compartmentalise your aliases
- Browser extension for Firefox and Chrome
- API
New features are added regularly, here are some potential future features:
- Tags/folders to help organise aliases
- Random word aliases e.g. yellow.biker54@anonaddy.me
- 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[3] 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.
Thanks, Will
[1] https://github.com/anonaddy
[2] https://gitlab.com/anonaddy
[3] https://github.com/spatie/laravel-cors
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.
Yes the size does include images and attachments.
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!
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
https://news.ycombinator.com/newsguidelines.html
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.
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.
https://mailinator.blogspot.com/2008/01/your-own-private-mai...
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.
Thank you for putting this together. I love that you even have 2fa support.
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?
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.
[1] https://crypton.sh/
[0] https://sms-activate.ru
[1] https://5sim.net
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. :)
[1]: https://phoneprivacy.co
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.
[1] https://anonaddy.com/blog/why-you-should-use-a-different-ema...
y.ou@gm yo.u@gm you@gm
See <https://support.google.com/mail/answer/7436150>.
So for example if you have an email (using a custom domain): email@example.com
You obviously will receive emails as you give out your email. Say for example you get emails from the following senders:
- mail@google.com
- azure@microsoft.com
- notice@azure.com
- ok@imgur.com
- hello@startup.com
It would be nice if the dashboard had something like the following (almost like meta emails):
The reason for this is that rather than deal with the flaky "unsubscribe" you can just disable emails from that sender. With what you have now you could accomplish the same thing by creating aliases for each service, but the issue is that sometimes you receive emails from unexpected address (e.g. you give your email to Microsoft for billing but start receiving from their marketing department).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): mail@example.com
And you then would allow people to customize what emails constitute "Microsoft", "Azure Emails", etc.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).
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.
There are instructions on the subscription page of your account.
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).
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.
Perhaps I could make this more clear?
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").
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 mymail@gmail.com. So in this case, spammer@spam.com goes to mymail@gmail.com.
- You then would have another email, realmail@mail.com that would receive email from mymail@gmail.com (you would set up the forward in Google).
- However, mymail@gmail.com would actually send to mailproxy@proxy.com, which would decrypt and forward to realmail@mail.com
TLDR: You need to encrypt the emails, pass through a service that won't be blocked, forward and decrypt to target destination.
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.
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.
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.