By Nelson Banya
Update via SW Radio Africa.
Defence lawyer Beatrice Mtetwa argued the emails were ‘fake,’ and moved to show the court how easy it is to create emails as though they were coming from a particular email address.
Hitschmann, various MDC officials, including Giles Mutsekwa, who is now the MDC co-Home Affairs Minister, and some police officers were arrested in 2006 in connection with this case but were acquitted. However Bennett is still facing the same charges of attempting to commit acts of banditry and terrorism.
Last week the judge said Hitschmann’s confessions implicating Bennett were invalid, after the state’s star witness said he had been tortured into linking Bennett to the crime. But in his ruling on Wednesday the judge said the emails were allegedly sent before Hitschmann’s torture and therefore could not be tainted by the alleged abuse suffered by the firearms dealer. Justice Bhunu therefore ruled that the disputed emails are admitted as evidence.
The defence lawyer then produced some ‘fake emails’ during the cross examination of State witness Precious Matare, to show the court how easy it is for anyone to hack into an email address and send emails from that address.
One of the false emails used by the defence to prove this point implicated the Attorney General Johannes Tomana, who is also the prosecutor in the Bennett case. When Matare began reading the fake email, the Attorney General quickly jumped up to oppose and to block the defence’s line of argument. Tomana argued that it was inappropriate to ‘caricature’ the person of the Attorney General in these proceedings.
Observers in court said it was pretty clear that Tomana saw that this kind of evidence would be damaging to his case and likely make a fatal flaw in his argument. Mtetwa maintained she was attempting to demonstrate that the alleged emails between her client and Hitschmann could have been produced by anyone.
The High Court judge adjourned the hearing to Monday where he is expected to make a ruling on whether the defence can continue to show the fake emails.
HARARE – Zimbabwe’s High Court on Wednesday admitted disputed email evidence implicating opposition politician Roy Bennett in a plot against President Robert Mugabe’s government.
Bennett, a white farmer and a senior official in Prime Minister Morgan Tsvangirai’s Movement for Democratic Change (MDC), faces a possible death penalty if convicted of illegal possession of arms for “terrorism, banditry and sabotage”.
Defence lawyers had asked the court to reject emails linking Bennett to the alleged crime, arguing that they had been doctored and that a key state witness, Peter Hitschmann, who is alleged to have conspired with Bennett, disowned them.
The court had previously thrown out confessions by Hitschmann linking Bennett to the crime, on the grounds that the statements had been extracted under torture.
High Court judge Chinembiri Bhunu ruled that the emails were created before Hitschmann’s alleged assault.
“The emails cannot be tainted by the alleged abuse suffered by Hitschmann,” Bhunu said.
“They are relevant and vital to the fair resolution of the case and are hereby admitted as evidence.”
The arrest and trial of Bennett, MDC nominee for deputy agriculture minister in a government set up by Mugabe and Tsvangirai, has raised tensions in the power-sharing administration.
The state charges Bennett with funding a 2006 plot to blow up a major communication link in the country and assassinate key government figures. He is accused of having deposited funds in Hitschmann’s Mozambican account for the operation.
Bennett denies the charges, which he says are politically motivated. Hitschmann, an arms trader and key state witness who faced the same charges but was convicted in 2006 on a lesser charge of possessing dangerous weapons, has absolved Bennett.
Editors Note:
This explanation of an Emails “Header” Data is courtesy of one of our readers. (M.Mugabe).
The complete headers provide much information on the origin of a message and are a useful tool for tracking and stopping SPAM and virus-laden e-mail. Most e-mail readers only show the To: and From: headers, which can be easily forged. The complete message headers will look something like this:
Return-Path: [fake@address.com]
Received: from server.mymailhost.com (mail.mymailhost.com [126.43.75.123])
by pilot01.cl.msu.edu (8.10.2/8.10.2) with ESMTP id NAA23597;
Fri, 12 Jul 2002 16:11:20 -0400 (EDT)
Received: from aol.com (127-34-56-98.dsl.mybigisp.com [127.34.56.98])
by server.mymailhost.com; Fri, 12 Jul 2002 13:09:38 -0700 (PDT)
Date: Fri, 12 Jul 2002 13:09:38 -0700 (PDT)
From: Hot Summer Deals
To: My.Friends@pilot.msu.edu
Subject: Just what you’ve been waiting for!!
In particular, the header lines beginning with Received: provide a trace of the message from its origin to your mail server. In many cases with spam and virus e-mail, not all of the information in the “Received:” headers can be trusted, but it can still provide many valuable clues as to the message source.
The first step in the analysis process is to find the full e-mail headers. The method for doing so varies depending on your mail reader. Consult the document Finding full e-mail headers for details.
What not to trust in mail headers
The above example is contrived, but illustrates several of the aspects of common forged e-mail headers. Of course, you may be lucky enough to have received a message from a verifiable source; if so, you will find some consistency to the results seen when analyzing the headers.
In the above example, the following headers are contrived by the sender’s system:
To: My.Friends@pilot.msu.edu
The contents of the To: header can be arbitrary. There is no account “My.Friends” at MSU. The true recipients of a message are determined by the e-mail “envelope” address, which is not displayed in these headers.
From: Hot Summer Deals
Likewise, the sender’s name is arbitrary. There may or may not be an account named “hot_deals” at AOL, and the sender may not be the valid owner of the account if it does exist.
Analyzing the “Received:” headers
The most useful clues to a message’s origin come from the headers that begin with Received:. Each mail server which handles an e-mail message adds a Received: header set to the front of the message; the first set is therefore added by your mail server. For this example, we’re assuming you read e-mail delivered to MSU’s Pilot e-mail system.
Let’s start with the first header:
Received: from server.mymailhost.com (mail.mymailhost.com [126.43.75.123])
by pilot01.cl.msu.edu (8.10.2/8.10.2) with ESMTP id NAA23597;
Fri, 12 Jul 2002 16:11:20 -0400 (EDT)
In this header, you see that the message was received by a Pilot mail server (pilot01.cl.msu.edu); the remainder of this line contains version information and the message id assigned by the Pilot mail server. The time stamp shows when the message was delivered to Pilot.
The first line shows three important pieces:
Mail server IP address: 126.43.75.123
This is the Internet IP address from which Pilot received the message.
Mail server domain name: mail.mymailhost.com
This is the domain name (DNS name) which matches the above IP address.
Mail server identification: server.mymailhost.com
This is what the server claimed its name to be. This may or may not agree with the domain name; a mail server may have more than one identity.
The second header gives more clues:
Received: from aol.com (127-34-56-98.dsl.mybigisp.com [127.34.56.98])
by server.mymailhost.com; Fri, 12 Jul 2002 13:09:38 -0700 (PDT)
In this header, the receiving mail server name (server.mymailhost.com) matches the name shown in the first header (so far so good). The first line of this header reveals the source:
Originating IP address: 127.34.56.98
This is the Internet IP address from which the remote mail server received the message.
Originating domain name: 127-34-56-98.dsl.mybigisp.com
This is the domain name (DNS name) which matches the above IP address. This reveals that the IP address may be owned by an organization known as “mybigisp.com”. This would appear to be a high-speed DSL subscriber to mybigisp.com, but only that organization can tell you for certain.
Originating system identification: aol.com
This is what the originator claimed its name to be. In this case, the sender is claiming to be “aol.com”, but the source IP address and domain name do not fit.
From these headers, the most reliable identification of the message source is the sender’s IP address, 127.34.56.98. A number of tools are available for verifying the owner of an IP address. The authoritative reference for IP addresses is the American Registry of Internet Numbers. Using ARIN’s “Search WHOIS” tool (or one of the other tools), you can find the identification of the IP address owner. In most instances, a message to “abuse@organization” will do the trick; be sure to include the message with its complete headers.
Note that there may be additional Received: headers that were generated by the originator of the “spam” e-mail (or by a mail virus). In general, you can only trust the “Received:” headers as far as you can verify them. If you are uncertain about their authenticity, you should go with the last one which is verifiable.
Thanks for this M Mugabe. Very Informative. (Editor)
Recent Comments