Delivering mail services on the Internet is hard. Really hard. It's even harder to do correctly, and harder yet to prevent abuse. It is quite likely that you're going to end up in a game of whack-a-mole with abuse issues, and that's going to be your primary fight. The moment somebody abuses the system, your IP gets RBL'd or DNSBL'd and it's game over until it's fixed.
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!
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.
My mail server got blacklisted because of backscatter. That is where the sender sends spam to an address that doesn't exist on your server, but they also forge the "from" address, so the "this message could not be delivered" response, complete with the spam message, is sent "back" to the forged address (the spammers real target)
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
Which blacklist was it and how much did they charge? I have always wondered which are more mafia-esque and which less, as they all act so innocent but are also so adamant about hiding their pricing.
It was backscatterer.org. I don't recall how simple the fix was, but I couldn't find much information on it at the time. The list appeared last in the blacklist tools so I figured it was a fairly new thing.
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/...
Thank you for your reply. From my understanding, what you suggest is that a backscatter uses a return path email that does not exists?
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).
According to a friend at a large ISP who engineers their anti-SPAM, 93% of all email they receive is SPAM and dropped before routing to your junk folder. So for each 1 you receive, several dozen were sent to the bit bucket.
I work for a company that sales anti-spam and this is absolutely true. It is an unending battle between spammers and the people building the filters. We are also constantly getting RBL'ed by groups including Google and Symantec who know who we are as we have had business agreements with them in the past.
Hey mate, it looks polished. I hope it gets traction. As my way to help you, I'll feature it on SaaSHub (https://www.saashub.com). If you get it verified, I can promote it on the tribune as well.
OK. You are right. I understand that I might have been overdoing it. Bth, it's just the easiest way to contact the OP. I will try using different channels.
If a spammer is able to exploit his system he'll either run out of money and/or his hostname will be blocked. His challenge is to filter spam before those few lines of code.
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).
"Anonymous email forwarding" is probably a bad way to describe this service, since it is likely to make many people think (as it made me think) "isn't this just a more efficient tool for sending spam?".
What this really is is an easy way of setting up email aliases. I think that should be the tag line.
Still not what either I or the article is talking about. Yes, the person designing the service has to know about alias files (or whatever other back end is being used), but the user doesn't have to know or care. I'm talking about what the user sees.
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.
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!
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.
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.
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. :)
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.
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.
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.
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.
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.
"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.
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").
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).
I remember penet from the early Internet, although I never used it...
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!
One other thing... before users sign up, perhaps you could tell them what will happen to their data if you are ever served by Law Enforcement with a Warrant to give them some user's data... If the answer is that you're going to give your users' data to Law Enforcement (the right answer, as far as I know), then your "private" / "privacy protecting" service -- really wasn't all that "private" / "privacy protecting", now was it?
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...
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.
You might very well have created the best anonymous email service out there, which will be used and cherished by many thousands of happy users who use it legally, ethically, morally, etc.
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.
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.
> 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?
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.
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.
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!
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.
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!
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.
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.
I am surprised the people sending me physical junk mail haven’t lobbied the post office to provide all their customers with email boxes along with physical mail boxes and then stuff then with junk email along with important governmental notices only going through post office email boxes that have tiny storage quotas so you have to manually delete all the junk email, otherwise they will stop delivering the email that you actually care about and refreshing the junk email...
USPS' "informed delivery" service is headed in that direction. They email you attached advertisements along with the scanned mail pictures. Sometimes they just send you an advertisement when you're not even getting mail that day. It's atrocious
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.
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 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.
This is great! Props for getting it polished and putting it out there. Also I was really pleased to open the GitHub repo and immediately recognise it as a Laravel app! :D so I’m looking forward even more to giving this a good go
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.
Cool. I've had a similar idea kicking around in my head for a few years. How do you think about the compromise/disclosure risk of the data you keep that associates the subscriber account with aliases?
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 was interested in hashed aliases as well, though I haven't had any terribly bright ideas about how to mesh platform-blindness with a revenue model that at least covers costs.
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...
Spamgourmet is amazing and has been really responsive when it comes to fixing the sorts of issues that come up when running an email service (e.g. blacklisted IPs, messages getting shunted to spam, etc). I've been using it since 2007 and it's kept more than 10,000 junk emails out of my inbox. I think it actually started almost 20 years ago.
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.
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.
As a small SAAS owner I’m always very ambivalent about these things. I use throw away email addresses myself but there is nothing more annoying than seeing the same users sign up over and over again for trials.
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.
I’ve been using Inbucket[1] for a few years as a self hosted temp mail service. I wouldn’t use it for permanent addresses but for testing and burner-like uses it works well.
> Our system will then silently discard any further emails and you won't be forwarded anything else for that alias.
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.
Isn't that what spam filters do though? Or is there some technicality since they're technically not silently dropped but instead in a folder that you don't care about.
Yeah I think it's something like that. Actively rejecting on an SMTP level is fine too, since the sender is now aware. Just dropping it completely silently seemed to be the problem from what I recall.
I feel like it was either here on HN, or on some article linked here, a few weeks/months ago. But I could be wrong... vague recollection at the moment. I don't think the reason was mentioned explicitly but to me it's pretty obvious that it would be a question of accountability.
Awesome! I wanted to have something like this for ever and planned to build it myself using a combination of gmail and Flow or something. Now LastPass , 1Password etc. need to integrate it so every time you generate a new password you can add a random email to the mix.
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.
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."
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.
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.
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.
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!