I'm working on a website that features many different types of emails. Users have accounts, and when logged in they have access to a setting page that they can use to customize what types of emails they receive.

However, I'd like to also give users an easy way to unsubscribe directly in the emails they receive.

I've looked into list unsubscribe headers as well as creating some type of one click link that would unsubscribe a user from that type of email without requiring login or further action. The later would probably require me to break convention and make changes to the database in response to a GET on the link.

However, am I incorrect in thinking that either of these would require me to generate and permanently store a unique identifier in my database for every email I ever send, really complicating email delivery? Without that, I'm not sure how I would be able to uniquely identify a user and a type of email in order to change their email preferences, and this identifier would need to be stored forever as a user could have an email sitting in their inbox for a long time before they decide to act on it.

Alternatively, I was considering having a no-login page for managing email preferences. In contrast to above where I would need one of these identifiers for each email, this would only need one identifier per user, with no generation or other action required on sending an email.

All of these raise security issues, and they could potentially be used by people to tamper with others' email preferences. This could be mitigated somewhat by ensuring that the identifier is really difficult to guess.

For the once per user identifier approach, I was considering generating the identifier by passing a user's ID through some type of encryption algorithm, is this a sound approach? For the per-email identifiers, perhaps I could use a user's ID appended to the time.

However, even this would not eliminate the problem entirely, as this would really just be security through obscurity, and anyone with the URL could tamper, and in the end the main defense would have to be that most people aren't so bored as to tamper with other people's email preferences.

Are there any other alternatives I've missed, or issues or solutions with these that anyone can provide insight on? What are best practices in this area?

Edit: Here is the alternative I missed for anyone coming across this later. The smart way to do this is to include in the unsubscribe link a cryptographic signature of the user to be unsubscribed and what they are to be unsubscribed from. Nothing at all needs to be stored in the database, while being on par with security with the solutions I'd been considering.

1 Answer 1


Why would you need to store a unique identifier for each email you send? You just need a unique identifier for each user, as settings would surely be user-specific.

Typically, email subscription settings wouldn't be considered high-risk or high-security - after all, they can simply resubscribe if they want the email. I would encrypt the user's id (and maybe their email address or some other salt) to give each user a unique unsubscribe key that is added into a link in the footer of each email.

Storing a unique key per user in a database shouldn't concern you. Chances are if you have the resources to send mass mailings on a regular bases, you have the resources to store a 32 character key.

  • It was only the per email keys I was worried about from a complexity/overhead point of view. Upon further consideration though, you're right, I wouldn't need a unique identifier for each email. My initial thought was I would need it to determine not only the user, but the type of email being unsubscribed. However, under a one click unsubscribe scheme, the most I would need is one unique identifier per user per each type of email they could be unsubscribed from. Regarding security, even if they could just resubscribe, it would be an annoyance if a prankster was constantly re-unsubscribing them.
    – Mike Liu
    Jul 3, 2012 at 15:28
  • 1
    @MikeLiu - It's safe to say a "prankster" will probably never go to the trouble of attempting to brute-force or try and rainbow-table unsubscribe your user as that might take years - and you could always implement measures like IP blocking if there are x amount of invalid requests. The only realistic way for them to have a user's key is by intercepting their mail, in which case it's sort of the user's fault. To help protect them though, all you have to do is simply generate a new key each time they subscribe, rather than 'renewing' the old one.
    – Anonymous
    Jul 3, 2012 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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