On Sat, Jan 08, 2022 at 01:05:41PM +1100, raf wrote:
> Probably no real harm done. OCSP stapling is just a way to make it
> more private and more efficient for a web browser to verify that a
> website's certificate hasn't been revoked, by providing that
> information in-band, so the browser doesn'
On Fri, Jan 07, 2022 at 05:47:55PM -0500, PGNet Dev wrote:
> > Postfix has no CRL or OCSP support, and none is planned.
>
> other than reporting the bad result, does the current (bad) config cause any
> actual mail delivery breakage?
Probably no real harm done. OCSP stapling is just a way
to m
On Fri, Jan 07, 2022 at 07:28:32AM -0500, Viktor Dukhovni
wrote:
> On Fri, Jan 07, 2022 at 11:34:32AM +0100, Charlotte 🦝 Delenk wrote:
>
> > I was trying to harden my postfix configuration and was looking into
> > making TLS mandatory, as well as verifying the TLS Certificate using
> > DANE w
On Fri, Jan 07, 2022 at 06:17:45PM -0500, PGNet Dev wrote:
> > Absent DANE, this is all security theatre.
>
> yup. which is why i'm doing the step1 cleanups etc to get my own
> mistakes out of the way ... on the way to DNSSEC/DANE.
Be sure to do it right, or not at all. It does nobody a favour
i've clearly not noticed my mistake 'til now, and afaict have seen no
unexplained breakage. dunno if i should've and missed it, or it's
just noisy and ignorable?
Best to not solicit misbehaviour, even if typically nothing bad happens.
sure. not hoping to avoid fixing it! asking if i should'v
On Fri, Jan 07, 2022 at 05:47:55PM -0500, PGNet Dev wrote:
> > Postfix has no CRL or OCSP support, and none is planned.
>
> other than reporting the bad result, does the current (bad) config
> cause any actual mail delivery breakage?
It could, if the sending MTA implements OCSP and honours the e
Session ID resumption is by default disabled. This is a feature, let
the client store a session ticket if it wants, otherwise it does a fresh
handshake. This makes sense for SMTP.
OCSP staplingnot offered
???OCSP must staple extension requires OCSP stapling
On Fri, Jan 07, 2022 at 08:33:52AM -0500, PGNet Dev wrote:
>Session Ticket RFC 5077 hint 7200 seconds, session tickets keys seems
> to be rotated < daily
Keys are rotated as soon as possible, which is 2 * active lifetime.
Initially the key is used to encrypt new tickets, later it is only
Wietse Venema:
> tobs...@brain-force.ch:
> > Yes postmaster as recipient of delivery status notifications. I have
> > set
> >
> > > notify_classes = bounce, 2bounce, delay, policy, protocol, resource,
> > software
> >
> > so postmaster receives delay warnings in general on my system. But it
> > a
tobs...@brain-force.ch:
> Yes postmaster as recipient of delivery status notifications. I have
> set
>
> > notify_classes = bounce, 2bounce, delay, policy, protocol, resource,
> software
>
> so postmaster receives delay warnings in general on my system. But it
> also receives warnings for message
The other ??? item,
"Session Resumption Tickets: yes, ID resumption test failed, pls
report"
I've not found any guidance on at all, yet.
For postfix, do I care?
And if so, what/where is a fix?
did find this comment at SF,
"Certbot — Post-Handshake New Session Ticket a
Yes postmaster as recipient of delivery status notifications. I have
set
> notify_classes = bounce, 2bounce, delay, policy, protocol, resource,
software
so postmaster receives delay warnings in general on my system. But it
also receives warnings for messages where the one and only RCPT TO of
the
tobs...@brain-force.ch:
> Wietse
>
> seems the ugly hack does not work for delay messages to postmaster.
postmaster as the RECIPIENT of copies of delivery status notifications?
By default, postmaster does not receive copies of delivery
notifications. So that is one way to fix this.
If you tur
On 07.01.22 13:28, Viktor Dukhovni wrote:
On Fri, Jan 07, 2022 at 11:34:32AM +0100, Charlotte 🦝 Delenk wrote:
I was trying to harden my postfix configuration and was looking into
making TLS mandatory, as well as verifying the TLS Certificate using
DANE wherever possible.
TLS mandatory for del
raf wrote:
Being flippant, it would protect against a
man-in-the-middle-attack where someone tricks you into
reading false online documentation. :-)
Why bother? Most of us can misread the docs perfectly well all on our
own...
-kgd
i'm prepping postfix tls on the way to DANE implementation
current check with
testssl -t smtp mx.example.com:25
reports,
Testing server defaults (Server Hello)
TLS extensions (standard)"renegotiation info/#65281" "EC point formats/#11"
"session ticket/#35"
Wietse
seems the ugly hack does not work for delay messages to postmaster. Is
it possible it only works for delay messages to sender and not for
postmaster delay notifications? I still got delay warnings in my
postmaster box using the ugly hack.
Anyway changed back to graveyard-mode ;-)
Cheers
On Fri, Jan 07, 2022 at 11:34:32AM +0100, Charlotte 🦝 Delenk wrote:
> I was trying to harden my postfix configuration and was looking into
> making TLS mandatory, as well as verifying the TLS Certificate using
> DANE wherever possible.
TLS mandatory for delivery to the world at large? Or is yo
>
>
> It also prevents some browsers from indicating that a
> site is "insecure", but anyone going directly to
> www.postfix.org will know better than to worry about
> that.
>
Yes, the suggestion was mainly to ease new direct user accesses to
postfix.org, which nowadays don't require the protocol
Hi,
I was trying to harden my postfix configuration and was looking into
making TLS mandatory, as well as verifying the TLS Certificate using
DANE wherever possible.
According to the documentation of smtp_tls_security_level, you can
either set the value to "encrypt" for mandatory tls or "dan
With an ugly hack we could make these a "notify-none" recipient
I always like ugly hacks ;-)
This
/^(RCPT\s+TO:\s
On 07.01.22 08:00, tobs...@brain-force.ch wrote:
in command_filter seems to do the job. Just wonder could a time-unit be
specified instead of NEVER?
no, this is a SMTP command
21 matches
Mail list logo
