Mailing List CGatePro@mail.stalker.com Message #105994
From: Bill Cole <cgp-2015@billmail.scconsult.com>
Subject: Re: Failure to connect with cox.net
Date: Mon, 15 Feb 2016 15:09:21 -0500
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
X-Mailer: MailMate (1.9.4r5222)
On 13 Feb 2016, at 16:12, James Moe wrote:

On 02/12/2016 12:02 PM, James Moe wrote:
Error Code=unknown secondary
domain name

This was due to a setting that was counter-productive. In
General::Other::TLS Sessions "Process Target Domain extensions" was set.
Poor choice.

Often not really a problem either, except with very picky clients OR with a server using  one IP for many different domains. Can be silenced by adding any names you want clients using that resolve to the answering IP for a domain to the Domain Aliases on the Domain Settings page.

However, unsetting that feature has had no affect on accessibility by
cox.net.
Below are other log entries which indicate a failure to connect.

Au contraire, they indicate *SUCCESSFUL* connections. Really.

Note
the 15 minute timeout. These are all of the log entries for a typical
failure to connect.

12:30:06.677 2 IMAP-000377([72.208.72.31]) 'sma.community@sma-inc.us'
connected(CLRTXT) from [72.208.72.31]: 42690(tls)

That's a *SUCCESSFUL* connection and login by the user 'sma.community@sma-inc.us' using a cleartext auth method (i.e. PLAIN or LOGIN) over a TLS session (so that  auth method was safe) from TCP port 42690 on 72.208.72.31, a Cox IP address.

Without the *SUCCESSFUL* connection, there could be no attempt to log in and if the login had failed, you'd see that failure in the log instead of this indication of SUCCESS.

-- wait for it --

12:45:16.962 3 IMAP-000377([72.208.72.31]) read failed. Error
Code=connection reset by peer

15 minutes and 10.285 seconds after login, the session was closed while CGP was expecting the client to say something (maybe to renew an IDLE mode session, maybe waiting for a command) but instead it got a TCP RESET for the session. Since such disconnections are often harmless and typical, they are logged at level 3.

Such disconnections are harmless and typical because many modern mail clients routinely drop sessions without saying LOGOUT or QUIT or whatever the particular protocol requires, or they send a goodbye message without a TCP PUSH flag and unilaterally close the socket without waiting for a response and server-initiated TCP close. Kids these days are so rude...

12:45:16.962 2 IMAP-000377([72.208.72.31]) 'xxx.yyy@sma-inc.us'
disconnected ([72.208.72.31]:42690)

I assume the xxx.yyy username is a munge of 'sma.community', because that's just CGP's level 2 log entry for an end of session and everything else matches what we already know of IMAP session 000377.

There's nothing indicating a concrete problem *AT ALL* here.


13:50:30.493 2 IMAP-000664([97.44.128.123]) 'xxx.yyy@sma-inc.us'
connected(CLRTXT) from [97.44.128.123]:2161(tls)(temp client)

-- wait for it --

14:05:46.504 3 IMAP-000664([97.44.128.123]) read failed. Error
Code=connection reset by peer
14:05:46.504 2 IMAP-000664([97.44.128.123]) 'xxx.yyy@sma-inc.us'
disconnected ([97.44.128.123]:2161)

Same basic pattern, this time a much longer session from a Verizon Wireless IPaddress. It's unclear how this relates to anything else you've mentioned....


Any ideas what may be causing this?

Users using IMAP with apparent success and the very minor & common misbehavior of ending sessions without saying goodbye and closing the TCP session properly.

Suggestion:crank up your logging level for IMAP or perhaps just add the addresses with known real problems to your "Debug Addresses," list and look for actual problems at specific known times when there is a clear failure.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster