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
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 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 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 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 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 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 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 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 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 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 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
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 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
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 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
6.10.24 23:54, Geert Hendrickx via Postfix-users wrote:
> > Just set local_recipient_maps appropriately, without unix:passwd.byname if
> > you
> > don't need it.
> >
> - but mail recipient enumeration is still possible.
Oh, ok. I thought you wanted to avoid
On Tue, Oct 15, 2024 at 16:03:13 +0100, Paul Fowler via Postfix-users wrote:
> Are there best practices for avoid OS username enumeration on a mail relay?
Just set local_recipient_maps appropriately, without unix:passwd.byname if you
don't need it.
I set it to $alias_maps plus an inline:{} list
Hi
> warning: run-time library vs. compile-time header version mismatch:
> OpenSSL 3.4.0 may not be compatible with OpenSSL 3.3.0
Is this warning still relevant with OpenSSL's new versioning scheme,
where OpenSSL 3.x releases are guaranteed[1] to be ABI compatible ?
[1] https://openssl-library.
On Thu, Oct 24, 2024 at 11:33:22 -0400, Wietse Venema via Postfix-users wrote:
> And for the Postfix SMTP server, this would add two guards
> to Viktor's example:
>
> smtpd_tls_security_level =
> ${{$compatibility_level} >=level {3.10} ?
> {${built_with_tls ?
>
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 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 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 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 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
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 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 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 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`
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 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, Oct 24, 2024 at 20:00:05 +1100, Viktor Dukhovni via Postfix-users wrote:
> And this is the logic used in Postfix >= 3.10-20240612, but while you've
> upgraded to a shiny new OpenSSL, you haven't also upgraded to a shiny new
> Postfix snapshot. :-)
This is using standard Arch Linux package
On Thu, Oct 24, 2024 at 16:24:04 +1100, Viktor Dukhovni via Postfix-users wrote:
> Yes, of course, as documented. TLS is off by default, this is backwards-
> compatible behaviour, and Postfix aims to not "surprise" operators with
> unexpected new behaviour after an upgrade.
This could be enabled
On Mon, Jan 06, 2025 at 22:09:27 +0100, Andreas Kuhlen via Postfix-users wrote:
> A text that simply states that the user is unknown would be enough for me. I
> don't want to reveal the fact that I use virtual mailboxes with this bounce
> message.
https://www.postfix.org/postconf.5.html#show_user
On Wed, Feb 05, 2025 at 15:31:44 +0100, Ömer Güven via Postfix-users wrote:
> At least the big companies like GMail never complained about it, the
> Authenticated Received Chain (ARC) always passes without errors, even
> for forwarding. :-)
Yes, the message is still RFC 5322 compliant, as Viktor
On Wed, Feb 05, 2025 at 14:58:48 +0100, Ömer Güven via Postfix-users wrote:
> My solution does completely remove the Received header, so that the
> next-hop adds an appropriate one, usually pointing to the sending MX‘
> ip address.
Which is also not RFC 5321 compliant, just not visibly so :)
>
On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users wrote:
> This reduces the Received: header from:
>
> Received: from
> by servername (Postfix) with id yyy; server-date-stamp
>
> to:
>
> Received: by servername (Postfix) with id yyy; server-date
On Mon, Dec 16, 2024 at 16:32:27 +0100, Matus UHLAR - fantomas via
Postfix-users wrote:
> RH does not usually upgrade major versions of libraries, what's happened?
RHEL 9.4 actually rebased OpenSSL 3.0.7 => 3.2.2.
(which is not unusual in dot releases)
But Postfix was rebuilt as well, at least
On Fri, Jan 24, 2025 at 22:56:40 +0100, Andreas Kuhlen via Postfix-users wrote:
> I have set ‘RejectFailures true’ in /etc/opendmarc.conf. My expectation
> was that mails without a dmarc signature would then be rejected.
Only if the domain publishes a DMARC p=reject policy.
> 2025-01-24T21:52:1
On Wed, Jan 22, 2025 at 13:40:34 +1100, Viktor Dukhovni via Postfix-users wrote:
> Nothing in the Postfix config, but do note that on RedHat / Fedora
> systems there's also "crypto policy" that cranks up security to 11 to
> protect users against fairly exotic threats, so you end up with
> cleartext
On Mon, Jun 09, 2025 at 00:42:20 +1000, Viktor Dukhovni via Postfix-users wrote:
> On Sun, Jun 08, 2025 at 09:29:17AM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > > Can the default be decided at build-time (#ifdef), instead of with
> > > run-time conditional configuration?
> >
> > That
On Sat, Jun 07, 2025 at 18:51:21 -0400, Wietse Venema via Postfix-users wrote:
> > > For the Postfix SMTP client the new default would look like:
> > >
> > > smtp_tls_security_level =
> > > ${{$compatibility_level} >=level {3.10}?
> > > {${built_with_tls ? {may
> > >
>
On Mon, Jun 23, 2025 at 13:24:49 -0400, Wietse Venema via Postfix-users wrote:
> Conclusion: there is no benefit from to changing the SMTP server default
> TLS level.
I agree. The server-side TLS cannot work without some external process
to generate and configure the certificate(s), so it can ju
On Thu, Oct 24, 2024 at 11:33:22 -0400, Wietse Venema via Postfix-users wrote:
> The compatibility-level guard is a good idea. To take out some of the
> guesswork, I'm considering to add a read-only configuration parameter
> that indicates whether Postfix is built with TLS support.
>
> For the Pos
46 matches
Mail list logo
