Allow unsubscribing from expiration emails on per-certificate basis

[cpu]

Presently unsubscribing is an all or nothing action, and resubscribing is not easy. It would be useful if users could unsubscribe on a per-certificate basis.

This would be a significant architectural shift from what we do today, but perhaps one day!

[jsoref]

Adding the word "expiring" to this ticket because I searched for that keyword...

[jsoref]

So, there are three granularities afaict:

1. subscriber_email
2. domain
3. certificate

Afaiu, currently boulder fills in a template: to:$subscriber_email

cert for $domain is expiring

[suffix provided by provider]

I'm pretty sure (at the cost of managing subscriptions in boulder), an extra url could be dumped into the template which allows tuning the subscription for subscriber_email/domain/certificate...

[jsha]

at the cost of managing subscriptions in boulder

Yep, this is the key blocker. :-) Right now we use our email provider's built-in unsubscribe functionality, which is less than ideal because it doesn't allow this type of granularity. We can move this into Boulder but it's a significant chunk of work.

[ppKrauss]

Thanks @cpu, it is an important issue!

The simplest solution to the main problem is to offer, into the body of the email, a link (an URL) to unsubscribing on per-certificate basis.

PS: as "secret link" it can use some hash (ex. SHA256 of certificate-ID, time and user credentials), or a check-mail-number form... As strategy to avoid malicious unsubscription.

[ppKrauss]

Why it is important?

It is my personal vision, please, to avoid confusion see as parallel discussion ;-)

1. The "certbot system" (Certbot+Boulder) do all. Certbot-client do the certificates and the communication with Boulder-server (it is a webservice working for certbot clients), Bounder send e-mails.
   We can't isolate "only certbot bugs" from "only Bounder bugs", it is an error to ignore the "system-level" problems, the coupling between Certbot and Bounder projects.

2. When deleteing and revoking a certificate X using certbot commands, the user's expectative is to turn-off the emails automatically. This expectative is coherent, must be respected (!)...
   If there are a communication problem, it is a "certbot system" problem, therefore, a "bug of the system".

3. The message ignores the fact that Certificate X not exists for user context, not exist in the server of the Certificate X... So user not need e-mail alerts about it: this is like SPAM, was unsolicited.

Solving other problems with this issue

Supposed non-related problems will lost impact, or can even be solved,

• the certbot messages can add the URL after revoke or renew, or in renew contexts... See Certbot's issue #5099

• See a lot of community.letsencrypt.org/ cases as 24583, 18734, ...

• ... need to list all? ...