Throttling Email Requests

Question

I have some questions regarding user experience when it comes to throttling email requests from public pages in my app such as Signup Email Verification and Password Recovery.

First of all, I want to throttle requests because I do not want to spam email recipients with my app's transactional emails. I am concerned about User A trying to signup an account using User B's email address for the sake of annoying User B at my app's expense (like getting flagged as spam)

I haven't read a fool proof approach to protect apps from these types of attacks (if you know of one, I would really appreciate it if you can tell me).

Currently I have implemented a captcha, but I would also like to implement throttling. So my questions would be:

1. How many times would I let a user send a request before I throttle sending emails for the same request? I did a single quick test with facebook, and I learned they throttle password recovery emails after the 3rd try.

2. How long should I throttle the request? 10 minutes? 30 minutes?

3. Should I A) let the user know I throttled the request, like placing a notice? or B) Act like I didn't do anything? Facebook did (B). I think it is more of a security thing? But, my problem is that, if I choose (B), a legitimate user not receiving any emails would keep on requesting for the whole throttling period. Which would be very bad UX?

Answer 1

Something to remember about transactional emails is that they should be intentionally triggered by the user. What this means is a site shouldn't send a confirmation or password reset email unless the user directly requests it.

Why does that matter? Because if the user intentionally did something, you don't need to ask them to do it again. They already went through the trouble. Though you may be concerned about people exploiting the system, design for your typical user first. Once a particular form is submitted, like for a password reset, there's no reason to even have that form be available anymore until the password has been reset. This means, simply don't send the same email twice. Of course, minor exceptions exist, but for the most part there isn't a good reason for a user to receive the same email over and over again.

When it comes to throttling rates, the answer to what you should do specifically is this: For those on dedicated IPs, your throttle rate should be fine tuned to match your IP reputation. (It never hurts to know this.) If you're on a shared IP, your host might be handling that for you. This means, quite commonly, err on the safe side and throttle as much as possible. The last thing you want is to be flagged by an ISP as spam.

You don't need to let the user know about your batch process. Only inform the user about their experience and how that experience is being affected. This means saying something to the effect of:

We sent you an email [to do a thing]. You should see it in your inbox within [a timeframe]. If you don't see it, *let us know* and we'll sort things out.

If you detect that something shady is likely going on, then lock the account, but don't blame the user. Just inform them through a secure method of the steps that should be taken to fix things.