I want a secure web app, and allowing infinite email confirmations and re-sends seems insecure. I was thinking 3 but would love an opinion from someone with experience.


Sending email with Postmark and don't want an attacker to burn through unlimited email credits. I also don't want to spam my users if an attacker were to send a bunch of emails.

That said, I don't want well-meaning users to not be able to re-send a confirmation. I was hoping someone would say "we use x number but upped it to x number and have had no more complaints.

Or maybe limiting this is stupid, for some other reason. I don't know.

  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Apr 8 '15 at 14:07
  • @gnat not sure what i would research, nothing came up on google or searching on here. – AJcodez Apr 8 '15 at 14:12
  • 1
    You mention security. The most important part of security is knowing what you're defending against. So, what is your threat model? What is limiting of re-sends defending against? As it is, your question is only asking for a fairly arbitrary number. Someone might use 2, someone else infinite resends, each for a reason that makes sense in their context. That's not useful. A better question would be: “I'm building a web app and want to protect my users from X-attacks. So far, I thought of limiting Y to 3. Is this limit reasonable given X, or is there a better defense Z for this scenario?” – amon Apr 8 '15 at 14:53

One should only resend once there is proof of delivery failure.

Some email providers use a period of time to attempt to deliver the email. A typical the default is 48 hours. Over this 48 hour period they may attempt to deliver the email N number of times, where N could be 8, 10, etc.

This is done to help on transient email errors. For example, what if the person's inbox is full or thier service provider went down. All of these return specific errors, for example the SMTP service call will return a 422 if the mail box is full. A person could delete some of the mail and then that message would go through in that case on a subsequent attempt.

For a list of all codes, please see here:


For these types of errors, the provider would retry the message (automatically) again at a later period. Some returns are fatal, others may be classified as transient which may clear up after a period of time.

Finally after a period of time (say 48 hours) if the email is still not sent, they would report a delivery failure. At that point, the delivery is considered a failure and manual intervention would be required.

Only then would one want to attempt another confirmation or perhaps contact the user to see if the errors can be corrected.

The web application you are designing should take those factors into account when sending email.

  • Interesting, so you wouldn't allow re-send? I guess that makes sense come to think of it. – AJcodez Apr 8 '15 at 22:01
  • @AjCodez - Correct. Attempt delivery, if failed mark as failed and then some sort of manual followup. – Jon Raynor Apr 9 '15 at 13:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.