On 14/05/20 23:15 -0400, Viktor Dukhovni wrote:
That was enough of a clue for me. Please build and test the latest
commit from the tls-debug branch in my git repo, you should find it
works regardless of how you access Postgres...
Yes, after a full day of observation today, the issue appears to
On 14/05/20 01:40 -0400, Viktor Dukhovni wrote:
I'f you're comfortable with gdb, and willing to build both Postfix and
OpenSSL from source with debugging symbols, then you could add a "-D"
flag to the "smtpd" entry in the /opt/postfix/etc/master.cf file, and
attach to a "screen" running a debugge
On 13/05/20 21:58 -0400, Viktor Dukhovni wrote:
Please rebuild, and post another similar set of logs.
Thanks. Attached.
Alexander
May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: connect from []
May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio:
hsfunc=0x7f310ef3a780, rfunc=(ni
On 13/05/20 20:40 -0400, Viktor Dukhovni wrote:
Your OpenSSL library looks busted. Do you have more than one set of
OpenSSL libraries installed on your system? What ldd report for the
"smtpd" executable?
Is this the stock OpenSSL for your system, or your own build?
There's just one OpenSSL l
On 13/05/20 16:20 -0400, Viktor Dukhovni wrote:
Try the below. Note, if build as below, it will not replace your system
The output is attached.
Alexander
May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: connect from []
May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_
On 13/05/20 00:34 -0400, Viktor Dukhovni wrote:
an SSL_ERROR_WANT_READ. You need to try an updated OpenSSL.
Thanks for your insights. I'm trying new things to try to improve my
understanding of the issue.
I juggled around some versions. Bumped to libssl 1.1.1g, restarted
postfix, problem pers
On 13/05/20 13:56 -0400, Viktor Dukhovni wrote:
If you're willing to rebuild Postfix from source, then I can provide
a patch that would log more details.
Yes, absolutely willing. Thank you.
Alexander
On 12/05/20 23:27 -0400, Viktor Dukhovni wrote:
Once again out of the blue, a lost connection. The SMTP server is
trying to read the next command after sending "RCPT TO" and encounters
an EOF condition, for no apparent reason. At this point, I'd guess
your SSL library is broken...
I was able
On 12/05/20 21:07 -0400, Viktor Dukhovni wrote:
At this point, clone your submission service onto port 588, and
configure that copy with "smtpd -vvv" + all the other options.
Then use your client to connect to port 588, and there should
now be voluminous logging from the Postfix I/O layer (events
On 12/05/20 05:40 -0400, Viktor Dukhovni wrote:
Indeed the server slams the TCP socket closed after receiving the
client's RCPT command. Unclear why. You might try debug_peer_list
next, to see whether the server can log enough cleartext traffic
to expose the SMTP traffic inside TLS.
Thanks. U
On 11/05/20 23:35 -0400, Viktor Dukhovni wrote:
Attaching it is fine, if you're willing to disclose the IP addresses and
hostnames of the two servers.
Okay, I've attached two files; the PCAP and the postfix log.
To clarify my earlier email, the unencrypted session scenario only
arises when I r
The real problem is that the connection was terminated mid-transaction.
The "shutdown while in init" is I think a distraction, Postfix was
cleaning up the TLS session, when it was not yet, or is no longer in a
state that is valid for calling SSL_shutdown(). If you manage to
collect a PCAP captur
The remote peer sent a TLS shutdown message during the TLS handshake.
There is no way to 'continue' the handshake.
Maybe the remote peer times out - you could find out by looking at
the TIME STAMPS in your logs. Causes for timeout: your server is
slow, or your network has packet loss.
The times
nd expected but most fail due to
this error and I haven't been able to identify a pattern.
A survey of the mailing list suggests the problem as experienced by
another user may have been related to tlsproxy but I have
smtp_tls_connection_reuse set to no.
Thanks and regards,
Alexander Vasarab
14 matches
Mail list logo
