Boulder: Better Expiry Email System

[GriffinSoftware]

In the community there has been relatively steady demand for a better expiry email system. Here are two of the latest instances of confusion caused by the current system:

https://community.letsencrypt.org/t/unable-to-unsubscribe-from-email/148547

https://community.letsencrypt.org/t/expiry-date-in-email-does-not-match-the-browser/148584

My proposal is to have a brainstorming session in the community to come up with suggestions/direction for a better expiry email system.

[jprenken]

This is on our internal radar, too, and we have preliminary plans to rework how we handle these e-mails. The work will be complicated by needing to integrate with our external Email Service Provider (ESP)'s systems, including compliance (i.e. it being highly critical to respect unsubscribe requests).

[GriffinSoftware]

I'm glad to hear it's forthcoming. 😊

Figured I'd open up the discussion to mull over the details amongst the crew.

[jsha]

This is the main improvement I want to make, which I think should fix about 90% of these cases: https://github.com/letsencrypt/boulder/issues/4702

Secondarily, https://github.com/letsencrypt/boulder/issues/2475 and https://github.com/letsencrypt/boulder/issues/4695

[GriffinSoftware]

While I believe the suggestion in #4702 will handle the straightforward cases, my primary concern is that there are many users who lose track of the spaghetti of certificate trails they create. If the concept is "a valid ( unexpired and unrevoked) certificate [exists == is installed] for this domain", there could be dire consequences through deliberate withholding of an expiry notice. In essence, since we have no direct way of knowing which certificate covering a domain name a user intends to be installed (short of querying what is actually installed for that domain name), I feel like it's tricky to make any assumption that errs on the side of false negatives in terms of expiry emails sent.

[webprofusion-chrisc]

As an extension of this it would be great if you could follow a link in the expiry emails to then access your Let's Encrypt 'account' (as LE see it) via a web interface, to manage subscription prefs, see issued certs, possibly perform revokes etc. Some vendors provide a 'magic link' method for this so you don't have to set a password.

As a further extension of that you could then use that as a conduit for paid support tickets (i.e. paid support from LE to help solve an immediate cert renewal problem) - that may not be something LE wants to provide but it seems it would help fund the org/scalability.

[GriffinSoftware]

Just wanted to reference #5218 (which the current issue supersedes) in order to include the discussion @jsha and I had there.