On 2025/04/07 10:43, Mark Milhollan via mailop wrote: > On Mon, 7 Apr 2025, Viktor Dukhovni wrote: > > On Mon, Apr 07, 2025 at 12:47:33PM -0400, Bill Cole via mailop wrote: > > > On 2025-04-07 at 09:38:56 UTC-0400 (Mon, 7 Apr 2025 06:38:56 -0700 (PDT)) > > > Mark Milhollan via mailop <lists-mai...@milhollan.com> > > > is rumored to have said: > > > > > Mainly it is for browsers but that would force some senders to go along > > > > if their receivers began rejecting expired certificates > > > > > > It is exceedingly rare for senders to use *any* certificate in a SMTP TLS > > > session. > > > > The OP is suggesting that servers would need to set short expiration > > times even on self-signed certs, > > I did have senders and receivers swapped though. I.e., some senders (SMTP > clients) might refuse to deliver messages to receivers (SMTP servers) that > are using a certificate that is expired or has too much validity (per CA/B). > > This might, in effect, force those receivers to present a more normal > certificate which if it must happen every 30-ish days almost requires the > use of automation.
If they're doing certificate validation in the first place (not that common for email, but it does happen): yes, expired certs are quite likely to result in failure. CA/B requirements are more involved in whether a CA's certificate gets added to various root certificate programmes or not - it's not impossible that some software might check this, but it's definitely not the usual case in libraries implementing TLS, and it would hard to be foresee a situation where someone is allowing self-signed certs but also enforcing CA/B validity constraints. (And for CA-signed certificates, it's mostly irrelevant because the CAs won't be issuing them beyond the requirements anyway, assuming they want to stay in the various root stores). _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
