Archived Forum Post

Index of archived forum posts

Question:

POP3 CheckMail recurring login issue

May 21 '13 at 05:32

I have a c# routine that runs mailman.CheckMail() every 5 minutes against the POP3 service on outlook.com. Every once in a while the check fails with unknown user name or bad password. It happens at least once an hour, but the remaining times it works just fine.

The code used is fairly simple:

Chilkat.MailMan mailman = new Chilkat.MailMan();
...    
mailman.MailHost = "podXXXXX.outlook.com";
mailman.MailPort = 995;
mailman.PopSsl = true;
mailman.PopUsername = "XXXXXXXXXX";
mailman.PopPassword = "XXXXXXXXXX";
mailman.ConnectTimeout = 60;
mailman.ReadTimeout = 60;

// Verify the POP3 TCP/IP connection.
bool success = mailman.VerifyPopConnection();  <-- Is is wrong to verify here??
if (!success)
{
    return;
}

// Get number of emails
int nMails = mailman.CheckMail();

This may not be a chilkat or programming issue, but can I always trust that the login is properly transmitted to the POP3 server?

I would be able to understand recurring connection issues or similar cause, but since it appears the the connection is established properly, that does not seem to be the cause. Of course it could be a Microsoft internal problem but then there is most likely nothing I can do to solve the problem.

The full error message is:

ChilkatLog:
  CheckMail:
    DllDate: Dec 18 2012
    UnlockPrefix: XXXXXXXXXX
    Username: XXXXXXXXXXXX
    Architecture: Little Endian; 32-bit
    Language: .NET 4.5
    VerboseLogging: 0
    SendAlert:
      TlsAlert:
        level: warning
        descrip: close notify
      --TlsAlert
    --SendAlert
    socket shutdown..
    Pop3Connect:
      Connecting to POP3 server
      hostname: podXXXXX.outlook.com
      port: 995
      ssl: 1
      connectTimeoutMs: 60000
      heartbeatMs: 0
      ConnectTimeoutMs_1: 60000
      calling ConnectSocket2
      IPV6 enabled connect with NO heartbeat.
      connectingTo: podXXXXX.outlook.com
      resolveHostname1:
        Resolving domain name (IPV4) via gethostbyname
      --resolveHostname1
      GetHostByNameHB_ipv4: Elapsed time: 0 millisec
      myIP_1: XXXXXXXXXX
      myPort_1: 64108
      connect successful (1)
      clientHelloMajorMinorVersion: 3.1
      buildClientHello:
        majorVersion: 3
        minorVersion: 1
        numRandomBytes: 32
        sessionIdSize: 0
        numCipherSuites: 10
        numCompressionMethods: 1
      --buildClientHello
      readIncomingTls_serverHello:
        processTlsRecord:
          processHandshake:
            handshakeMessageType: ServerHello
            handshakeMessageLen: 0x46
            processHandshakeMessage:
              MessageType: ServerHello
              Processing ServerHello...
              ServerHello:
                MajorVersion: 3
                MinorVersion: 1
                SessionIdLen: 32
                CipherSuite: RSA_WITH_AES_128_CBC_SHA
                CipherSuite: 00,2f
                CompressionMethod: 0
                Queueing ServerHello message.
                ServerHello is OK.
              --ServerHello
            --processHandshakeMessage
            handshakeMessageType: Certificate
            handshakeMessageLen: 0x11f8
            processHandshakeMessage:
              MessageType: Certificate
              ProcessCertificates:
                Certificate:
                  derSize: 1755
                  certSubjectCN: outlook.com
                  certSerial: 6097CFFA000100005018
                  certIssuerCN: MSIT Machine Auth CA 2
                --Certificate
                Certificate:
                  derSize: 1548
                  certSubjectCN: MSIT Machine Auth CA 2
                  certSerial: 615DAAD2000600000040
                  certIssuerCN: Microsoft Internet Authority
                --Certificate
                Certificate:
                  derSize: 1285
                  certSubjectCN: Microsoft Internet Authority
                  certSerial: 07276FAE
                  certIssuerCN: Baltimore CyberTrust Root
                --Certificate
                NumCertificates: 3
                Queueing Certificates message...
              --ProcessCertificates
            --processHandshakeMessage
            handshakeMessageType: ServerHelloDone
            handshakeMessageLen: 0x0
            processHandshakeMessage:
              MessageType: ServerHelloDone
              Queueing HelloDone message.
            --processHandshakeMessage
          --processHandshake
        --processTlsRecord
      --readIncomingTls_serverHello
      HandshakeQueue:
        MessageType: ServerHello
        MessageType: Certificate
        MessageType: ServerHelloDone
      --HandshakeQueue
      Dequeued ServerHello message.
      Dequeued Certificate message.
      DequeuedMessageType: ServerHelloDone
      OK to ServerHelloDone!
      No client certificate required by the server.
      Encrypted pre-master secret with server certificate RSA public key is OK.
      Sending ClientKeyExchange...
      Sent ClientKeyExchange message.
      Sending ChangeCipherSpec...
      Sent ChangeCipherSpec message.
      Derived keys.
      Installed new outgoing security params.
      Sending FINISHED message..
      algorithm: aes
      keyLength: 128
      Sent FINISHED message..
      readIncomingTls_changeCipherSpec2:
        processTlsRecord:
          processChangeCipherSpec:
            ccsProtocolType: 1
          --processChangeCipherSpec
        --processTlsRecord
      --readIncomingTls_changeCipherSpec2
      readIncomingTls_handshakeFinished2:
        processTlsRecord:
          processHandshake:
            handshakeMessageType: HandshakeFinished
            handshakeMessageLen: 0xc
            processHandshakeMessage:
              MessageType: HandshakeFinished
              FinishedMsgLen: 12
              Queueing Finished message.
            --processHandshakeMessage
          --processHandshake
        --processTlsRecord
      --readIncomingTls_handshakeFinished2
      Dequeue the FINISHED message...
      Dequeued Finished message.
      Handshake completed successfully.
      Secure Channel Established.
      Turning on TCP_NODELAY.
      Connected to POP3 server
      Turning on TCP_NODELAY.
      socketOptions:
        SO_SNDBUF: 65536
        SO_RCVBUF: 65536
        TCP_NODELAY: 65537
      --socketOptions
      PopCmdResp: +OK The Microsoft Exchange POP3 service is ready. [QQBNAFMAUABSAEQAMAAzADEAMABDAEEAMAAwADYALgBlAHUAcgBwAHIAZAAwADMALgBwAHIAbwBkAC4AbwB1AHQAbABvAG8AawAuAGMAbwBtAA==]
      greeting: +OK The Microsoft Exchange POP3 service is ready. [QQBNAFMAUABSAEQAMAAzADEAMABDAEEAMAAwADYALgBlAHUAcgBwAHIAZAAwADMALgBwAHIAbwBkAC4AbwB1AHQAbABvAG8AawAuAGMAbwBtAA==]
      ConnectionType: SSL/TLS
    --Pop3Connect
    Pop3Authenticate:
      username: xxxxxxxxx
      popSPA: 0
      PopCmdSent: USER xxxxxxxxx
      PopCmdResp: +OK
      PopCmdSent: PASS ****
      PopCmdResp: -ERR Logon failure: unknown user name or bad password.
      POP3 response indicates failure.
      PASS_response: -ERR Logon failure: unknown user name or bad password.

      POP3 authentication failed
    --Pop3Authenticate
    Authentication failed.
    Not in transaction state
    Failed.
  --CheckMail
--ChilkatLog

Answer

Here are some comments:

1) Instead of calling VerifyPopConnection, I would recommend calling Pop3BeginSession which connects and authenticates.

2) I've noticed the same behavior in non-Chilkat apps. For example, from time to time when checking email on my IPhone, I get an error message indicating the login is invalid -- but I know it is not. I wonder if this is somehow related?

3) Turn on VerboseLogging, and examine the contents of the Pop3SessionLog property. With verbose logging on, the Pop3SessionLog should contain the login/password. With verbose logging off, the password would be excluded from the log. You can use the session log to verify that the correct login/password was indeed being sent.


Answer

I would like to add that after I added a retry delay of 10 seconds, I practically get no authentication failures logged. For clarification my code now looks like this:

// Verify the POP3 TCP/IP connection and authenticate
bool success = mailman.Pop3BeginSession();
if (!success)
{
    // The POP3 server indicates authentication failure from 
    // time to time so retry after a short delay before failing.
    System.Threading.Thread.Sleep(10000); // 10 seconds
    success = mailman.Pop3BeginSession();
    if (!success)
    {
        ErrorHelper.LogError(mailman.LastErrorText);
        return false;
    }
}

Perhaps Pop3BeginSession() could have an optional argument to retry automatically x number of times or after a specified delay before failing completely?! Since this is little extra code I had to add, it hardly justify modifying Pop3BeginSession(). The same problem happens with IMAP though, so if a workaround will be introduced in Pop3BeginSession(), it should also be implemented in IMAP's Login() method.

Too bad that my discussion with Microsoft over this problem has led nowhere so far. Their attitude seems to indicate random network errors rather than internal authentication errors.