er
> aka DragonWork
>
>>> Am 27.07.2025 um 11:58 schrieb Luca vom Bruch via Postfix-users
>>> :
>>>
>>
>> Hello,
>>
>> I would like to ask for help here as well since I already tried the tlsrpt
>> mailing list.
>>
>>
gt; I have a mail loop problem for TLS reports that are sent everyday even though
> I am no longer sending out E-Mail to that address.
>
> I don’t know if it is a postfix config issue or a problem with tls reporter.
> (I use the rpm from ghettoforge).
>
> My postfix c
https://www.postfix.org/DEBUG_README.html#logging
Postfix logs all failed and successful deliveries to a logfile.
* When Postfix uses syslog logging (the default), the file is
usually called /var/log/maillog, /var/log/mail, or something
similar; the exact pathname is configured in a fil
Hello,
I would like to ask for help here as well since I already tried the tlsrpt
mailing list.
I have a mail loop problem for TLS reports that are sent everyday even though I
am no longer sending out E-Mail to that address.
I don’t know if it is a postfix config issue or a
On Tue, May 06, 2025 at 11:50:55AM -0400, Jason Hirsh via Postfix-users wrote:
[ Just noticed this post from May 06... ]
> # TLS CONFIG
> smtp_tls_note_starttls_offer = yes
> smtpd_tls_key_file = /usr/local/etc/letsencrypt/live/kasdivi.com/privkey.key
> smtpd_tls_cert_file =
>
Andreas, Viktor
Thank you so much for the comments. Sender dependent delivery solved my problem
and now I can apply the right overrides to the right service . Because of
transport precedence, I also had to adjust my transport_maps setting (remove '
* smtp' from the end of the list) so that
se
ent nexthop */
VSTRING *host; /* hostname or empty */
VSTRING *addr; /* printable address or empty */
unsigned port; /* network byte order or null */
+int tlsreqno; /* "TLS-Required: no" */
On Thu, Jun 19, 2025 at 09:24:27AM +, Michael Webb via Postfix-users wrote:
> When relaying TLS report emails generated by sys4 tlsrpt-reporter,
> Postfix built with TLSRPT library seems to ignore master.cf overrides
> and generates warning logs.
The master.cf overrides you've
Am 19.06.25 um 11:24 schrieb Michael Webb via Postfix-users:
In my master.cf I have defined a dedicated listener (port 10032) to receive TLS
reports from the tlsrpt-reporter package so they can be relayed without
generating another TLS report (to avoid a report loop).
I tried to use these
Thank you for the amazing work that has been done to integrate the TLSRPT
feature.
After setting up TLS reporting in one of my systems I noticed some worrying
behavior (Postfix 3.10.2 on EL9).
Was hoping someone could take a look to see if it does need a fix or whether
there is a better way to
On 2025-05-14 at 21:29:59 UTC-0400 (Thu, 15 May 2025 11:29:59 +1000)
Viktor Dukhovni via Postfix-users
is rumored to have said:
On Wed, May 14, 2025 at 11:47:25AM -0400, Sean McBride via
Postfix-users wrote:
On 13 May 2025, at 13:02, Bill Cole via Postfix-users wrote:
The simplest setup is
On 15/5/25 00:20, Jaroslaw Rafa via Postfix-users wrote:
Dnia 14.05.2025 o godz. 20:37:40 Matthew J Black via Postfix-users pisze:
- as you are no doubt aware, I had an "interesting" situation where
my email were being turned into html by a service I am no-longer
using. Hopefully this email (w
On Wed, May 14, 2025 at 11:47:25AM -0400, Sean McBride via Postfix-users wrote:
> On 13 May 2025, at 13:02, Bill Cole via Postfix-users wrote:
>
> > The simplest setup is to have the full chain in a single file
> > referred to by smtpd_tls_cert_file and NO smtpd_tls_chain_file.
There is no such
x27;t have to renew it so often :)
Most mail servers use opportunistic TLS when exchganging mail, and they
don't check who issued the server certificate. And even if they won't be
able to negotiate TLS, most servers will fall back to unencrypted connection
and still deliver the mail.
My serve
certs vs the pain of
>having to deal with and renew self signed certs (if that will even work
>anymore).
>
>With this latest letsencrypt announcement, is this going to hose my Postfix
>TLS? I'm far from proficient at the cert business, grateful that is "just
>wor
s (if that will even work anymore).
With this latest letsencrypt announcement, is this going to hose my Postfix
TLS? I'm far from proficient at the cert business, grateful that is "just
works" now. Worried about how this will affect me.
Announcement email today from outre..
On 14 May 2025, at 12:06, Bill Cole via Postfix-users wrote:
>> OTOH that setup doesn't seem so simple in that (AFAICT) neither certbot nor
>> acme.sh can generate such a combined file.
>
> Really?
>
> $ postconf smtpd_tls_eccert_file
> smtpd_tls_eccert_file = /var/root/.acme.sh/scconsult.com_ecc
On 2025-05-14 at 11:47:25 UTC-0400 (Wed, 14 May 2025 11:47:25 -0400)
Sean McBride via Postfix-users
is rumored to have said:
On 13 May 2025, at 13:02, Bill Cole via Postfix-users wrote:
The simplest setup is to have the full chain in a single file
referred to by smtpd_tls_cert_file and NO smt
On Wed, May 14, 2025 at 05:47:25PM CEST, Sean McBride via Postfix-users
said:
> On 13 May 2025, at 13:02, Bill Cole via Postfix-users wrote:
>
> > The simplest setup is to have the full chain in a single file referred to
> > by smtpd_tls_cert_file and NO smtpd_tls_chain_file.
>
> OTOH that set
On 13 May 2025, at 13:02, Bill Cole via Postfix-users wrote:
> The simplest setup is to have the full chain in a single file referred to by
> smtpd_tls_cert_file and NO smtpd_tls_chain_file.
OTOH that setup doesn't seem so simple in that (AFAICT) neither certbot nor
acme.sh can generate such a
Dnia 14.05.2025 o godz. 20:37:40 Matthew J Black via Postfix-users pisze:
> - as you are no doubt aware, I had an "interesting" situation where
> my email were being turned into html by a service I am no-longer
> using. Hopefully this email (which uses a different system/service)
> will be in plai
p -F` of the sni map file fixed the issue - thank you to those who had the patience to help me resolve both issues.I had no idea that when creating the sni-map.db file the TLS certs were added to the file. Knowing this now, I have updated my ACME.sh systemd service file to include an automat
hostname, while Postfix does not. With posttls-finger it is
possible to specify an SNI name to include in the TLS client hello:
$ posttls-finger -cC -F /etc/ssl/cert.pem -lsecure
"[mail.peregrineit.net]:587" |
openssl x509 -subject -dates -noout
subject=CN=peregrineit.n
On Tue, May 13 2025, 19:28:58 CEST Jaroslaw Rafa wrote via Postfix-users:
> Please, please, don't send HTML-only mail to the list. It's a part of
> longstanding mailing list etiquette that you don't do this. Some of us are
> reading the eamil in plain text.
There is some weird pipelining-chain thr
qp98Q-t6-FZJih8cg9F0Vh0HKCxo4tM9pU52yWTfWfJwaHgNwuUKjdp09wKg";
> style="mso-hide:all"/>Hi All,This is really weird - Our Postfix
> server is presenting old/expired LE TLS Certs, even though we've
> updated the certs AND restarted Postfix (and Dovecot) (and even
Please, pleas
On 13.05.25 23:42, Matthew J Black via Postfix-users wrote:
This is really weird - Our Postfix server is presenting old/expired LE
TLS Certs, even though we've updated the certs AND restarted Postfix
(and Dovecot) (and even rebooted the server) multiple times.
I've done
On 2025-05-13 at 11:36:09 UTC-0400 (Wed, 14 May 2025 01:36:09 +1000)
Matthew J Black via Postfix-users
is rumored to have said:
Cool - that's what I get
But what do you get with 'openssl s_client -starttls smtp -connect
mail.peregrineit.net:587' - cause I get :
depth=0 CN=peregrineit.net
ve
On Tue, May 13, 2025 at 05:07:04PM +0200, Matus UHLAR - fantomas via
Postfix-users wrote:
> any reverse proxy between you and server?
> no multiple postfix instances used?
Let's not encourage further pointless waste of time.
The OP needs to post:
$ postconf -nf
$ postconf -Mf
and some
On Tue, May 13 2025 at 17:19:19 CEST Matthew J Black wrote via Postfix-users:
> so if there are suggesting (...) I'm more than happy to hear them and
> try them.
Please stop sending HTML-only.
--
Thanks
Tom
___
Postfix-users mailing list -- postfi
On Wed, May 14, 2025 at 12:56:34AM +1000, Matthew J Black via Postfix-users
wrote:
> > There's no magic, Postfix loads certificates and keys from the
> > configured locations.
> >
> > https://www.postfix.org/DEBUG_README.html#mail
>
> Yeah, I realise that - that's why it's so weird! :-)
> (Which
Cool - that's what I get
But what do you get with 'openssl s_client -starttls smtp -connect
mail.peregrineit.net:587' - cause I get :
depth=0 CN=peregrineit.net
verify error:num=10:certificate has expired
notAfter=Apr 10 07:36:42 2025 GMT
I'll post in a few hours
On 14/5/25 01:20, Viktor Duk
On 14/5/25 00:08, Matus UHLAR - fantomas via Postfix-users wrote:>> are you sure the proper smtpd_tls_cert_file and smtpd_tls_key_file are > configured in postfix configuration?>Triple-checked it :-)And as I said, I can't find the old certs on the box anywhere, so even if they were incorrectly set
ffed things up somewhere, but I'll be a>> disney proncess if I can work out where!)>> any reverse proxy between you and server?> no multiple postfix instances used?>Nope, no reverse proxy - well, yes there is, for some of the (externally facing) domains, but the problem also
On 14/5/25 01:12, Viktor Dukhovni via Postfix-users wrote:> On Wed, May 14, 2025 at 12:56:34AM +1000, Matthew J Black via Postfix-users wrote: There's no magic, Postfix loads certificates and keys from the>>> configured locations.>> https://www.postfix.org/DEBUG_README.html#mail>> Yeah, I r
>> On 14/5/25 00:08, Matus UHLAR - fantomas via Postfix-users wrote:
>> >
>> > are you sure the proper smtpd_tls_cert_file and smtpd_tls_key_file
>> > are
>> > configured in postfix configuration?
> On Wed, May 14, 2025 at 12:17:29AM +1000, Matthew J Black via
Postfix-users wrote:
On 14/5/25 00:48, Viktor Dukhovni via Postfix-users wrote:> On Wed, May 14, 2025 at 12:17:29AM +1000, Matthew J Black via Postfix-users wrote:>>> [q2AY6ESDEdxdcaKPIjGrwB1r7irZNrS9NMjjOyd3RyDvDnZMS2-sTQhrVffoXSQ5YfoHS>> mIcYF9Dtgcyg6uqQNRONtN6fjtE7FhanYwbNm07AoA0WypPtbent8SCQHFw3oKlNwb8geri
On Wed, May 14, 2025 at 12:17:29AM +1000, Matthew J Black via Postfix-users
wrote:
> [q2AY6ESDEdxdcaKPIjGrwB1r7irZNrS9NMjjOyd3RyDvDnZMS2-sTQhrVffoXSQ5YfoHS
>mIcYF9Dtgcyg6uqQNRONtN6fjtE7FhanYwbNm07AoA0WypPtbent8SCQHFw3oKlNwb8geri
>jbVIdLhnAzelVvNmW4ujeNXfWCDKM6iFsokflWxvpn_FvMEODKjqJj2
Hi All,This is really weird - Our Postfix server is presenting old/expired LE TLS Certs, even though we've updated the certs AND restarted Postfix (and Dovecot) (and even rebooted the server) multiple times.I've done a thorough search of the box for the old certs and can find nothing.I
> Begin forwarded message:
>
> From: Jason Hirsh
> Subject: Re: [pfx] Postfix TLS Library Problem No such file
> Date: May 6, 2025 at 2:27:43 PM EDT
> To: postfix-u...@postfix.org
> Cc: Bill Cole
>
>
>> On May 6, 2025, at 12:43 PM, Bill Cole via Postfix-us
uating mail servers.
You can test a TLS/SSL server of any sort using the OpenSSL 's_client'
function or the free 'sslscan' utility
(https://github.com/rbsec/sslscan.)
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmai
Dnia 6.05.2025 o godz. 11:50:55 Jason Hirsh via Postfix-users pisze:
>
> May 5 10:01:31 triggerfish postfix/smtpd[94025]: warning: TLS library
> problem: error:8002:system library::No such file or
> directory:/usr/src/crypto/openssl/crypto/bio/bss_file.c:297:calling
> fopen
, reject_non_fqdn_sender, check_client_access
hash:/usr/local/etc/postfix/rbl_override, reject_non_fqdn_recipient,
reject_unauth_destination, reject_unauth_pipelining,
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
# TLS CONFIG
r the next release (I'm really looking forward to a stable
>> v3.10, so it's great news that you have frozen the code )
>>
>> but as an idea for the future releases?
>
> I just opened a discussion with Viktor about working towards a
> future where SMTP over authen
wards a
future where SMTP over authenticated TLS is the norm.
- Enforce DANE if available (allowing for hybrid case)
- Else enforce STS if available
- Else enforce { secure, match=nexthop,dot-nexthop }
Custom policies will be needed for sites that are an exception from
the norm (including the cas
:53 schrieb Wietse Venema via Postfix-users
> :
>
> ?mer G?ven via Postfix-users:
>> Hi!
>>
>> For the next release (3.10), I'd like to propose that unknown tags
>> returned by TLS policy socketmap servers are logged as warnings,
>> but never regarded a
?mer G?ven via Postfix-users:
> Hi!
>
> For the next release (3.10), I'd like to propose that unknown tags
> returned by TLS policy socketmap servers are logged as warnings,
> but never regarded as an invalid policy. This would avoid delivery
> errors introduced by fu
Hi!
For the next release (3.10), I‘d like to propose that unknown tags returned by
TLS policy socketmap servers are logged as warnings, but never regarded as an
invalid policy.
This would avoid delivery errors introduced by future additions, when an older
Postfix version doesn‘t support a tag
eats, so you end up with
> cleartext instead of reasonably, but not maximally secure TLS.
On RHEL 9 servers (which matches OP's postfix 3.5.25 and openssl 3.2.2)
you generally want to use `update-crypto-policies --set DEFAULT:SHA1`
for mailservers, to improve interoperability.
(for services o
On Tue, Jan 21, 2025 at 05:16:29PM -0500, Wietse Venema via Postfix-users wrote:
> >[root@host /]# postconf -n | grep tls
> >milter_rcpt_macros = i {rcpt_addr} {rcpt_host} {rcpt_mailer}
> > {tls_version}
> >smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.cr
postfix--- via Postfix-users:
> > You may want to comment out protocol or cipher tweaks' these can
> > reduce interoperability:
> >
> > postconf -n | grep tls
>
>
> I do not think I am using any tweaks and try to keep things as default as
>
You may want to comment out protocol or cipher tweaks' these can
reduce interoperability:
postconf -n | grep tls
I do not think I am using any tweaks and try to keep things as default as
possible. Or maybe I'm misunderstanding.
[root@host /]# postconf -n | grep tls
milter_r
ept error from
> sub.example.com[xxx.xxx.xxx.xxx]: -1
>Jan 21 09:15:22 host postfix/smtpd[79286]: warning: TLS library problem:
> error:0AC1:SSL routines::no shared cipher:ssl/statem/statem_srvr.c:2327:
>Jan 21 09:15:22 host postfix/smtpd[79286]: lost connection after STARTTLS
> from
]: warning: TLS library problem:
error:0AC1:SSL routines::no shared cipher:ssl/statem/statem_srvr.c:2327:
Jan 21 09:15:22 host postfix/smtpd[79286]: lost connection after STARTTLS
from sub.example.com[xxx.xxx.xxx.xxx]
Jan 21 09:15:22 host postfix/smtpd[79286]: disconnect from
sub.example.com
Postfix does not cache DSNS lookup results. It relies on the
resolver configured in /etc/resolv.conf.
Postscreen honors the 'negative' TTL when it allowlists a client
that passes DNSBL checks, but it does not store the query result
itself.
Wietse
__
||> TCP layer with blocking calls on DNS. If we see DNS also moving
||
||Postfix blocks on DNS. The SMTP reads and writes are also blocking.
||The TLS reads and writes are non-blocking if implemented in tlsproxy,
||and blocking if implemented in the SMTP client itself.
|
|Only to note t
on DNS. The SMTP reads and writes are also blocking.
|The TLS reads and writes are non-blocking if implemented in tlsproxy,
|and blocking if implemented in the SMTP client itself.
Only to note that RRs can be and usually are cached. (I use
dnsmasq for almost a quarter of a century, but toda
Joachim Lindenberg:
> Given the fact that "encrypt" implies no "dane" this sounds like
> a bad idea for interoperability with dane sites.
Wietse:
> No problem. Postfix currently does not try DANE (or STS) with the
> default TLS security level "may".
Jo
Wietse wrote:
>> Given the fact that "encrypt" implies no "dane" this sounds like a bad idea
>> for interoperability with dane sites.
> No problem. Postfix currently does not try DANE (or STS) with the default TLS
> security level "may".
Joachim Lindenberg via Postfix-users:
> Wietse wrote:
> > When an SRV response for "_smtps._tcp.example.com" names the standard SMTP
> > port, the feature overrides a default TLS security level "may" with
> > "encrypt". This is on/off configur
Wietse wrote:
> When an SRV response for "_smtps._tcp.example.com" names the standard SMTP
> port, the feature overrides a default TLS security level "may" with
> "encrypt". This is on/off configurable and needs a few lines of code in the
> SMTP clie
automatically turn on TLS
|wrappermode for a configurable list of service names. This is nice
|to have and relatively easy to implement. It takes a few lines
|to create a matchlist duriong process startup, and another few lines
|to query it.
|
|- When an SRV response for "_smtps._
Ralph Seichter via Postfix-users wrote in
:
|* Steffen Nurpmeso via Postfix-users:
|
|> I did not want to initiate a discussion, actually.
|
|And who would have guessed? Just push a feature which does not serve a
|real purpose. Discussions are *so* last year.
That not; I would not say so, n
I scanned the draft version 3. On the Postfix side this appears
to involve:
- For "_smtps._tcp.example.com" SRV responses that don't name the
standard SMTP port, it may be helpful to automatically turn on TLS
wrappermode for a configurable list of service names. This is n
uce
|unless there are pre-relase checks in place that catch this.
|
|DANE and MTA-STS are ways to discover that a domain or MX host
|supports SMTP over TLS. Neither protects against vulnerabilities
|like CVE-2011-0411. DANE requires DNSSEC, and can protect against
|"downgrade to plain
re-introduce
unless there are pre-relase checks in place that catch this.
DANE and MTA-STS are ways to discover that a domain or MX host
supports SMTP over TLS. Neither protects against vulnerabilities
like CVE-2011-0411. DANE requires DNSSEC, and can protect against
"downgrade to plai
* Steffen Nurpmeso via Postfix-users:
> I did not want to initiate a discussion, actually.
And who would have guessed? Just push a feature which does not serve a
real purpose. Discussions are *so* last year.
> It was indeed quite the other way around, as you know very well [...]
That was a lot
eless roundtrips and packets -- and even
more, in fact, as Jeremy had written that with Implicit TLS it is
possible to attach initial SMTP data to the TLS handshake packet
(and ditto at the tail), so the saving can be even more, then
i happily jump on this train *immediately*. Of course. Thank you.
oposals that repurpose some
|"invalid bit pattern" case to signal that a domain supports:
|
|- a feature that is not part of the protocol (smtps) that is mentioned
| in the request,
|
|- on a port (25) that is not mentioned in the request or response.
Ok i change it so default IANA p
On 31/12/2024 09:35, Ralph Seichter via Postfix-users wrote:
* Steffen Nurpmeso via Postfix-users:
There is nothing to link. postfix already supports SRV. [...]
Seriously? You refer to a draft, then don't bother to link to it, or
mention that you are the author, with an agenda to boot? What
* Steffen Nurpmeso via Postfix-users:
> There is nothing to link. postfix already supports SRV. [...]
Seriously? You refer to a draft, then don't bother to link to it, or
mention that you are the author, with an agenda to boot? What a strange
way to try to initiate a discussion. One might suspect
eople know explicitly who is
|trying to promote a subject, and why. Also, that draft is the basis of
|any discussion, so why not link to it?
There is nothing to link. postfix already supports SRV. If there
is one with port 0, STARTTLS is to be used, if there is one with
not 0 then Implicit TLS on th
oposals that repurpose some
|"invalid bit pattern" case to signal that a domain supports:
|
|- a feature that is not part of the protocol (smtps) that is mentioned
| in the request,
|
|- on a port (25) that is not mentioned in the request or response.
The draft says it differently,
* Steffen Nurpmeso via Postfix-users:
> >Are you referring to [1], i.e. your own draft? "Nenne Ross und
> >Reiter."
>
> Well i think that became obvious from the rest of the message.
I think it is just good manners to let people know explicitly who is
trying to promote a subject, and why. Also, t
Steffen Nurpmeso via Postfix-users:
> Btw why do you say "odd"? SRV has the possibility for port 0 ever
> since it was created, yet port 0 never was a valid port. So to
> the contrary even (hah!) we finally live it in full, what was only
> envisioned in the past. If that isn't progress, i do not
Viktor Dukhovni via Postfix-users wrote in
:
|On Sun, Dec 29, 2024 at 06:45:22AM +0100, Ralph Seichter via Postfix-users \
|wrote:
|> * Steffen Nurpmeso via Postfix-users:
|>
|>> there is this IETF draft which asks for support SMTPS (aka really,
|>> now), that is Implicit
y,
|>> now), that is Implicit TLS via dedicated port for SMTP.
|>
|> [1] https://datatracker.ietf.org/doc/draft-nurpmeso-smtp-tls-srv/02/
|
|I've problems with that
|
|1. usually, IETF drafts are discussed on IETF mailing lists.
|I didn't found any such
Ralph Seichter via Postfix-users wrote in
:
|* Steffen Nurpmeso via Postfix-users:
|
|> there is this IETF draft which asks for support SMTPS (aka really,
|> now), that is Implicit TLS via dedicated port for SMTP.
|
|Are you referring to [1], i.e. your own draft? "Nenne Ross
Am 29.12.24 um 06:45 schrieb Ralph Seichter via Postfix-users:
* Steffen Nurpmeso via Postfix-users:
there is this IETF draft which asks for support SMTPS (aka really,
now), that is Implicit TLS via dedicated port for SMTP.
[1] https://datatracker.ietf.org/doc/draft-nurpmeso-smtp-tls-srv
* Steffen Nurpmeso via Postfix-users:
> there is this IETF draft which asks for support SMTPS (aka really,
> now), that is Implicit TLS via dedicated port for SMTP.
Are you referring to [1], i.e. your own draft? "Nenne Ross und Reiter."
[1] https://datatracker.ietf.org/doc/dra
Hello dear Wietse Venema, Viktor Dukhovni, all,
there is this IETF draft which asks for support SMTPS (aka really,
now), that is Implicit TLS via dedicated port for SMTP.
It is not offending Viktor's DANE for SMTP (which i for example
cannot use at all without starting to run my own names
On Tue, Dec 17, 2024 at 08:43:48AM +0100, Ansgar Wiechers via Postfix-users
wrote:
> On 2024-12-17 Tobi via Postfix-users wrote:
> > I'm looking for a way to achieve the following: if postfix smtp client
> > cannot establish a TLS connection to MX host then we want to chan
On 2024-12-17 Tobi via Postfix-users wrote:
> I'm looking for a way to achieve the following: if postfix smtp client
> cannot establish a TLS connection to MX host then we want to change
> nexthop **and** add a suffix to the subject. The goal is to route back
> the mail to the ha
Hi there
I guess the answer will be "not possible" but maybe (hopefully) I'm
wrong :-) I'm looking for a way to achieve the following: if postfix
smtp client cannot establish a TLS connection to MX host then we want
to change nexthop **and** add a suffix to the subject. The g
2024 at 03:29:54PM +0100, Matus UHLAR - fantomas via
Postfix-users wrote:
works with tls1.3, doesn't work otherwise:
On 26.11.24 02:24, Viktor Dukhovni via Postfix-users wrote:
Of course, because TLS 1.3 ignores "-ciphers", it does algorithm
negotiation very differently.
A
as a post-mortem :-)
rcpt changed the mta-sts policy file but did not update the DNS TXT
record (especially the id value). So it's fully according to policy
discovery behaviour specified in RFC 8461
(https://datatracker.ietf.org/doc/html/rfc8461#section-3) that a mta-
resolver should not check for
On Mon, Dec 09, 2024 at 04:29:54PM +0100, Tobi via Postfix-users wrote:
> Finally found it :-) RCPT domain changed not long ago from Gmail to
> Microsoft and uses mta-sts. Out mta-sts resolver still had the policy
> for gmail, therfore the delivery to Microsoft could not be verified. We
> just del
>> Server certificate not verified
> all over the postfix logs. Manually testing shows the same
nope, not here
randy, also debian 12 and postfix 3.7.11
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-u
noise in the logs?
> >
> > not just noise. It prevents our delivery and finally we bounce back
> > to
> > sender with "expired"
>
> SMTP defaults to unauthenticated TLS. What settings, if any, on your
> end cause you Postfix to care about the presented certific
>
> > not just noise. It prevents our delivery and finally we bounce back
> > to
> > sender with "expired"
>
> SMTP defaults to unauthenticated TLS. What settings, if any, on your
> end cause you Postfix to care about the presented certificate
> (cha
On Mon, Dec 09, 2024 at 12:03:02PM +0100, Tobi via Postfix-users wrote:
> > Is that preventing mail delivery, or just noise in the logs?
>
> not just noise. It prevents our delivery and finally we bounce back to
> sender with "expired"
SMTP defaults to unauthenticated TL
Victor,
On Mon, 2024-12-09 at 19:46 +1100, Viktor Dukhovni via Postfix-users
wrote:
> On Mon, Dec 09, 2024 at 08:28:55AM +0100, Tobi via Postfix-users
> wrote:
>
> > since this weekend we have the issue that our postfix seems to be
> > unable to verify TLS certs presented
On Mon, Dec 09, 2024 at 08:28:55AM +0100, Tobi via Postfix-users wrote:
> since this weekend we have the issue that our postfix seems to be
> unable to verify TLS certs presented by Microsoft. We get
>
> > Server certificate not verified
Is that preventing mail delivery, or ju
the system is a Debian 12 with latest updates. Did Microsoft mess it or
do we mess it?
Anyone else experiencing such issues with MS atm?
I have nothing like that in my logs, but I'm pretty low volume
//Danjel
___
Postfix-users mailing list -- po
Hello list
since this weekend we have the issue that our postfix seems to be
unable to verify TLS certs presented by Microsoft. We get
> Server certificate not verified
all over the postfix logs. Manually testing shows the same
> openssl verify -verbose <(echo | openssl s_client
7;
> >
> > Seems like determining whether the ciphers could interoperate is the
> > first step.
>
> works with tls1.3, doesn't work otherwise:
Of course, because TLS 1.3 ignores "-ciphers", it does algorithm
negotiation very differently.
> 00A77BF7:error:0
y sent the alert.
sorry, forgot to say it was server reply to TLS helo.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I wonder ho
On Mon, Nov 25, 2024 at 11:52:07AM +0100, Matus UHLAR - fantomas via
Postfix-users wrote:
> This is Debian 12, postfix 3.7.11 and SSL 3.0.15.
Does Debian do anything similar to RedHat's crypto policy?
> > Note that these ciphers don't enable "forward-secrecy", they use RSA key
> > exchange:
> >
On 2024-11-22 at 13:24:33 UTC-0500 (Fri, 22 Nov 2024 19:24:33 +0100)
Matus UHLAR - fantomas via Postfix-users
is rumored to have said:
Now I'm searching for the proper smtpd_tls_exclude_ciphers setting
to get at least some, possibly most secure ciphers of those provided
in my first mail.
smt
On Fri, Nov 22, 2024 at 01:09:06PM +0100, Matus UHLAR - fantomas via
Postfix-users wrote:
> Our customer has an old scanner/printer seems to support TLS1.2, but only a
> few weak ciphers that are forbidden in out postfix configuration, according
> to old discussion in this list:
T
On 2024-11-22 at 13:24:33 UTC-0500 (Fri, 22 Nov 2024 19:24:33 +0100)
Matus UHLAR - fantomas via Postfix-users
is rumored to have said:
[...]
Thanks.
Now I'm searching for the proper smtpd_tls_exclude_ciphers setting to
get at least some, possibly most secure ciphers of those provided in
my fi
1 - 100 of 1990 matches
Mail list logo
