Edit: Ask HN: Any suggestions for solving this? Hitting the frontpage means people are spamming the login form with bogus addresses like firstname.lastname@example.org that bounce and cause trouble for us and the ESPs. Not ideal, but I'm not sure how to solve this for a small scale side-project. Discussion in https://github.com/portier/portier-broker/issues/96
I used to use a telnet based approach to check if the account exists, but most servers these day don't respond with the correct error response if an account does not exist.
As far as I can tell, the trick is building up that initial reputation and doing as much mitigation as possible up front: checking for MX records, rate limiting, soft-failing with CAPTCHAs for things that look suspicious, etc.
I know what I'll be hacking on for the rest of the week. :)
Yes you need to protect the log in page by rate limiting, Captcha, looking up mx records, etc.
One approach I have thought would be good to use is a rainbow table like approach. Most people are not very imaginative about the fake email accounts they use.
I've been thinking about this space for a while (e.g. https://news.ycombinator.com/item?id=12411204 ) and would be happy to chat or brainstorm.
The pricing might be prohibitive for your usage. I don't know if any of them offer discounts/free usage for open source projects. (Not endorsing any of them; they've been sitting on my own list of things to investigate.)
Also, as an aside: SendGrid may not be suitable for transactional email you need delivered consistently quickly, unless you purchase their dedicated IP option. (And if you're bouncing a lot, a dedicated IP could actually be counterproductive for your delivery.) Recent incident [https://sendgrid.com/docs/Classroom/Deliver/shared_ip_thrott...] and discussion [https://news.ycombinator.com/item?id=12142728].
Having to wait 20 minutes to receive an e-mail so that i can login would be a real PITA.
Also, "recipient verification" (which some others have managed) isn't a good long-term solution.
Lots of services already depend on email verification during signup or password recovery. I'd love to know, have you seen any interesting solutions around greylisting in the wild?
To "bypass" or somehow defeat greylisting, you mean?
I'm not aware of any via workarounds, no. I would certainly be interested in hearing about any , though, since I use greylisting on mail servers with thousands of users.
In some cases, such as when using OpenBSD's spamd , you (an SMTP client) don't even get to talk to the "real" SMTP server until you've successfully "passed the tests". This is the primary implementation of greylisting that I use, FWIW.
Having that form of validation should help since DKIM was made to specifically stop email spoofing; and anyone serious about implementing Portier would understand that need.
Outlook/Gmail etc aren't likely to be flagged by ESP's for the most part as those have reputation and rudimentary spoofing protection, at least more than email@example.com anyway.
Persons using custom domains are usually the admins of those domains, and Office 365/GApps/Registrars etc. provide simple ways to enable DKIM.
In the past, there was an SPF RR type but that's been deprecated.
Won't help if you get flooded with a bunch of invalid usernames at a big email provider, but as your volume of legitimate volume grows the bad ones should hurt less.
Nobody who actually cares about reliably receiving mail should depend on implicit MX. Of all the things mail administrators have to do these days, like reverse lookup, SPF, and DKIM, is it reasonable to care about anyone who can't be bothered with MX records?
I'd gladly reject such domains if doing so improved overall mail delivery rate to popular domains. And unlike 99% of situations where an email fails to show up, the sending web site can instantly report the reason for failure.
I manage e-mail systems with thousands of users and a fair number of domains as well. In most cases, I also manage the authoritative DNS servers for these domains so I make sure that all the appropriate records (MX, TXTs for SPF, DKIM, etc.) are set up properly.
You're right, though. If example.com hasn't bothered setting up an MX record for example.com -- even if mail is hosted on the same machine as identified in the A RR -- they probably aren't worth worrying about. It seems reasonable to conclude that they really aren't too concerned about being able to receive mail.