Who is accessing my IMAP inbox?

 The issue

A certain user who was reading his email messages using Thunberdbird 13.0 IMAP client, complained about not seeing any new messages on his inbox. Apparently, all the new messages that had been received were perfectly visible whenever accessing his IMAP account from an Internet Browser. In order to see these very same email messages in Thunderbird, the user was due to close and then re-open this IMAP email client software. No other connections were established, according to the user, to his IMAP account. The user was reading his email from an internal IP address from the University.

Let’s be sure of it

Occam’s razor. It always works, at least for me. These symptoms were so similar to the ones affecting any IMAP account whenever concurrent accesses were taking place, that it was difficult not to have a serious look at who was connected  to his IMAP account and from where, to say the least. Unluckily, I could not track down any internet connections to the IMAP server, because I was not the one in charge of it. Therefore, I needed something that could do that for me. TBTracer was the perfect add-on to fulfil all my needs.

After installing it, I decided to track only all the IMAP conversation between the client (that is, Thunderbird), and the server. Therefore, I ran this command – according to the TBTracer’s reference – on a CLI:

export NSPR_LOG_FILE="/tmp/tbtrace.log"

Thus, all the IMAP log would be annotated on a log-file, that is,  /tmp/tbtrace.log.

After a couple of minutes, I looked for calls to the function CreateNewLineFromSocket(), the ones describing what IP addresses were accessing this IMAP account and, moreover, which folders they were accessing to. In theory, at least two different IPs were to be found, if the original idea of having concurrent IMAP connections to this account had to be proven.

And so, this is what I got whilst analysing the log:

1780471552[7ff56745d9d0]: 88e61800:upc.edu:S-Sent:CreateNewLineFromSocket:  []) by web-k2pim.upc.edu (Horde Framework) with HTTP; Fri, 29

Apparently, an external IP address was, in fact, accessing the Sent folder from an Internet Browser. Thus, another connection was already established, affecting and even blocking this IMAP account in doing so.

Determining who that was

A simple call to nslookup revealed that this IP was from ONO, the same IP belonging to the user’s personal computer at home. This computer was, in fact, powered on and running an Internet Explorer process that was accessing the IMAP account, though the user had no idea about that. Apparently, the computer was supposed to be switched off. As it turned out to be, it was not and, besides, Internet Explorer was still running despite the fact that the user thought it was completely closed. As I stated earlier, Occam’s razor. It never fails ;-).