There is rate limiting on both sender IP, recipient email and recipient domain. As well as unsubscribing. Will improve this if it does start getting abused
So this will need to be limited to just several addresses?
> rate limiting on... recipient domain
Including gmail.com and outlook.com?
I'd guess that the simplest option would be to require some sort of registration and requiring an "API token" with every request. Not as clean and easy-peasy, but far more practical for moderation purposes.
Alternatively, a self-hosted version of the same would solve these problems. But if you are planning on turning this into a $ service at some point, that's probably not going to work because of that.
> So this will need to be limited to just several addresses?
If this is in reference to rate limiting, each address is limited seperately, so if you send a message to 4 addresses and one's over the limit, it will fail and the rest willt work.
If you mean is there a limit to the number fo addresses per request, then there actually isn't and that's a VERY good point, so thank you!
>> rate limiting on... recipient domain
> Including gmail.com and outlook.com?
Yeh, the limit per domain is pretty high (compared to per email address).
> I'd guess that the simplest option would be to require some sort of registration and requiring an "API token" with every request. Not as clean and easy-peasy, but far more practical for moderation purposes.
If you having to register, verify your account, get an API key etc, then it's getting on towards the complexity of other services, which is, both, exactly what I was trying to avoid and means this is a cut-down version of other services, which then makes it redundant :) It was mainly meant for sending a notification to yourself when a command completes to check email delivery and such, not high volumes of traffic.
I run a similar service (but for browser/mobile notifications instead of emails[1]) and take basically that approach. So far abuse hasn't been an issue with ~50k notifications sent.
