SSL_error=5
J.P
snap...
May 27 15:18:11 mail sendmail[859]: STARTTLS=server, error: accept
failed=0, SSL_error=5, timedout=0, errno=0
May 27 15:18:11 mail sendmail[859]: i6RDIBgB111859: blablabla.net
[11.11.11.11] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during
connection to MTA
May 27 15:18:11 mail sendmail[857]: i6RDIBgB111857:
from=<Gr...@eu.blaat.com>, size=10626, class=0, nrcpts=1,
msgid=<123.123-123...@someone.com>, proto=ESMTP, daemon=MTA,
relay=mail2.someone.com [22.22.22.22] (may be forged)
check...
telnet 11.11.11.11 25
Trying 11.11.11.11...
Connected to 11.11.11.11.
Escape character is '^]'.
220 alpha.tld.com ESMTP
ehlo user
250-alpha.tld.com
250-AUTH=LOGIN CRAM-MD5
250-STARTTLS
250-PIPELINING
250 8BITMIME
help
214 qmail home page: http://pobox.com/~djb/qmail.html
quit
Others are going fine
Per Hedeland
goo...@pbnec.nl (J.P) writes:
>Anyone also noticed that this happens only with qmail users ?
>
>snap...
>
>May 27 15:18:11 mail sendmail[859]: STARTTLS=server, error: accept
>failed=0, SSL_error=5, timedout=0, errno=0
>May 27 15:18:11 mail sendmail[859]: i6RDIBgB111859: blablabla.net
>[11.11.11.11] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during
>connection to MTA
SSL_error 5 is SSL_ERROR_SYSCALL (you have to check the OpenSSL source
to find that...) - from the man page of SSL_get_error() (the function
that returned this to sendmail):
SSL_ERROR_SYSCALL
Some I/O error occurred. The OpenSSL error queue may contain more
information on the error. If the error queue is empty (i.e.
ERR_get_error() returns 0), ret can be used to find out more about
the error: If ret == 0, an EOF was observed that violates the pro-
tocol. If ret == -1, the underlying BIO reported an I/O error (for
socket I/O on Unix systems, consult errno for details).
The sendmail code never calls ERR_get_error() at this point, but it's
probably a good guess that it would return 0, indicating the EOF ('ret'
was indeed 0, that's the "failed=0" in the log entry). I.e. the client
probably closed the connection abruptly, and a likely reason for this is
that it simply crashed when trying to do the TLS handshake.
You could watch the session with tcpdump or better ssldump to try to get
more info about what exactly is happening, but if STARTTLS works fine
for other clients, it's probably some brokenness regarding TSL in the
client installation. I don't know if such brokenness is particularly
common in qmail installations.:-)
You can also turn off the STARTTLS offering based on client hostname /
IP address (see Srv_Features in cf/README and doc/op/op.*).
--Per Hedeland
p...@hedeland.org