dovecot - Sep 2012 - LTMP Proxy fails when backend server connection refused

Version: 2.1.9

Connecting directly to the proxy server on the LMTP port, issue lhlo, 
mail from, rcpt to, data. After the . closing of data, it just hangs 
there. The logs on the proxy server show:

Sep 27 19:55:12 proxy1 dovecot: lmtp(9398): Connect from 69.8.2.71
Sep 27 19:55:24 proxy1 dovecot: lmtp(9398): Error: lmtp client: 
connect(lmtp, 7025) failed: Connection refused

root      9398  1102  0 19:53 ?        00:00:00 dovecot/lmtp

The proxy server is hard coded (not director in this case). I 
purposefully shut it down to see how the system would handle failures. 
Unfortunately, it appears that the process just hangs there. For fun, I 
tried a separate protocol lmtp option in the config to try 
proxy_timeout. It made no difference. Missing some error handling?

protocol lmtp {
         passdb {
                 driver = static
                 args = proxy=y host=%s nopassword=y proxy_timeout=120
         }
}


Jack

On 9/27/2012 3:30 PM, Jack Bates wrote:
> Version: 2.1.9
>
> Connecting directly to the proxy server on the LMTP port, issue lhlo, 
> mail from, rcpt to, data. After the . closing of data, it just hangs 
> there. The logs on the proxy server show:
>
Looking at dovecot's proxy code.

Calls to connect_connect_ip do not return an error when the server isn't 
there. This may be expected, but it is what determines failure/OK in the 
LMTP code. The log entry is performed by lmtp_client_wait_connect callback.

In the standard client-common-auth.c code, the error returned for a 
failure is

1) syslog error is reported by proxy_wait_connect() callback
2) error to client is returned by an error in proxy_input()

In the lmtp code, we issue a "250 2.1.5 OK". Right after, the 
lmtp_client_wait_connect() callback is called and issues the connection 
refused error. However, we've already approved the rcpt.

I am not sure which method we really want in the lmtp proxy. Should it 
be failing at the initial rcpt command or after the data command. 
Currently, though I haven't checked yet, we don't appear to be detecting
the input failure and handling the data command correctly since we've 
already allowed the rcpt to proceed without a backend proxy available.


Jack