Re: Failure to connect with cox.net

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]) '[email protected]'
> connected(CLRTXT) from [72.208.72.31]: 42690(tls)

That's a *SUCCESSFUL* connection and login by the user 
'[email protected]' 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]) '[email protected]'
> 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]) '[email protected]'
> 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]) '[email protected]'
> 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.


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[email protected]>.
To unsubscribe, E-mail to: <[email protected]>
To switch to the DIGEST mode, E-mail to <[email protected]>
To switch to the INDEX mode, E-mail to <[email protected]>
Send administrative queries to  <[email protected]>