Anton Security Tip of the Day #10: Email Tracking Through Logs

Following the new tradition of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #10: Email Tracking Through Logs

Email tracking - oh, need I say more? :-) A nightmare for privacy fans - an "evil" weapon of lawyers and HR. Email tracking raises concerns that vary from a severe inability to do it all the way to having too much ability to do it. In this tip, we will focus on the following scenario: your boss says she just sent you an email; you never received it. What's the story?

First we need to search our Sendmail server logs (this is that case where searching logs is appropriate) for the email address of the sender (unfortunately, we rarely can search the logs of the remote mail server which sent - or didn't send! - the message in question). One thing to note before we start searching is to limit the time frame to the one close to the reported problem (let's say to the same day).

So, we search for messages containing from=boss@examples.com (since we want the sender address) at January 11 (if you just search for boss@examples.com, the volume of unrelated results will be much higher) and find something like this:

Jan 11 11:45:49 ns1 sendmail[28022]: j0BGjkc28022: from=boss@example.com, size=376597, class=0, nrcpts=1, msgid=Pine.LNX.4.61.0501111145450.17081@boss.example.com, proto=SMTP, daemon=MTA, relay=esafe1.example.com[10.211.15.69] (may be forged)

Is this our message (we are not quite sure since we don't see a recipient)? Why isn't it here?! What do we do next? Well, this is where things get a little ugly (for those unfamiliar with Sendmail logs).

Next, we need to search the logs for this "mysterious" string "j0BGjkc28022" from the previous log record and find this:

Jan 11 11:46:00 ns1 sendmail[28025]: j0BGjkc28022: to=employee@example.com, delay=00:00:14, xdelay=00:00:11, mailer=local, pri=405901, dsn=2.0.0, stat=Sent

So, it looks like our mailserver have indeed sent the message, but what happened to it afterwards? Where did it go next? Given that "employee" has a mail account on the example.com system, most likely the message went into his mail spool (something like /var/spool/mail folder)

Next? If the employee uses local shell access to a mail server and Pine or other similar mail client to read mail (really unlikely, but possible - mostly at University systems), we need to see whether it exists in user's local mail folders, such his /home/username/Mail folder or something similar.

But what if the employee uses POP3 or IMAP to read mail? In this case, we have more logs to go through ... However, most POP3 server logs will not help us determine the fate of a specific message, but just to confirm that the user checked and/or downloaded mail. We will leave POP3 log fun for the next tip...

So, in today's basic tip we covered one simple scenario of email tracking through logs.

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

Technorati tags: security tips, logs, logging, log management, chuvakin