On Jul 11, 2009, at 6:40 PM, Barney Desmond wrote:
2009/7/11 Wietse Venema <wie...@porcupine.org>:
system.log:Jul 10 00:07:57 trex postfix/smtpd[45598]: warning: TLS
library problem: 45598:error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:571:
This is openssl's way of saying that the client sent garbage.
To expand on that, I imagine it means the client tried to talk
plaintext when Postfix was expecting crypto.
Thanks for the estimation. Comparing a working transaction with one
that does not work, shows no difference. The one part I need even
more debug log data, only states "start tls" and then "failure". I
somehow need to get to the data that happens between those two log
lines.
It is good to finally know this is more than likely the proxy though.
Can you clarify exactly how this is meant to work? You said you want
MTA-to-MTA crypto, I assume in this particular case you mean
Proxy->Postfix crypto. Depending on how much control you have over the
configuration, you could use a "dumb" method like an stunnel pipe, or
something smarter like STARTTLS in-band.
I am trying to avoid stunnel, because this is supposed to be built
into the proxy, and I have invested a lot of time into a package for
the proxy. I have invested about as much time into testing and trying
to debug this issue.
My basic setup is Internet -> proxy - postfix
Where postfix is a working MTA that has worked for months on end as a
rock solid MTA.
The basics are, an email comes in on port 25, from anywhere, it could
be the local machine or inbound from any host. Connect to port 25 on
the proxy, which is then connected up to the remote postfix machine.
STARTTLS is issued, and a secured connection from the proxy to postfix
is made. The majority of the time, emails do make it, and are
secured. Some times they do not. I have found some hosts that simply
never make it, others that will make it in many hours time.
I have found in 99% of the cases, a machine on the local subnet to the
proxy, will fail, but can eventually deliver a few hours later. They
just sit in that local machines postfix queue and are tried later.
This is a convenient way for me to test.
For what it is worth, turning off STARTTLS on port 25 in postfix, and
I am back to 100% reliability.
It sounds like you're trying to do the latter,
Correct.
but you say "STARTTLS
is issued. At that point, the proxy will either make the crypto
connection, and deliver the mail off to postfix, or, it will drop the
connection.".
Dropped connection. What is more odd, is telnet prxoy.example.com 25
then the ehlo, mail from, rcpt to, data dance works. Where it fails,
is when I use `mail u...@example.com` on the command line.
openssl client to the remote postfix, and the proxy, connect up fine
as well. But maybe I just am not testing it enough it hit a failure.
Why should the proxy drop the connection? In any case, I
think the proxy needs debugging.
I agree.
You might also try adding the proxy
as a verbose peer in Postfix, it might make the client's mistakes
quickly evident.
Doing a search on that turns up this very thread :)
Can you point me to docs on verbose peer, as well as an other
suggestion you may have now that you know a little more.
If there is a kind soul out there that knows this stuff well, and
could ever allow me to point an MX at them, and add an account, so I
could point the proxy to them, allowing a little help with debugging
this, I would be most appreciative.
Thank Barney for the suggestions.
--
Scott * If you contact me off list replace talklists@ with scott@ *
