Jesús Manuel Loaiza Vidal escribió:
Jesús Manuel Loaiza Vidal escribió:
Victor Duchovni escribió:
On Tue, Dec 16, 2008 at 02:45:19PM -0700, Jes?s Manuel Loaiza Vidal
wrote:
We need to log the error detail from the SSL library to see what the
library is unhappy about. This sure looks like an SSL library bug,
compiler bug or hardware issue. The kernel is no longer suspect
for now.
In addition to the previous patch, please also apply:
--- src/tls/tls_bio_ops.c 2008-12-16 15:12:12.000000000 -0500
+++ src/tls/tls_bio_ops.c 2008-12-16 15:12:30.000000000 -0500
@@ -345,6 +345,10 @@
return (-1); /* network read/write
error */
}
break;
+ case SSL_ERROR_SSL:
+ if (hsfunc == 0)
+ tls_print_errors();
+ /* FALLTHROUGH */
default:
retval = status;
done = 1;
and report the results (logs).
The logs:
mail log <http://www.ich.edu.mx/attachments/postfix-4.txt>
pcap file <http://www.ich.edu.mx/attachments/tcp-4.cap>
Thanks:
Dec 16 14:39:49 [postfix/smtpd] warning:
TLS library problem: 3079596704:error:14094410:SSL
routines:SSL3_READ_BYTES:sslv3 alert handshake failure:
s3_pkt.c:1053:SSL alert number 40:
This is bogus. It appears that the library believes it has valid
protocol
data to consume without reading the client's next record, but the
previous
record containing the client's "RCPT TO:" command is of the right
length
to account for all the data seen on the wire and was fully consumed by
a previous SSL_read(). So the internal library state is at this point
severely corrupted. It sees an "alert" record instead of an empty
buffer.
Try different hardware and/or memory diagnostics. Also try recompiling
both Postfix and OpenSSL on a known non-flaky machine...
The purpose of my test host was exactly that. Same problem occurs in
my main mail host wich is a 64bit Xen VM on a Xeon 5140 x86_64 host
with 8gb FB ram, and my main mail server is in one virtual machine
using Xen.
My test host is a clean gentoo install from scratch on a Windows 2003
Server (Xeon X5355 x86_64 host with 8gb FB ram) and a 32bit
Virtualbox VM wich I have setup nearly like my main mail host (with
the exception of content filtering/DKIM signing/etc).
I hoped my main mail host was the problem, but sadly also had the
same issue on my test host.
Weird case.
If I comment these two lines from my main.cf, the problem doesn't
occur (at least not from the first time or occurs less, having tried
two times and no issues):
#smtpd_sender_login_maps = ldap:/etc/postfix/ldap-sendermaps.cf
smtpd_sender_restrictions =
permit_mynetworks,
# reject_sender_login_mismatch,
permit_sasl_authenticated,
check_sender_access pgsql:/etc/postfix/pgsql-senderpolicy.cf,
reject_non_fqdn_sender,
reject_unknown_sender_domain
In my main mail host I used PostgreSQL lookup tables for
smtpd_sender_login_maps (in my main host there is no LDAP lookups
still), so LDAP library cannot be the problem
Here are the logs:
mail log <http://www.ich.edu.mx/attachments/postfix-5.txt>
pcap file <http://www.ich.edu.mx/attachments/tcp-5.txt>
I have a mistake in the link of pcap file
pcap file <http://www.ich.edu.mx/attachments/tcp-5.cap>
