Re: Support Ended for Expiration Notification Emails

[Osiris]

Continuing the discussion from Support Ended for Expiration Notification Emails:

@lenaunderwood

As a result, Let's Encrypt is no longer storing new email addresses. Subscribers may notice that when creating or updating an account, the API response no longer contains contact information, regardless of the contact information provided in the request.

Shouldn't Boulder return an error when an ACME client attempts to set an email address to the account? Now an update just goes to /dev/null, as nothing is being stored in the account, but Boulder returns a HTTP 200 "everything went OK!". But that might not be what the user was expecting. Although to be fair, it did return an account object without the contact info.. So the client could see the update didn't take place.

Not sure what's the expected result here is: Boulder returning an error when asked for a contact update or the ACME client being smarter..

[Nummer378]

@Osiris

Shouldn't Boulder return an error when an ACME client attempts to set an email address to the account? Now an update just goes to /dev/null

Last I heard, the plan was that if you specify an email that will be automatically signed up for the newsletter. The newsletter isn't tied to a particular ACME account, but Let's Encrypt can still use it to send mass-emails. So the email isn't entirely useless. Also, erroring out would probably break a lot of clients out there

[jvanasco]

Does anyone know if this is being ended in staging as well?

I was still getting expiry emails from staging earlier this week. I did not risk unsubscribing, because I was unsure if it pointed to a separate mandrill integration than production and did not want to risk losing a few days worth of these alerts. (I don't use the alerts for expiry concerns, I use them as a fallback to keep track of past deployments and configurations. )

[lenaunderwood]

As of yesterday, we are not sending expiry emails in staging anymore either.

[griffin]

@Osiris

I think silently "passing" outdated requests is better than overtly breaking a massive number of outdated client instances. Maybe I'm misunderstanding your ask here?

[aarongable]

@Osiris

Shouldn't Boulder return an error when an ACME client attempts to set an email address to the account? Now an update just goes to /dev/null, as nothing is being stored in the account, but Boulder returns a HTTP 200 "everything went OK!". But that might not be what the user was expecting.

It's a fair question! But given our metrics, it's definitely better for us to simply allow the new-account or update-account request to succeed, but return an account object clearly showing that we have not persisted the contact info. If we chose to error out all new-account or update-account requests which contain contact info, we would break millions of clients.

[Osiris]

@Nummer378

Also, erroring out would probably break a lot of clients out there

@griffin

breaking a massive number of outdated client instances

@aarongable

we would break millions of clients

Yeah, that wouldn't be great either..

I'm afraid there's not much an ACME server can do to relay the info back to the user/client, besides erroring out — which is not an option — right?

[webprofusion]

Many (most?) acme clients don't have error reporting/monitoring, so if you break renewals the only way the user will find out is when their certificates expire, or if they are monitoring current certs then they see the expiry approaching when it should have renewed.

I do have a solution in the works for general early warning of renewal failures (across popular acme clients), but ultimately that only works if people seek it out and use it, or if people build their own processes to do the same.