I'm new to the community, reading the constributing.md it says:
- All pull requests must receive at least one approval through the GitHub UI.
Wasn't sure if that's review by a maintainer after pull or required from any person who is not you beforehand.
I'll maybe just stomp on and I'm sure someone will educate me if I get it wrong.
I'll pop link to branch and sample email here if I get around to it though, the more heads the better.
I think they mean that one of the certbot team has to review and approve the pull request before it can be merged. So yes, it would require making a pull request first before it can be reviewed. And by the certbot team, not just anyone 
I don't think the production email template is in public version control (just this test one), but yes, I think if you wrote a new email and posted it here, it would be very useful. Then we could tag one of the relevant people to review it.
That's correct.
I agree with @_az's early assessment: The most friendly thing, for most people, would be to fix expiration-mailer: Warn about expiring names, rather than expiring certificates ¡ Issue #4702 ¡ letsencrypt/boulder ¡ GitHub. That way, rather than sending you mail and asking you to check serial numbers, you simply wouldn't get mail in most cases. I know it's been a while that we haven't implement that fix yet, but it is definitely still something that's constantly on my mind.
As a stopgap until we improve our expiration emails, there are a couple of very good third-party services that notify you about certificate expirations across all your hostnames. They even work with a mix of CAs! I suspect they have dedicated more time to usability of their notifications than we have, and may have this problem solved:
My reading of the referenced issue (https://github.com/letsencrypt/boulder/issues/4702) doesn't cover cases where the controlling le account for a cert is changed. I think we are getting emails about expiring certs because of this. So having a fingerprint/serial number would useful to know the email is about a cert from the old account.
My plan for that issue,l is actually to consider the case where a new certificate exists on a different account to count as a renewal. That's a fairly common situation, for instance if someone rebuilds a server and does not migrate their ACME account.
It may be more useful to not assume that. When there is one sysadmin, that assumption is beneficial because it will limit "noise". When there are multiple sysadmins, or someone has one of their junior employees handle an issue (and muck things up), this can create problems.
It would be nice to receive an email in those situations that says something like- "This Certificate was renewed by another account and may not need attention".
I feel like experience shows that adding more words doesn't help. The current email contains the following text which tries to explain false positives:
In particular, note that this reminder email is still sent if you've obtained a slightly different certificate by adding or removing names. If you've replaced this certificate with a newer one that covers more or fewer names than the list above, you may be able to ignore this message.
and it's been flying over users' heads for its entire existence. Maybe there's too much to read, maybe it requires too much thinking and interpretation.
Maybe one false positive is preferable to one false negative, but if it's at a ratio of e.g. 10:1, forget about it. Please do whatever is more useful for the average user.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.