Verify return code: 10 (certificate has expired)
...
Issuer: C=US, O=Let's Encrypt, CN=R3
Validity
Not Before: Jan 21 22:10:55 2023 GMT
Not After : Apr 21 22:10:54 2023 GMT
Subject: CN=www.postfix.com
Peter
* Peter Ajamian via Postfix-users:
> Verify return code: 10 (certificate has expired)
Thanks. For some reason, the web server had not been restarted after the
last certificate update, which normally happens automatically. I just
restarted the server process manually.
-Ralph
_
On 22/04/23 22:18, Ralph Seichter via Postfix-users wrote:
* Peter Ajamian via Postfix-users:
Verify return code: 10 (certificate has expired)
Thanks. For some reason, the web server had not been restarted after the
last certificate update, which normally happens automatically. I just
restart
* Peter Ajamian via Postfix-users:
Verify return code: 10 (certificate has expired)
On 22/04/23 22:18, Ralph Seichter via Postfix-users wrote:
Thanks. For some reason, the web server had not been restarted after the
last certificate update, which normally happens automatically. I just
restart
On Sat, Apr 22, 2023 at 01:08:06PM +0200, Matus UHLAR - fantomas via
Postfix-users wrote:
> >You should set a POST_HOOK in certbot renew (assuming you're using
> >certbot, that is) that restarts or reloads the web server.
>
> I guess this exactly what failed.
The "post hooks" in certbot are no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, 2023-04-22 at 11:25 -0400, Viktor Dukhovni via Postfix-users
wrote:
> On Sat, Apr 22, 2023 at 01:08:06PM +0200, Matus UHLAR - fantomas via
> Postfix-users wrote:
>
> > > You should set a POST_HOOK in certbot renew (assuming you're using
>
On Sat, Apr 22, 2023 at 11:25:14AM -0400, Viktor Dukhovni via Postfix-users
wrote:
> On Sat, Apr 22, 2023 at 01:08:06PM +0200, Matus UHLAR - fantomas via
> Postfix-users wrote:
>
> > >You should set a POST_HOOK in certbot renew (assuming you're using
> > >certbot, that is) that restarts or relo
I've said this in the past, certbot was badly coded, used too much memory and
lacked vision. But there are two great alternatives, written as bash scripts
(thats right.. bash scripts!)
https://github.com/acmesh-official/acme.sh
https://github.com/dehydrated-io/dehydrated
give them a try, they
> It was common practice to allow your (from the ISP PoV) clients to submit
> mail via SMTP, through port 25 on your mailserver. Some ISPs still do
this.
> The client authentication here is done via client IP address, no further
> checks.
>
> Next, enciphered and authenticated mail submission beca
* Viktor Dukhovni via Postfix-users:
> The "post hooks" in certbot are not *reliable*.
For the curious among you: I use dehydrated [1], which integrates nicely
with my other automation, including Ansible [2]. An Ansible handler is
used to restart the web server if certificates were updated, and t
I have read and re-read the documentation regarding transport(5) here:
https://www.postfix.org/transport.5.html
First, the docs for things like say "sender_dependent_relayhost_maps" say:
"This information is overruled with... the transport(5) table."
but what the heck is "the transport(5) table"
On Sat, Apr 22, 2023 at 05:56:12PM -0700, Andrew Athan via Postfix-users wrote:
> "This information is overruled with... the transport(5) table."
In other words, "transport_maps", a logical dictionary built from
a list of component tables (some of which may also be composite).
> But "sender_depe
I hope the message quoting/formatting in my response works as expected. If
not let me know and I will rely less on gmail's formatter.
>
> "This information is overruled with... the transport(5) table."
>
> In other words, "transport_maps", a logical dictionary built from
> a list of component tabl
Oh, sorry, one last (lol) thing ... since it doesn't seem like "@" is ever
part of searches do you think it might be wise to change the docs so that
instead of saying " sender-dependent override for the global relayhost
parameter setting. The tables are searched by the envelope sender address
and @
On Sat, Apr 22, 2023 at 07:58:25PM -0700, Andrew Athan wrote:
> If I understand it well enough I'll write and submit a doc PR.
This is unlikely to be productive.
> If I put all this together what I think I'm hearing is that transport_map
> overrides everything
The transport(5) table has the hig
Andrew Athan via Postfix-users writes:
> (...)
> My goal is to silently discard all inbound mail from a certain
> domain. Or actually, I may wish to redirect all of that mail either to
> a flat file (similar to the proposed blackhole transport) or (...)
Go with easy way. See header_checks. `man
16 matches
Mail list logo
