Why not use the email address in the unsubscribe link

Question

Give me a few reasons why you should NOT include email addresses in the text form for unsubscribe links that are sent to our newsletters.

Now it is:

xyz.net/unsubscrible?uid=123& email=[e-mail] 

I click for:

 xyz.net/unsubscrible?uid=123&key=(encrpted_email_md5hash). 

I do not really like the idea of ​​sending email addresses in text form, but I need to convince my manager of possible threats.

Update. Despite the fact that all the answers suggested how I should protect him, and NOT the reason why I should protect her, I think that the answer to the question "Answer to the question" is most suitable.

Answer 1

For the same reason that banks do not have links such as

 bank.com/applycredit?ssn=123456789&name=john+smith&dob=19500101&married=true&address=... 

it can be easily intercepted and interpreted.

Answer 2

Because then you can unsubscribe from someone else. Ideally, you want to use only the key:

 xyz.net/unsubscrible?key=<some unique cryptographic hash> 

I should not guess identifiers and emails and cause some actions for someone else.

Answer 3

Almost every newsletter I receive has a disclaimer below, something like:

This email was sent to [e-mail]. To unsubscribe, click this link: xxxx

I believe that an explicit list of my own email address in the newsletter will be helpful. Whether the addy email address is a link or not seems to me irrelevant.

---

Suppose you are not publishing an email address in the actual text of the message or in the unsubscribe link. The email address is still in the email header. As a result, I really don't see the need or arguments for disguising it in the unsubscribe link.

Answer 4

Why not? Do not turn it on because it is not needed. What is the data used for? Suggest that we not include anything that we really do not need in a querystring.

The only thing really required is a unique identifier. It looks like you already have a unique identifier in querystring: uid .

Potential issue: what caused me to automatically create subscription URLs and hit ?uid= 1 to 10 million?

Suggestion: create a custom index for each user in your table. Use this as a token to unsubscribe. It will not be predictable or vulnerable to automatic attacks.

 foo.com/unsubscribe?u=<guid> 

Answer 5

I assume uid is the user id. If you know the user ID, then you must determine the email address with this right? It seems that the letter in the URL does nothing. I think if you do not need to include personal information, it is better not to do this.

Answer 6

I agree that you do not need an email address if you have another method of uniquely identifying the user. The only reason may be to indicate to the user the email address to which he is subscribed, but that he is also outdated since he / she clearly receives the email.

Answer 7

I could give you a very tricky answer, but you will find that the full email address is not so bad.

The presence of URLs containing an email address can be used by malicious proxy servers (i.e. from public places) to store addresses and send spam. But if I assume that there is something malicious in a public place, it is better to install the keylogger on a public computer and make it even worse.

Another point may be this: if you send emails to valuable customers, an attacker can create email addresses and unsubscribe them, which actually reduces your communication power. To do this, you can add a crypto checksum to your URL (don’t require CAPTCHA, people don’t like it when unsubscribing), but then by encrypting (or simply encoding it in an obvious way) the entire mailing address that you could solve the problem without using two parameters.

Answer 8

Since you are not using https , request parameters can be tracked. This is a serious problem for mobile and laptop users in places with free wifi-like coffee shops.

And since the uid is already mapped to an email address, you do not need to expose identifying information, such as an email address for snoopers.

You need to make sure that the cancellation will not happen as soon as they click on the link. This is the GET URL that should be idempotent (see Section 9.1 ), that is, it should not be authorized to modify the underlying database.

And I should not have the authority to unsubscribe, just knowing your email address, which I could do by creating a URL if uid is either guessed or not required.