View Full Version : Can you verify who sent an e-mail by header information?
Ernie M
8th February 2008, 07:49 PM
Can the information contained in an expanded view of an e-mail header legally prove who sent it? And, can that information legally verify what day and time the e-mail was sent?
Can you tell from information like:
From:
Subject:
Date:
To:
Received:
Received:
Received:
X-Originating-Ip:
Message-Id:
Mime-Version:
Content-Type:
Sun-Java-System-Smtp-Warning:
User-Agent:
Or does someone like a forensic computer investigator need to have the originating e-mail sending computer in hand, and access the hard drive to verify that it was that particular machine which sent the e-mail in question?
In other words, if I sent you an e-mail from my computer to your computer, can you tell beyond a reasonable doubt that it came from my machine? And, can you legally verify what date and time I sent it?
I know I might need to provide you with more particulars, but for starters, assume that the machine that sent the e-mail, and the machine that received the e-mail, are Window's based PC's. I do not know what the sending machine was using for an Operating System or e-mail program, but I should know early this week (February 12-14, 2008) what the receiving computer used for an OS and e-mail program.
Supercharts
8th February 2008, 10:23 PM
What do you use to receive e-mail? Office, Opera, Agent, MS Express..?
Here_to_learn
9th February 2008, 03:31 AM
Well, the thing is that each of the "Received"-lines tells you that the email has been handled by a certain email server. Assuming that all the email servers involved can be trusted, and are correctly configured, and have no bugs, and run the latest version, and...
Ok, let's stop there. If you can trust the email servers, then you can also (mostly) trust the content of those lines. But if any of the email servers involved can be fooled, then someone can inject the email into that server and supply it with a couple of faked "Received"-lines. At that stage it gets very hard to trace the email back.
So to be fully able to trace an email back, you really should have access to the log files of every involved email server.
There are some resources available that can help you trace email headers. I just did a Google on "trace email headers", and found both tutorials and tools that can help you see how far back you can trace what you have.
I used to do this (trying to stop spammers from hitting my email server) some years ago, and usually I would find a mis-configured email server two or three steps back. If I was really lucky, I could find an IP address in the headers that led me back to the source, but it's a boring job.
Arkan_Wolfshade
9th February 2008, 05:21 AM
Easiest way to learn bout this subject is to read antispam websites. They fully explain how to trace the origins of an email.
shadron
10th February 2008, 06:53 PM
I believe that it has been pretty well established that any or all of these lines can be faked. Anyone can set up an SMTP server and force it to include anything it is told to include in the message header. If someone rigged a mail server and somehow persuaded you to attach to it, the whole thing is suspect.
nescafe
11th February 2008, 06:59 PM
No. They can all be spoofed. If you need something that will stand up in a court of law, PGP and similar programs are the only way to go.
jeremyp
12th February 2008, 04:54 PM
In other words, if I sent you an e-mail from my computer to your computer, can you tell beyond a reasonable doubt that it came from my machine?
The received headers provide an audit trail of all the SMTP servers the e-mail has been through. If there are some spoofed received headers, it might be tricky telling where spoofed ones end and the real ones begin, but probably not impossible.
And, can you legally verify what date and time I sent it?
Only if you can positively identify the earliest legitimate Received header which should have a time stamp of when the e-mail was received by the firsat real SMTP server - everything else can be faked.
ElMondoHummus
12th February 2008, 06:04 PM
Can the information contained in an expanded view of an e-mail header legally prove who sent it? And, can that information legally verify what day and time the e-mail was sent?
Can you tell from information like:
From:
Subject:
Date:
To:
Received:
Received:
Received:
X-Originating-Ip:
Message-Id:
Mime-Version:
Content-Type:
Sun-Java-System-Smtp-Warning:
User-Agent:
Or does someone like a forensic computer investigator need to have the originating e-mail sending computer in hand, and access the hard drive to verify that it was that particular machine which sent the e-mail in question?
In other words, if I sent you an e-mail from my computer to your computer, can you tell beyond a reasonable doubt that it came from my machine? And, can you legally verify what date and time I sent it?
I know I might need to provide you with more particulars, but for starters, assume that the machine that sent the e-mail, and the machine that received the e-mail, are Window's based PC's. I do not know what the sending machine was using for an Operating System or e-mail program, but I should know early this week (February 12-14, 2008) what the receiving computer used for an OS and e-mail program.
Okay, because most administrators don't artificially change header information, you can indeed technically determine what IP address a message came from, what time it hit each server, etc., but when you invoke the word "legally" like you did ("can the information... legally prove who sent it?"), then that's a whole level beyond the technical. I don't know what the standard of "proof" is in a court of law to determine where a message came from, but given the fact that headers can indeed be changed/forged/screwed with, then I'd be hard pressed to belive that they by themselves without the context of what servers it went through would be considered "proof". It's not even considered absolutely definitive proof of origin in a technical sense because of the possibility of forging, so I'd fall over in shock if headers by themselves were ever taken as legally definitive proof of origin.
But, to abuse a web acronym: IANAL. This is only my personal opinion.
Now, if you had headers that also matched SMTP logs from each step along the way, and if you can establish that the SMTP logs were not forged or manipulated (how, I have no idea, I'm merely discussing an ideal...) then I think you're a lot closer to technically proving origin. But again, legal proof, is a whole different level that I simply cannot speak to. And to add to the bad news: Good luck with convincing an ISP to part with its SMTP log; some mail administrators refuse to keep beyond a certain number of days worth of logs, and while space is normally cited as the issue, the reality is that some absolutely do not want to get embroiled in a legal case and have their records subpoenaed. I've heard that from the mouth of some ISP administrators ("They can't subpoena what we don't have"), and heard others allude to it.
So, I'm sorry I took so many words to not answer your question :o, but the information here may be useful towards finding your answer. May. The obvious answer, of course, is to consult with a lawyer :D, but it doesn't hurt to throw the answers out to geeky folks like myself :eek:;) just to get a sense of what's involved, even if it cannot be a truly definitive answer. Anyway, hope that helps a little! Good luck!
Complexity
12th February 2008, 09:18 PM
I'm curious, Ernie M.
What are you up to?
ddt
13th February 2008, 04:00 AM
Can the information contained in an expanded view of an e-mail header legally prove who sent it? And, can that information legally verify what day and time the e-mail was sent?
As others already commented, all headers can be forged. The "Received:" headers, if not forged, give the trail the email has been following. To really ascertain that trail, you need the logs of all intermediate machines.
I know I might need to provide you with more particulars, but for starters, assume that the machine that sent the e-mail, and the machine that received the e-mail, are Window's based PC's. I do not know what the sending machine was using for an Operating System or e-mail program, but I should know early this week (February 12-14, 2008) what the receiving computer used for an OS and e-mail program.
The sending and receiving machine are not relevant to this; only the intermediate machines. Say, in the scenario that an individual P at home sends an email to another individual Q at home: P's computer will send the email with SMTP to the SMTP-server A of his ISP. A will include the first "Received" header and log it. A will then send it on to another SMTP-server B which is closer to the recipient; B will then add a second "Received" header and log it too. B will then send it to the SMTP-server C of Q's ISP. C adds another "Received" header and logs too, and sends it to the POP-server of the same ISP, which adds another "Received" header and logs it too. Now when Q wants to get his mail, he contacts this POP-server and downloads the email as is.
In the above, SMTP is the protocol for sending email along; POP is a protocol for downloading email from a machine which only receives the emails and stores them for retrieval by the clients.
In the above scenario, I included one intermediate machine B - there may be lots of them, there may be none. In the olden days, email was commonly routed through intermediate machines. Nowadays, most ISP's configure their SMTP-servers to not accept such intermediate routing, so "none" is the normal case.
Now note that the logging, and adding "Received" headers, only occurs on the SMTP-servers and POP-servers of the various ISP's, and the actual end machines don't factor into the equation. These servers, BTW, are most commonly Unix/Linux machines, not Windows.
Now, if you had headers that also matched SMTP logs from each step along the way, and if you can establish that the SMTP logs were not forged or manipulated (how, I have no idea, I'm merely discussing an ideal...) then I think you're a lot closer to technically proving origin.
I don't think any ISP has any inclination towards tampering with their logs, apart from the legal issues that might arise from that.
But again, legal proof, is a whole different level that I simply cannot speak to. And to add to the bad news: Good luck with convincing an ISP to part with its SMTP log; some mail administrators refuse to keep beyond a certain number of days worth of logs, and while space is normally cited as the issue, the reality is that some absolutely do not want to get embroiled in a legal case and have their records subpoenaed. I've heard that from the mouth of some ISP administrators ("They can't subpoena what we don't have"), and heard others allude to it.
It depends where you live. The EU has passed a directive one or two years ago that says these logs have to be retained at least 6 months. Netherlands passed legislation with an even longer duration.
ETA: And yes, the European ISP's were not happy about this. Some Dutch ISP's even plan to go to court against the state asking for reimbursement of the costs involved.
iantresman
16th February 2008, 06:02 AM
No.
Unalienable
16th February 2008, 06:32 AM
Usually it can be determined which IP address really sent the message. Each server that handles the email (and there are often many of them) will tack its information onto the audit trail, including the very first one that handled it.
What spammers, hackers, etc. do, is this: they obfuscate the digital trail by launching an email which appears to already have been handled by several servers. That way their IP shows up in the middle, and not at the beginning like it's supposed to be. But with some research you can discover where the audit trail starts making sense, and presume that everything before that is subterfuge.
There are more sophisticated ways to hide your identity through email for which this technique would not be applicable, but for run of the mill spammers it's very reliable.
© 2001-2009, James Randi Educational Foundation. All Rights Reserved.
vBulletin® v3.7.5, Copyright ©2000-2010, Jelsoft Enterprises Ltd.