one-click (oneclick) unsubscribe RFC 8058 best practices

[Arnaudv6]

Hi,

Servers sending many emails must comply with rfc8058:
(sender must set a header with an unsubscribe link).
To my understanding, there is no validity period to that link:
link must be valid almost for ever (until unsubscription).

I have found no answer to following questions, here or elsewhere:

• must link change for each message to same dest?
• how much entropy is desirable for hard-to-forge part in consequence?
• other recommendations?

What would you suggest?

[g4lb]

RFC 8058 does not require a new link for each message, and it gives no entropy value.
I suggest a random token of at least 64 bits, the OWASP session ID minimum.

[Arnaudv6]

Hi @g4lb and thanks for your input.
I agree that no-rotation makes things simpler, we all like simple.
I was going for that same 8B entropy for lack of another reference.

The valid forever part still unsettles me though:
For instance, should we protect it with symmetric-encryption in case an attacker accesses DB?

Side note: it just occurred to me that spec does not enforce header removal on message forwarding...?
Email has a lot more implied, complex risks than most users perceive I think.

[g4lb]

Use a hash, not encryption: store the SHA-256 hash of the token. A leaked database then gives no valid links.
RFC 8058 does not cover forwarding. A person who gets a forwarded message can unsubscribe the original recipient.

[Arnaudv6]

Hash means I can't create the link (with original value)? Or I don't get you?

[g4lb]

Yes. Instead, make the token as an HMAC of the recipient and the list ID, with a secret key outside the database. You store nothing, you get the same link each time, and a leaked database gives no valid links.

[Arnaudv6]

I like this idea, thanks !