On Mon, Sep 23, 2024 at 18:32:00 +1000, Viktor Dukhovni via Postfix-users wrote:
> This is not a release-notes-worthy change, just avoids loss of minor forensic
> detail for externally loaded kex "groups" (or, more generally, KEMs).
That's only true for the very last change - but the entire chang
On Fri, Sep 20, 2024 at 20:06:43 +1000, Viktor Dukhovni via Postfix-users wrote:
> If it is possible to test kyber768 with OpenSSL 3.0 or 3.1, please do,
> and post your findings to the list.
Tested with OpenSSL 3.0 as well now (RHEL 9 version), with oqs-provider added.
$ openssl version
OpenSSL
On Fri, Sep 20, 2024 at 00:40:35 +1000, Viktor Dukhovni via Postfix-users wrote:
> So you should be able to apply the top-most commit at:
>
> https://github.com/vdukhovni/postfix/commits/provider-kex/
>
> to a Postfix 3.10-20240917 (or earlier, modulo the expected conflict in
> the HISTORY
On Thu, Sep 19, 2024 at 21:41:44 +1000, Viktor Dukhovni via Postfix-users wrote:
> Can you build Postfix after running "makedefs" with "OPT='-g -ggdb3'",
> and set a break-point in posttls-finger at line ~1054 of tls_misc.c:
>
> 1054 if (tls_get_peer_dh_pubkey(ssl, &dh_pkey)) {
With a PQ
On Thu, Sep 19, 2024 at 17:44:36 +1000, Viktor Dukhovni via Postfix-users wrote:
> Try the below:
Perfect:
> Anonymous TLS connection established from X: TLSv1.3 with cipher
> TLS_AES_128_GCM_SHA256
> (128/128 bits) key-exchange x25519_kyber768 server-signature ECDSA
> (prime256v1)
> server-di
On Thu, Sep 19, 2024 at 19:10:05 +1000, Viktor Dukhovni via Postfix-users wrote:
> On Thu, Sep 19, 2024 at 10:01:16AM +0200, Geert Hendrickx via Postfix-users
> wrote:
>
> > > Anonymous TLS connection established from X: TLSv1.3 with cipher
> > > TLS_AES_128_GCM_SHA2
On Thu, Sep 19, 2024 at 08:26:53 +0200, Geert Hendrickx via Postfix-users wrote:
> I confirm your patch works, I can now use these new key exchanges in Postfix.
Could the reverse lookup be fixed as well, for Received headers and logging?
> Anonymous TLS connection established from X: T
On Thu, Sep 19, 2024 at 12:54:41 +1000, Viktor Dukhovni via Postfix-users wrote:
> Not a problem, the proposed decoration would be part of the element, but
> I'm arguing that it is not needed.
>
> https://github.com/openssl/openssl/issues/21633#issuecomment-2359871975
I agree the need is only on
On Thu, Sep 19, 2024 at 02:02:50 +1000, Viktor Dukhovni via Postfix-users wrote:
> This makes it possible to write "forward-looking" configs that will use
> newer groups once they're available in the OpenSSL runtime.
Well actually, in this case it achieves the opposite, as the individual
checking
On Thu, Sep 19, 2024 at 01:01:42 +1000, Viktor Dukhovni via Postfix-users wrote:
> The OBJ_sn2nid() function is not extensible, and not affected by loading
> of providers. To actually be able to map this algorithm to a "nid", the
> base OpenSSL code would have to know about "x25519_kyber768".
Ok
On Wed, Sep 18, 2024 at 14:02:32 +0200, Geert Hendrickx via Postfix-users wrote:
> On Wed, Sep 18, 2024 at 21:29:07 +1000, Viktor Dukhovni via Postfix-users
> wrote:
> > You should initially test with "posttls-finger",
>
> `posttls-finger -L ssl-debug` shows su
On Wed, Sep 18, 2024 at 21:29:07 +1000, Viktor Dukhovni via Postfix-users wrote:
> On Wed, Sep 18, 2024 at 01:04:58PM +0200, Geert Hendrickx wrote:
>
> > Specifically, this provider implements new Key Encapsulation Methods like
> > "x25519_kyber768", which I can use with `openssl s_server -groups`
Hi Viktor
I was recently playing around with oqs-provider[1] for PQC support in openssl,
but couldn't get it to work with Postfix 3.9.0 for TLSv1.3 key exchange.
Specifically, this provider implements new Key Encapsulation Methods like
"x25519_kyber768", which I can use with `openssl s_server -gr
On Sun, Sep 08, 2024 at 19:39:43 +0200, hostmaster--- via Postfix-users wrote:
> Interesting approach if i correctly understood what you do: You are running
> STARTTLS, basically accepting unencrypted connections but with
> "warn_if_reject reject_plaintext_session" you are rejecting unencrypted
> s
On Mon, Sep 09, 2024 at 00:17:08 +1000, Viktor Dukhovni via Postfix-users wrote:
> And of course, I'd negligent to not mention that I don't recommend a hard
> requirement of TLS on port 25, you may one day reject some important mail
> and not even know it, and if STARTTLS stops working, you may be
On Fri, Jun 21, 2024 at 16:22:24 -0400, Wietse Venema wrote:
> Locally-generated bounces are generated by the Postfix bounce
> daemon which talks to a cleanup service to queue a message.
> One could run bounce daemons with a cleanup_service override
> in master.cf:
Thanks Wietse, that makes sens
Hi
We have few different sets of Postfix mailservers with different roles;
inbound servers, outbound servers that DKIM sign outgoing mail with a
milter, and some other servers that just relay mail that is already signed
elsewhere.
The first and third types of mailservers don't need to sign mail p
On Thu, Mar 07, 2024 at 00:22:31 +0100, Steffen Nurpmeso via Postfix-users
wrote:
> Thanks to the README i got it going with
>
> masquerade_domains = $mydomain
> local_header_rewrite_clients = permit_mynetworks,permit_tls_clientcerts
>
> However, i first tried to add these via -o to the abov
On Tue, Feb 13, 2024 at 12:51:51 -0500, Viktor Dukhovni via Postfix-users wrote:
> On Tue, Feb 13, 2024 at 06:32:14PM +0100, Geert Hendrickx via Postfix-users
> wrote:
> > What's the alternative for masquerade_domains ?
>
> It is canonical_maps, ideally with explicit map
On Tue, Feb 13, 2024 at 12:23:32 -0500, Wietse Venema via Postfix-users wrote:
> - masquerade_domains complicates table-driven address validation.
> Log a deprecation warning with compatibility_levels>=3.9.
What's the alternative for masquerade_domains ?
Geert
On Sat, Jan 06, 2024 at 20:10:34 -0500, Wietse Venema via Postfix-users wrote:
> People are welcome to test tools against postfix-3.9-20240106.
With postfix-3.9-20240106 (with smtpd_forbid_bare_newline=yes but
smtpd_forbid_unauth_pipelining=no) all smuggling tests now fail,
including CRCRL tests.
On Sat, Jan 06, 2024 at 14:47:59 -0500, Wietse Venema via Postfix-users wrote:
> Damian:
> > If I remember correctly, on the wire there was \r\n\r\n.\r\r\n
>
> Viktor Dukhovni:
> > Does that also need to be more strict? :-(
>
> Indeed, and as usual the fix is trivial. This process is backwards,
On Thu, Jan 04, 2024 at 10:36:23 -0500, Wietse Venema via Postfix-users wrote:
> Wietse Venema via Postfix-users:
> > Geert Hendrickx via Postfix-users:
> > > I just found an unexpected side effect of this particular configuration
> > > (unrelated to SMTP smuggling).
&g
On Thu, Dec 21, 2023 at 07:51:31 -0500, Wietse Venema via Postfix-users wrote:
> * With all Postfix versions, "smtpd_data_restrictions =
> reject_unauth_pipelining" will stop the published exploit.
Hi
I just found an unexpected side effect of this particular configuration
(unrelated to SMT
On Sat, Dec 23, 2023 at 18:09:10 -0500, Wietse Venema via Postfix-users wrote:
> Note that only the encapsulating message can contain a DKIM signature
> by the authenticated sender's domain. The smuggled message caannot
> contain a DKIM signature by the impersonated sender's domain unless
> the att
On Mon, Dec 18, 2023 at 17:40:49 -0500, Wietse Venema via Postfix-users wrote:
> Viktor Dukhovni via Postfix-users:
> > - Postfix 3.9 (pending official release soon), rejects unuthorised
> > pipelining by default: "smtpd_forbid_unauth_pipelining = yes".
> >
> > - Postfix 3.8.1, 3.7.6, 3.6.10 and
On Wed, Nov 15, 2023 at 10:29:41 -0500, James Cloos via Postfix-users wrote:
> LE announced a while back that they would not renew the cross cert.
Yes, but dropping the cross-signed X1 root cert from the default chain
last week was an accident:
https://community.letsencrypt.org/t/shortening-the-l
On Tue, Jun 06, 2023 at 10:31:30 -0400, Wietse Venema via Postfix-users wrote:
> Geert Hendrickx via Postfix-users:
> > What is the relation between new "smtpd_forbid_unauth_pipelining"
> > and existing "reject_unauth_pipelining" in smtpd_*_restrictions?
On Tue, Jun 06, 2023 at 09:48:11 -0400, Wietse Venema via Postfix-users wrote:
> * Optional: harden a Postfix SMTP server against remote SMTP
> clients that violate RFC 2920 (or 5321) command pipelining
> constraints. With "smtpd_forbid_unauth_pipelining = yes", the
> server disconnec
29 matches
Mail list logo
