The MSN Messenger Protocol Torn Apart: Part 1/3 - User Statuses (Page 6 of 7 )
Every time a user comes online your msn messenger alerts you, doesn't it? The client knows when this happens because the server tells it. That's what your client should be ready to handle. The server uses NLN and FLN commands to tell us the real time status of users. Lets have a closer look:
Look at the first command. It begins with the NLN command identifier. The NLN command notifies the client when users go online or their online state changes. The NLN command doesn't contain any transaction id because you really don't need to respond to this message (respond as in respond back to the server with a command). It's just to let you know that a users online state has changed. After that we have the current state of the user. 'AWY' in this case means the user has changed his status to away. After that we have the respective users email id and his screen name.
Let's have a look at the second command. It's the FLN command identifier. The FLN command notifies the client when the user goes offline. Again, this command doesn't have a transaction id (the same reason why the NLN command doesn't have a transaction id). This command sends us just one more parameter, which is the users email id that has gone offline.
Challenges In order to make sure that your msn client is active, the server keeps sending something called challenges at regular intervals. These commands are sent at random times. Let me show you what these commands are and how you should respond to them. This is a typical challenge message the server would send you:
CHL 0 90938290383838737622
It contains the command identifier CHL. Next we have a transaction id, which is 0. Whenever the server needs to send you any commands it usually would use the transaction id of 0. The final parameter is a challenge string.
What you would have to do is take this challenge string, concatenate it with the string 'Q1P7W2E4J9R8U3S5' and encrypt the resultant string with the MD5 algorithm. So in this case you would encrypt '90938290383838737622Q1P7W2E4J9R8U3S5' using the MD5 algorithm and send it back to the server. We would send a reply, which looked like this:
We respond to this challenge with the QRY command. We send with it an all-new unique transaction id. Next, we send the string 'email@example.com' and finally the number 32. 32 denotes the number of bytes in the command excluding the current line, which contains the QRY command identifier. After that we have a line break and we send the encrypted MD5 digest along.
The server would respond back with this message:
The server sends you the QRY command with the same transaction id you had used to send the server the answer of the challenge i.e. 10. Receiving this message would mean you have successfully passed the challenge. In case you fail to challenge, the server would disconnect you and send you an error command.
Server Messages There are a few other server messages that the server sends to us on a few occasions. Again, it's up to you to respond to them or not.
This is the message command the server sends to us when we receive a new email:
From: Mehta Message-URL: /cgi-bin/getmsg?msg=MSG1029401739.3&start=1610592& len=402&curmbox=ACTIVE Post-URL: https://lc1.law13.hotmail.passport.com /ppsecure/domessengerlogin/EN Subject: Hi Dest-Folder: ACTIVE From-Addr: firstname.lastname@example.org id: 2
The first 3 lines I have already explained earlier. The Content-Type of this message is 'text/x-msmsgsemailnotification'. The mime body again contains the details about the new email message, which has just arrived. It contains details like its subject, who it is from, which email id is it from etc.
This is the message the server sends to us when delete an email from our inbox: