Re: Unexpected lmtpproxy response
From: "JP Howard" <[EMAIL PROTECTED]> Date: Wed, 11 Dec 2002 15:18:40 +0800 On Wed, 11 Dec 2002 17:06:51 +1100, "Rob Mueller" <[EMAIL PROTECTED]> said: > Every now and then, we see the following error in our logs: > > Dec 6 22:29:20 www postfix/lmtp[15516]: 7319A58B2: to=, > relay=/var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox], delay=218, > status=bounced (host /var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox] > said: 250 2.1.5 ok (in reply to DATA command)) I can't think of any obvious reason why this might happen. Due to the lmtpengine abstraction, it should be pretty damn hard for it to be sending the wrong number of error messages somewhere. But it's possible there's a weird error path. I think step #1 would be to try to get a protocol log. This is hard, since it can be a lot of data. Larry
Re: Unexpected lmtpproxy response
On Wed, 11 Dec 2002 17:06:51 +1100, "Rob Mueller" <[EMAIL PROTECTED]> said: > Every now and then, we see the following error in our logs: > > Dec 6 22:29:20 www postfix/lmtp[15516]: 7319A58B2: to=, > relay=/var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox], delay=218, > status=bounced (host /var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox] > said: 250 2.1.5 ok (in reply to DATA command)) > <...> > There are a few specifics that seem to trigger it: > 1. We're using a unix socket. If we change to an inet one with an > internal IP address, the problem doesn't seem to occur Actually, we haven't confirmed #1 as yet. I'm not sure whether or not it occurs with a TCP socket.
Unexpected lmtpproxy response
Every now and then, we see the following error in our logs: Dec 6 22:29:20 www postfix/lmtp[15516]: 7319A58B2: to=, relay=/var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox], delay=218, status=bounced (host /var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox] said: 250 2.1.5 ok (in reply to DATA command)) We're currently using a hacked version of the lmtpproxyd.c to do proxied delivery to our separate IMAP servers. The code is basically the same, though we've replaced the mupdate lookup stuff with our own hostname lookups. There are a few specifics that seem to trigger it: 1. We're using a unix socket. If we change to an inet one with an internal IP address, the problem doesn't seem to occur 2. The load of the destination lmtp server is quite high We're running linux, so I'm not sure if it's a linux bug, some race condition in the proxy or kernel, or anything else for that matter. Odd. Just thought I'd check if anyone else has seen it or knows a work around. Rob
