Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
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
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.
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.