Pings are commands sent by either the server or the client, presumably to ensure the connection. These are analogous to the PINGs and PONGs of IRC. Pings from the client are sent with the PNG command and replied to with the QNG command. Pings sent from the server are sent with the CHL command and replied to with the QRY command.
Pings from the client are generally used to either make sure the connection is still working or to prevent some NATs from automatically closing idle sockets. One can also use these pings to test the latency between the client and the server.
PNGs may be sent at any time after the second USR has been sent with the password.
Client pings are the simplest of all commands. The client sends PNG with no TrID or parameters, and the server responds with a QNG with no TrID or parameters. A ping and server response will always look like this:
>>> PNG\r\n
<<< QNG\r\n
Pings from the server are sent with the CHL command. They are often referred to as challenges, because that is a good possibility as to what the three letter code stands for.
Challenges are sent by the NS from time to time, the first one shortly after the initial status has been set with CHG. There's no regular period to the time between CHLs. They include two parameters - the first is always "0", the second is the "challenge string". This has always been a 20-digit number, but a client shouldn't rely on that. A challenge might look something like this:
<<< CHL 0 15570131571988941333\r\n
When you receive a challenge, you must send a QRY command to the server within about 50 seconds or you'll be disconnected. QRY is a payload command with a TrID and two parameters: a client identification string and the number of bytes in the payload. As with all payload commands, the length is be followed by a newline, then the payload, which is not followed by a newline. The payload of the QRY command is the "MD5 digest" of the challenge string and a client identification code. MD5 digests are always 32 bytes in length.
If you sent an invalid email address or incorrect digest, the server will send error 540 and close the connection. If you get the payload wrong, the results will be hard to predict and not good. Otherwise, the server will send a QRY response with the same TrID and no parameters.
Different Microsoft clients use different ID codes and ID strings. Here is a list of the strings and their corresponding strings:
| Client ID string | Client ID code |
|---|---|
| msmsgs@msnmsgr.com | Q1P7W2E4J9R8U3S5 |
| PROD0038W!61ZTF9 | VT6PX?UQTM4WM%YR |
| PROD0058#7IL2{QD | QHDCY@7R1TB6W?5B |
| PROD0061VRRZH@4F | JXQ6J@TUOGYV@N0M |
It doesn't matter which ID string you use, but you must use the corresponding ID code - for example, you can't use msmsgs@msnmsgr.com with VT6PX?UQTM4WM%YR.
A common theory for why challenge strings exist is to keep third party client developers away from the protocol. How these client ID codes were originally discovered has been lost in the mists of time, but they were presumably either reverse-engineered or leaked from Microsoft, so we're not sure what their legal state is. There is a thread in the forum discussing the legality of challenges.
MD5 is a message digest algorithm. Taking the MD5 digest of a string gives you a 32 byte "fingerprint" of it. If possible, you should try to find a library or an external program that creates MD5 fingerprints, but it's is officially described in RFC 1321, so you can try to implement it yourself if you're feeling brave. Make sure that your library can produce lower-case hexadecimal digests (there should be an option for this)
When the server gives you a challenge string, add your client code onto the end of it. For example, if the server gives you abcdefg and your code is 1234567, the input to the MD5 function should be abcdefg1234567. The hexadecimal digest for abcdefg1234567 is d1713d0f1d2e8fae230328d8fd59de01. I suggest you check your implementation using this example.
Here is an example server ping and reply. You should check that your MD5 implementation against this example to make sure that you're encoding correctly. The most common mistake is to add a newline to the end of the challenge string before or after encoding it.
<<< CHL 0 15570131571988941333\r\n
>>> QRY 1049 msmsgs@msnmsgr.com 32\r\n
8f2f5a91b72102cd28355e9fc9000d6e (no newline)
<<< QRY 1049\r\n
In this case, you would take the hexadecimal digest of 15570131571988941333Q1P7W2E4J9R8U3S5 which happens to be 8f2f5a91b72102cd28355e9fc9000d6e, and of course is 32 bytes long.