willbrowning

I apologise if there has been some sort of misunderstanding. When I first launched the site I publicised the fact that it was in open beta whilst I was ironing out any obvious bugs and testing things out. I also had a banner message in the settings page stating this.

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.

Best, Will

Here is a good blog post [1] that explains backscatter and some ways to help prevent it.

[1] https://willem.com/blog/2019-09-10_fighting-backscatter-spam...

I actually use the database to store all the different aliases, then Postfix does a database lookup to see if they exist or not.

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.

Not at the moment I'm afraid. It would be cool to set up an .onion address, I'll have to look into this.

Fair point, I'll try to emphasise the ease of alias creation instead going forward.

That's a really good point, I often fall into the trap of assuming things like this, thanks.

I haven't used it myself but I think Privacy.com[1] does this.

[1] https://privacy.com/

Great stuff! Let me know if you have any questions.

I'll have to do some further reading on this. Do you vaguely remember where you read this and why it was not allowed?

Yes that's true you could be linked if using a custom domain and someone can determine that nobody else is sharing that domain with you.

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.

Thanks, I do have a small number of instructions for self hosting[1] they're still a work in progress and you'll need to know how to manage a server from the command line etc.

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.

[1] https://github.com/anonaddy/anonaddy#self-hosting

I agree there may well be some challenges along the way but I'll do my best to prepare and prevent them. I'm always reading and learning more about the best measures to have in place for the server.

Thank you, hopefully I'll be able to stay sane!

Thanks a lot.

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[1] 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[2] by Adam Wathan and Steve Schoger.

[1] https://jigsaw.tighten.co/ [2] https://refactoringui.com/

Yes a few other users have mentioned integration with password managers. I agree that would be extremely convenient, but this would obviously be up to the password manager to integrate it using the API.

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.

Thanks for your suggestions, I agree. In the privacy policy on the site I do state that "information will not be provided under any circumstances to any parties other than when compelled by law." Logs are rotated daily and deleted after 7 days.

I'll do some more research on the legal issues you've mentioned above too.

I encrypt as much sensitive information in the database e.g. recipient email addresses, descriptions etc.

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 not heard of that as I normally use Mozilla Thunderbird. I'll look into it.

I've never heard of inboxalias to be honest with you, so can't comment on that.

Yes replies have to be routed through the server in order to remove any trace of the real email address sender. They are currently sent from the domain anonaddy.me.

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.

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.

Thanks a lot, on the landing page the only javascript included is on the blog and help pages for searching.

I have no idea how big the traffic spike is from this post but the server appears to be coping very well so far!

Nice! I also plan to add random word aliases soon e.g. [email protected] 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.

Not really that I know of apart from this site[1].

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/

It actually says "everything in free" meaning you get everything that is in the free plan plus the rest of the items in the list.

Perhaps I could make this more clear?

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.

That's a really good suggestion!

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.

Yes you can, although at the moment it is done manually as I haven't got round to implementing a proper crypto checkout flow!

There are instructions on the subscription page of your account.

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.

[1] https://anonaddy.com/blog/why-you-should-use-a-different-ema...