I have an smtp server that I use as smtp relay for some internal mail
server and as smtp authenticate for some users.
I have the enabled sender IPs in network_table
I have the enabled users as system users in passwd/shadow
Inserting my local domains (hosted in another internal server), in
On Mon, Jan 22, 2024 at 02:57:16PM -0500, Bill Cole via Postfix-users wrote:
> The reason implicit TLS isn't useful for SMTP (MTA-MTA) use is that port 25
> must always be backwards-compatible and so MUST start with a plaintext
> server greeting, NOT a TLS handshake. Establishing a new secure
On 2024-01-22 at 14:16:31 UTC-0500 (Mon, 22 Jan 2024 16:16:31 -0300)
Taco de Wolff via Postfix-users
is rumored to have said:
Regarding MTA-MTA connections, it seems I didn't fully understand it.
I was
surprised that port 25 (unencrypted) was used for all mail traffic,
but
surely (and
On 2024-01-22 at 12:42:08 UTC-0500 (Mon, 22 Jan 2024 12:42:08 -0500)
Viktor Dukhovni via Postfix-users
is rumored to have said:
On Mon, Jan 22, 2024 at 11:44:40AM -0300, Taco de Wolff via
Postfix-users wrote:
[...]
Has this something to do with FIPS mode? I don't think so because the
ciphers
Thanks Viktor for the reply. I think you were correct that mail was blocked
only on port IPv4, and it had nothing to do with DANE.
I've removed the TLSv1.3 ciphers from the list and TLSv1.3 keeps working.
Unfortunately, the >=TLSv1.2 syntax is not supported for my version of
Postfix (v3.5.8) and
On Mon, Jan 22, 2024 at 11:44:40AM -0300, Taco de Wolff via Postfix-users wrote:
> Two questions really, one is that I can't enable TLS1.3 whatever I try.
> Running CentOS8 with OpenSSL v1.1.1k-FIPS and Postfix v3.5.8, I confirm
> that TLS1.3 ciphers are available:
Protocol version negotiation
On 22.01.24 12:34, Taco de Wolff via Postfix-users wrote:
Sorry, this was a problem with the system-wide cryptographic policies. I
set it to DEFAULT and it works. This is unexpected though, since at least
two TLS1.3 ciphersuites are enabled with FIPS:OSPP and TLS1.3 works with
Nginx (Dovecot is
Matthias Schneider via Postfix-users:
> Thanks for getting back to me quickly.
>
> While I understand your concerns about logging reliability, it's
> important to highlight that, for some users, the log serves as the
> sole source of truth to confirm whether an email was relayed or
> rejected in
Sorry, this was a problem with the system-wide cryptographic policies. I
set it to DEFAULT and it works. This is unexpected though, since at least
two TLS1.3 ciphersuites are enabled with FIPS:OSPP and TLS1.3 works with
Nginx (Dovecot is similar to Postfix though and both are fixed with this
Thanks for getting back to me quickly.
While I understand your concerns about logging reliability, it's important to
highlight that, for some users, the log serves as the sole source of truth to
confirm whether an email was relayed or rejected in the SMTP process.
The challenge we face is the
Thanks Matthias, great point. I was sure that should've fixed the problem
as it should indeed be SHA256. For some weird reason I still can't connect
with TLS1.3 though. Some additional information while trying to connect
from localhost with smtpd_log_level=2:
# cat /var/log/maillog
Jan 22
Sorry, Postfix logging must not be used as if it is a reliable
channel for message processing. Postfx goes through great effort
to guarantee that message loss won't happen unless a file system
is damaged or unless a message is forcibly deleted from the queue.
There are no such guarantees for
Hi,
i think this has something todo with smtpd_tls_fingerprint_digest:
smtpd_tls_fingerprint_digest = ${{$compatibility_level}
An: "postfix-users"
Gesendet: Montag, 22. Januar 2024 15:44:40
Betreff: [pfx] Enabling TLS1.3 and allow sending over SMTPS/465
Hi,
Two questions really, one
Hi,
Two questions really, one is that I can't enable TLS1.3 whatever I try.
Running CentOS8 with OpenSSL v1.1.1k-FIPS and Postfix v3.5.8, I confirm
that TLS1.3 ciphers are available:
# openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021
# postconf -T compile-version
OpenSSL 1.1.1k FIPS 25 Mar
[An on-line version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.8.5.html]
[Fixes for Postfix versions < 3.5 will be announced at
https://www.postfix.org/smtp-smuggling.html]
Postfix stable release 3.8.5, 3.7.10, 3.6.14, 3.5.24
Security: this release
Dear Postfix Developers,
I hope this message finds you well. I'm reaching out to address a concern
related to the limit for the header key/value string in the "info", "warn" and
"reject" header_check log message during the cleanup process.
The current 200-character limit, introduced in 2002
16 matches
Mail list logo
