Re: postfix 2.6.6 "stuck queue"
On Wed, Aug 14, 2019 at 12:44:30PM -0700, Sean Hogberg wrote:
[ The OP should consider using a paragraph break now and then. ]
> Anyway, I'm seeing mail sit in the active queue (picked up by qmgr, but
> not sent to smtp) for 20-40 mins.
Perhaps your MTA is accepting mail to invalid recipients, only to
bounce it after a failed inbound delivery. If the sender address
is also bogus, the bounces may tempfail, and clog the queue.
The solution is to configure the MTA to reject invalid (and, if
applicable, over-quota) recipient addresses, thereby eliminating
the source of the congestion. You should probably also raise the
smtp transport ("unix" not "inet") process limit in master.cf, and
perhaps also the default_process_limit.
> Then it seems like the qmgr process
> restarts and processes all mail in the active queue, then handles the queue
> as you'd expect for 20-40 mins.
What do you mean by "restarts"? If some cron job is actually
restarting the queue manager ("postfix reload") that's rather
conterproductive, and you should get rid of that cron job.
Similarly, any periodic "postfix flush" is a bad idea.
What can help a bit is raising the ratio of the minimal_backoff_time
and maximal_backoff_time:
miminal_backoff_time = 225s
maximal_backoff_time = 14400s
This retries fresh mail more quickly, but then retries messages
that failed multiple times less often. Overall, the amount
of time mail that ultimately bounces will spend less time
clogging the queue.
> Logs\conf:
> https://pastebin.com/qEweh4ph
Static connection caching is probably unwise:
smtp_connection_cache_destinations = static:all
The bounce_queue_lifetime = 2h hints at excessive bounce rates,
address the root cause, not the symptoms. For legitimate mail,
bounces should be retried substantially longer than that.
This MTA appears to only process outbound mail, mydestination is
empty and there are no relay or virtual domains. Any mail to
problem destinations is therefore originating with the trusted
clients (mynetworks). If they're doing poor recipient validation,
address that. This MTA looks like a bulk mail engine, perhaps
for clients with "dirty" lists. If so, "good luck" with that...
If your syslog-daemon is doing synchronous writes to the log file,
then performance can be impacted by silly logging such as:
postfix-mainqueue/smtp[25032]: CD992CCAB3099: warning: header X-...
do you really need those? And of course, if applicable, turn off
synchronous syslog writes:
http://www.postfix.org/BASIC_CONFIGURATION_README.html#syslog_howto
--
Viktor.
Re: Wirthy of a warning?
@lbutlr: > Are logs like the following really worthy of a warning log level? Yes, because they can result in an irreversible action: if Postfix replies with 5XX then the client will not retry the delivery attempt. If you don't like these, "man grep". Wietse > postfix/submit/smtpd[84385]: warning: hostname = > zg-0301e-69.stretchoid.com does not resolve to address 107.170.200.25: = > hostname nor servname provided, or not known > postfix/smtps/smtpd[96068]: warning: hostname = > 189-91-4-216.dvl-wr.mastercabo.com.br does not resolve to address = > 189.91.4.216: hostname nor servname provided, or not known > > Looking for actual problems I have to sift through thousands of these = > (well, I simply grep -v resolve, but still=E2=80=A6 > > > > --=20 > I WILL NOT PLEDGE ALLEGIANCE TO BART Bart chalkboard Ep. 7F09 > > Current Song: Pigs On The Wing (Part 1) by Pink Floyd from Animals = > (1:25) > >
Wirthy of a warning?
Are logs like the following really worthy of a warning log level? postfix/submit/smtpd[84385]: warning: hostname zg-0301e-69.stretchoid.com does not resolve to address 107.170.200.25: hostname nor servname provided, or not known postfix/smtps/smtpd[96068]: warning: hostname 189-91-4-216.dvl-wr.mastercabo.com.br does not resolve to address 189.91.4.216: hostname nor servname provided, or not known Looking for actual problems I have to sift through thousands of these (well, I simply grep -v resolve, but still… -- I WILL NOT PLEDGE ALLEGIANCE TO BART Bart chalkboard Ep. 7F09 Current Song: Pigs On The Wing (Part 1) by Pink Floyd from Animals (1:25)
Re: postfix 2.6.6 "stuck queue"
According to pastebin, every minute some email is delivered. That mail is not stuck in the queue. To support your claim that mail is stuck in the queue, show evidence in the form of 'status=deferred' statistics. Or better, run the qshape tool, which is bundled with Postfix source code. Wietse
Re: Sender IP reverse lookup rejected
Kadlecsik József wrote: Hello, One of our users reported a rejected email with the error code and message Remote-MTA: dns; artemis.gat.com Diagnostic-Code: smtp; 550 Sender IP reverse lookup rejected We handle several domains with different outgoing smtp settings at multiple mail gateways: # /etc/postfix/master.cf wignersmtp unix - - y - - smtp -o smtp_bind_address=148.6.0.56 -o smtp_bind_address6=2001:738:5001::56 Slightly wild guess: Something about the reverse DNS entries bothers the receiving site. (Whether it's a reasonable complaint is something else entirely, and rejecting mail to postmaster@ is not very bright all on its own.) kdeugau@pod:~$ host 148.6.0.56 56.0.6.148.in-addr.arpa domain name pointer smtp.wigner.mta.hu. kdeugau@pod:~$ host smtp.wigner.mta.hu. smtp.wigner.mta.hu has address 148.6.0.58 smtp.wigner.mta.hu has address 148.6.0.56 smtp.wigner.mta.hu has address 148.6.0.57 smtp.wigner.mta.hu has IPv6 address 2001:738:5001::56 smtp.wigner.mta.hu has IPv6 address 2001:738:5001::57 smtp.wigner.mta.hu has IPv6 address 2001:738:5001::58 I would recommend giving each of those IPs a unique PTR name, and setting up matching A or records. I'm guessing they're erroring on either the multiple IPs in the forward lookup, or the mismatch between PTR and at least one forward entry. They may still fail if you have eg: 56.0.6.148.in-addr.arpa domain name pointer smtp1.wigner.mta.hu. smtp1.wigner.mta.hu has address 148.6.0.56 smtp1.wigner.mta.hu has IPv6 address 2001:738:5001::56 -kgd
postfix 2.6.6 "stuck queue"
Hey guys, I just took over some postfix gateways (my primary MTA is exim, so getting used to a few differences), and ran into an issue that I'm not quite sure how to solve. Unfortunately using an old postfix version (2.6.6), I do want to get that upgraded and up to date but wont be able to do that in the near future due to other business priorities at the moment. Anyway, I'm seeing mail sit in the active queue (picked up by qmgr, but not sent to smtp) for 20-40 mins. Then it seems like the qmgr process restarts and processes all mail in the active queue, then handles the queue as you'd expect for 20-40 mins. When the qmgr process restarts again, it just seems to refuse to connect to smtp, and the queue builds back up and sits basically unprocessed for another 20-40 mins, rinse and repeat (can see the sent message count per minute at the end of that pastebin). When stracing the qmgr process, when its working I see a number of connects to the smtp daemon as you'd expect, but when the process respawns and nothing is processing, I'm not even really seeing connection attempts to postfix/smtp (though I do see it receiving mail from postfix/smtpd into the queue). I have separate transports for google\yahoo\microsoft (as show up in the pastebin), they don't seem to have the same issue (though their volume is quite small as we have a separate set of outbounds that handle most those large provider mail). The active queue gets up to around 5-7k, the deferred queue tops out around 1k -- so I wouldnt think things are saturated, especially as the process limit for smtp isn't reached (when mail isnt being delivered at all). Any pointers here? when mail is being actually processed, the active queue shrinks to 2 digits and stays there til the qmgr process restarts and we start to see no delivery attempts. Logs\conf: https://pastebin.com/qEweh4ph
Re: Domain cannot be found?
On Aug 14, 2019, at 10:12, Matus UHLAR - fantomas wrote: > > or get the bank to fix it. One rarely needs multiple PTR records. That would be ideal, but in 37 years of dealin with banks, fixing their stupidity is not something they do. Sent from my iPhone
Re: Domain cannot be found?
On 8/14/2019 10:30 AM, @lbutlr wrote: Aug 14 09:25:41 mail postfix/smtpd[44179]: NOQUEUE: reject: RCPT from unknown[198.241.168.120]: 550 5.7.25 Client host rejected: cannot find your hostname, [198.241.168.120]; from=<*munged*@*mybak*> to= proto=ESMTP helo= root@mail # dig cportal3.visa.com +short [9:27] [/var/log] 198.241.168.120 The help doesn’t match the from, but it is valid. And yes, this is a BANK, sigh. smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre permit On 14.08.19 10:54, Noel Jones wrote: This looks like a reject on the client due to failed FCrDNS, not the HELO. There's two PTRs for that IP, but only one PTR has FCrDNS. Postfix will check the first PTR returned, so it's basically random if they'll get rejected. If you use reject_unknown_client_hostname be prepared to maintain a whitelist. or get the bank to fix it. One rarely needs multiple PTR records. -- 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. 42.7 percent of all statistics are made up on the spot.
Re: Domain cannot be found?
On 8/14/2019 10:30 AM, @lbutlr wrote: Aug 14 09:25:41 mail postfix/smtpd[44179]: NOQUEUE: reject: RCPT from unknown[198.241.168.120]: 550 5.7.25 Client host rejected: cannot find your hostname, [198.241.168.120]; from=<*munged*@*mybak*> to= proto=ESMTP helo= root@mail # dig cportal3.visa.com +short [9:27] [/var/log] 198.241.168.120 The help doesn’t match the from, but it is valid. And yes, this is a BANK, sigh. smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre permit This looks like a reject on the client due to failed FCrDNS, not the HELO. There's two PTRs for that IP, but only one PTR has FCrDNS. Postfix will check the first PTR returned, so it's basically random if they'll get rejected. If you use reject_unknown_client_hostname be prepared to maintain a whitelist. -- Noel Jones
Re: Domain cannot be found?
Possibly multiple PTR records causing issue? dig -x 198.241.168.120 +short mail1.payablesautomation.net. cportal3.visa.com. On Wed, Aug 14, 2019 at 11:32 AM @lbutlr wrote: > Aug 14 09:25:41 mail postfix/smtpd[44179]: NOQUEUE: reject: RCPT from > unknown[198.241.168.120]: 550 5.7.25 Client host rejected: cannot find your > hostname, [198.241.168.120]; from=<*munged*@*mybak*> to=< > lbut...@covisp.net> proto=ESMTP helo= > root@mail # dig cportal3.visa.com +short > [9:27] [/var/log] > 198.241.168.120 > > The help doesn’t match the from, but it is valid. > > And yes, this is a BANK, sigh. > > smtpd_helo_restrictions = reject_invalid_helo_hostname, > reject_non_fqdn_helo_hostname, check_helo_access > pcre:/etc/postfix/helo_checks.pcre permit > > > -- > Nihil est--in vita priore ego imperator Romanus fui. > >
Domain cannot be found?
Aug 14 09:25:41 mail postfix/smtpd[44179]: NOQUEUE: reject: RCPT from unknown[198.241.168.120]: 550 5.7.25 Client host rejected: cannot find your hostname, [198.241.168.120]; from=<*munged*@*mybak*> to= proto=ESMTP helo= root@mail # dig cportal3.visa.com +short [9:27] [/var/log] 198.241.168.120 The help doesn’t match the from, but it is valid. And yes, this is a BANK, sigh. smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre permit -- Nihil est--in vita priore ego imperator Romanus fui.
Re: Sender IP reverse lookup rejected
On Wed, 14 Aug 2019, Kadlecsik József wrote: > It seems it's a persistent problem. I tried to contact the postmaster at > the other side but of course got the same reject. We'll try to contact > them via a third party. Using a third party as a relay, I got the same error message. Maybe the whole address space of .hu is blocked and the error message is just misleading. Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
Re: Sender IP reverse lookup rejected
On Wed, 14 Aug 2019, Wietse Venema wrote: > Kadlecsik J?zsef: > > It seems it's a persistent problem. I tried to contact the postmaster at > > the other side but of course got the same reject. We'll try to contact > > them via a third party. > > In that case, try setting > > -o inet_protocols=ipv4 > > (or ipv6) and see if it is a specific kind of DNS that is borked. The MX of the domain has got IPv4 address only, so IPv6 is not used. We have got such a special transport for sites with advertised IPv6 addresses but broken IPv6 connection... Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
Re: check IP before permit_sasl_authenticated
On 13 Aug 19, at 09:19 , Scott Techlist wrote: > I'd like to block certain IP's from attempting to authenticate on my > submission port. You cannot prevent them from attempting to authenticate, at least not via postfix. You would need to firewall them or do something in hosts.allow for that. You can allow them from losing in successfully, regardless of credentials, but you can’t keep them from connecting and trying to login. -- On a scale of one to ten, it sucked.
Re: Sender IP reverse lookup rejected
Kadlecsik J?zsef: > It seems it's a persistent problem. I tried to contact the postmaster at > the other side but of course got the same reject. We'll try to contact > them via a third party. In that case, try setting -o inet_protocols=ipv4 (or ipv6) and see if it is a specific kind of DNS that is borked. Wietse > Thank you to remind me about smtp_delivery_status_filter, it can come > handy in other cases! > > Best regards, > Jozsef > - > E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu > PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt > Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences > H-1525 Budapest 114, POB. 49, Hungary >
Re: Sender IP reverse lookup rejected
On Wed, 14 Aug 2019, Wietse Venema wrote: > > One of our users reported a rejected email with the error code and > > message > > > > Remote-MTA: dns; artemis.gat.com > > Diagnostic-Code: smtp; 550 Sender IP reverse lookup rejected > > > > We handle several domains with different outgoing smtp settings at > > multiple mail gateways: > > > > # /etc/postfix/master.cf > > wignersmtp unix - - y - - smtp > > -o smtp_bind_address=148.6.0.56 > > -o smtp_bind_address6=2001:738:5001::56 > > -o smtp_helo_name=smtp.wigner.mta.hu > > -o syslog_name=postfix-wigner-smtp > > > > # /etc/postfix/main.cf > > default_transport = kfkismtp > > sender_dependent_default_transport_maps = > > hash:/etc/postfix/sender_transport > > > > # /etc/postfix/sender_transport > > @wigner.mta.hu wignersmtp: > > ... > > > > The sender address was from the @wigner.mta.hu domain and the IPv4/IPv6 > > addresses resolve to smtp.wigner.mta.hu. The HELO name is also explicitly > > set to this name. Using debug_peer_list I could verify that the wignersmtp > > transport setting is used for @wigner.mta.hu senders indeed. > > > > So, what kind of incorrect setting can the "Sender IP reverse lookup > > rejected" error message be mean? > > It could be the same problem as GMAIL, where they would do a hard reject > after a temporary error during reverse DNS lookup. > > At the time (years ago) I just turned on "-o soft_bounce=yes" for those > deliveries, so that the email would be delivered later. > > Of course, soft_bounce is not ideal; nowadays I would use > smtp_delivery_status_filter to change the 5.*.* into 4.*.* for that > specific server response. > > If the result of this is that mail stays in the queue, then > further investigation will be needed. It seems it's a persistent problem. I tried to contact the postmaster at the other side but of course got the same reject. We'll try to contact them via a third party. Thank you to remind me about smtp_delivery_status_filter, it can come handy in other cases! Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
Re: Sender IP reverse lookup rejected
Kadlecsik J?zsef: > Hello, > > One of our users reported a rejected email with the error code and message > > Remote-MTA: dns; artemis.gat.com > Diagnostic-Code: smtp; 550 Sender IP reverse lookup rejected > > We handle several domains with different outgoing smtp settings at > multiple mail gateways: > > # /etc/postfix/master.cf > wignersmtp unix - - y - - smtp > -o smtp_bind_address=148.6.0.56 > -o smtp_bind_address6=2001:738:5001::56 > -o smtp_helo_name=smtp.wigner.mta.hu > -o syslog_name=postfix-wigner-smtp > > # /etc/postfix/main.cf > default_transport = kfkismtp > sender_dependent_default_transport_maps = > hash:/etc/postfix/sender_transport > > # /etc/postfix/sender_transport > @wigner.mta.hu wignersmtp: > ... > > The sender address was from the @wigner.mta.hu domain and the IPv4/IPv6 > addresses resolve to smtp.wigner.mta.hu. The HELO name is also explicitly > set to this name. Using debug_peer_list I could verify that the wignersmtp > transport setting is used for @wigner.mta.hu senders indeed. > > So, what kind of incorrect setting can the "Sender IP reverse lookup > rejected" error message be mean? It could be the same problem as GMAIL, where they would do a hard reject after a temporary error during reverse DNS lookup. At the time (years ago) I just turned on "-o soft_bounce=yes" for those deliveries, so that the email would be delivered later. Of course, soft_bounce is not ideal; nowadays I would use smtp_delivery_status_filter to change the 5.*.* into 4.*.* for that specific server response. If the result of this is that mail stays in the queue, then further investigation will be needed. Wietse
Sender IP reverse lookup rejected
Hello, One of our users reported a rejected email with the error code and message Remote-MTA: dns; artemis.gat.com Diagnostic-Code: smtp; 550 Sender IP reverse lookup rejected We handle several domains with different outgoing smtp settings at multiple mail gateways: # /etc/postfix/master.cf wignersmtp unix - - y - - smtp -o smtp_bind_address=148.6.0.56 -o smtp_bind_address6=2001:738:5001::56 -o smtp_helo_name=smtp.wigner.mta.hu -o syslog_name=postfix-wigner-smtp # /etc/postfix/main.cf default_transport = kfkismtp sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport # /etc/postfix/sender_transport @wigner.mta.hu wignersmtp: ... The sender address was from the @wigner.mta.hu domain and the IPv4/IPv6 addresses resolve to smtp.wigner.mta.hu. The HELO name is also explicitly set to this name. Using debug_peer_list I could verify that the wignersmtp transport setting is used for @wigner.mta.hu senders indeed. So, what kind of incorrect setting can the "Sender IP reverse lookup rejected" error message be mean? Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
Re: CAfile problem with OpenSSL-1.1.1c
Hi Andreas, > Am 14.08.2019 um 10:01 schrieb A. Schulze : > > > Christian Rößner: > > Hello Christian, > >> By changing *_CAfile parameters to *_CApath, everything started working >> again. > > nothing specific to your OpenSSL version but: do you run postfix chroot? > from http://www.postfix.org/postconf.5.html#smtpd_tls_CApath: The system is not running chroot. > > "To use smtpd_tls_CApath in chroot mode, this directory (or a copy) must be > inside the chroot jail." > > Andreas > > OT: >> tls_ssl_options = NO_COMPRESSION > > as you're using latest postfix+openssl, you may want to add "no_renegotiation" Thanks, I will add this :-) Christian -- Rößner-Network-Solutions Karl-Bröger-Str. 10, 36304 Alsfeld Fax: +49 6631 78823409, Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Re: CAfile problem with OpenSSL-1.1.1c
Christian Rößner: Hello Christian, By changing *_CAfile parameters to *_CApath, everything started working again. nothing specific to your OpenSSL version but: do you run postfix chroot? from http://www.postfix.org/postconf.5.html#smtpd_tls_CApath: "To use smtpd_tls_CApath in chroot mode, this directory (or a copy) must be inside the chroot jail." Andreas OT: tls_ssl_options = NO_COMPRESSION as you're using latest postfix+openssl, you may want to add "no_renegotiation"
CAfile problem with OpenSSL-1.1.1c
Hi, I recently upgraded my systems to have full openssl-1.1.1c support. After upgrading my mail-server, I realized that I had problems with trusting server certificates. I checked that the server still uses /etc/ssl/certs/ca-certificates.crt, but for some reason Postfix can not work with this file anymore. Even running update-ca-certificates (which added 141 CAs) did not solve the problem. By changing *_CAfile parameters to *_CApath, everything started working again. Is there something special woth TLSv1.3 (OpenSSL-1.1.1c) that I forgot to do after upgrade? Here are some relevant logs I found while troubleshooting: Aug 12 20:32:45 mx postfix/relay/smtp[24007]: setting up TLS connection to mx.roessner-net.de[134.255.226.247]:25 Aug 12 20:32:45 mx postfix/relay/smtp[24007]: mx.roessner-net.de[134.255.226.247]:25: TLS cipher list "aNULL:-aNULL:HIGH:@STR ENGTH:!aNULL" Aug 12 20:32:45 mx postfix/relay/smtp[24007]: looking for session smtp&134.255.226.247& 83C77C56AE6BC60C2C9E9B52C4E501B2D34BA7166F7510D567CEFBE7D30B548 in smtp cache Aug 12 20:32:45 mx postfix/relay/tlsmgr[23993]: lookup smtp session id=smtp&134.255.226.2 47& Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:before SSL initialization Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS write client hello Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS write client hello Aug 12 20:32:45 mx postfix/relay/smtp[24004]: 466k0K1GwXzNkFw: to=<*@ra-roessner-merle.de>, relay=mx.roessner-net.de[1 34.255.226.247]:25, delay=11792, delays=11792/0.16/0.26/0, dsn=4.7.5, status=deferred (Server certificate not trusted) Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS read server hello Aug 12 20:32:45 mx postfix/smtpd[24008]: disconnect from relay.roessner-net.de[134.255.226.249]:46037 ehlo=1 starttls=1 quit= 1 commands=3 Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:TLSv1.3 read encrypted extensions Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:SSLv3/TLS read server certificate request Aug 12 20:32:45 mx postfix/relay/smtp[24005]: mx.roessner-net.de[134.255.226.247]:25: depth=0 verify=0 subject=/CN=mx.roessne r-net.de Aug 12 20:32:45 mx postfix/relay/smtp[24005]: mx.roessner-net.de[134.255.226.247]:25: depth=0 verify=1 subject=/CN=mx.roessne r-net.de Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:SSLv3/TLS read server certificate Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:TLSv1.3 read server certificate verify Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:SSLv3/TLS read finished Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:SSLv3/TLS write change cipher spec Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:SSLv3/TLS write client certificate Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS read server certificate request Aug 12 20:32:45 mx postfix/relay/smtp[24007]: mx.roessner-net.de[134.255.226.247]:25: depth=0 verify=0 subject=/CN=mx.roessne r-net.de Aug 12 20:32:45 mx postfix/relay/smtp[24007]: mx.roessner-net.de[134.255.226.247]:25: depth=0 verify=1 subject=/CN=mx.roessner-net.de Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS read server certificate Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:SSLv3/TLS write certificate verify Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:TLSv1.3 read server certificate verify Aug 12 20:32:45 mx postfix/relay/smtp[24005]: SSL_connect:SSLv3/TLS write finished Aug 12 20:32:45 mx postfix/relay/smtp[24005]: certificate verification failed for mx.roessner-net.de[134.255.226.247]:25: self-signed certificate Aug 12 20:32:45 mx postfix/relay/smtp[24005]: mx.roessner-net.de[134.255.226.247]:25: subject_CN=mx.roessner-net.de, issuer_CN=mx.roessner-net.de, fingerprint=1C:93:B4:39:D9:0A:3C:18:FA:84:90:55:73:77:42:2E, pkey_fingerprint=7C:C6:C5:59:7A:07:A4:E9:14:02:75:92:58:C3:DE:8E Aug 12 20:32:45 mx postfix/relay/smtp[24005]: Untrusted TLS connection established to mx.roessner-net.de[134.255.226.247]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256 Aug 12 20:32:45 mx postfix/smtpd[24006]: Trusted TLS connection established from relay.roessner-net.de[134.255.226.249]:47803: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256 Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS read finished Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS write change cipher spec Aug 12 20:32:45 mx postfix/relay/smtp[24007]: SSL_connect:SSLv3/TLS write client certificate Aug 12 20:32:45 mx postfix/relay/smtp[24005]:
