> You're right that there are a lot of bad actors out there, but in my experience they are pretty easy to deal with if you set things up right.

Sure, it's possible to defend against hackers to a degree, but even using a completely static website still leaves you open to attack surfaces in the webserver software or to remotely exploitable vulnerabilities in the Linux network stack.

> FYI you are misusing "greylist."

I assume we share the definition of "greylisting" to be the receiver MTA blocking the first delivery of an incoming email with "try again later", and the sender MTA then retrying after that time frame? If yes then this exactly describes my experience in administrating self-hosted mail servers with popular large mail providers.

Ah, my apologies, I jumped to conclusions that you were misusing "greylisting". I've never actually checked if I'm getting greylisted sending to large providers, but I think initial greylisting of new addressses is pretty reasonable.

My mail server (MailInABox) has postgrey enabled by default, greylisting incoming email each time email is received from a new address. I thought that was a little overzealous so turned it off.

It might be reasonable, but highly annoying if you run a, say, sign-up double opt-in or an email-based second factor/OTP. Customers don't like waiting an hour or whatever greylisting period, and so as a SaaS operator you are all but forced to go to one of the big e-mail senders like AWS SES because you don't stand a chance otherwise.

Ah, darn... I'm starting a web app with email verification now, using my own email server for sending and I didn't consider this. Thanks for the warning. Guess I'm about to find out how bad it is.

Pretty annoying to test for this reliably as well...