And if people think the oil companies are bad, why would the oil companies want to see this passed?

People act like this is the end of the world, especially those who will reap serious money from it.

If it is that important can we get access to all of the data, and take the time to just confirm what the hell is happening here?

This tax is going to snowball and hit the end user right in the paycheck, and I just don't think that most people can shell out much more in taxes right now.

Shouldn't we look at major incentives instead?

The track record of the people making these decisions isn't very good, shouldn't they have all of the good information that they can possibly get?

What reason do we have to believe that this isn't going to be like every other cluster f*ck incompetent bureaucrats have foisted on/upon us?

I've never seen so many, so eager to get royally reamed in my life.

"Well, let's see, the fact is, what we are talking about is a global transaction ," she said, "something that we would do in conjunction with other G nations, whether it is G8, G20, whatever the current G number is. Because it is really a source of revenue that has really minimal impact on the transaction, but a tremendous impact on helping us meet our needs."

As has been pointed out to me, the filenames are Unix epoch timestamps. (Like, duh, Lance.) This invalidates certain parts of my analysis, but doesn't in any way invalidate my conclusions.

The point of the original information was to provide more circumstantial evidence pointing to the location of the email archives. The fact that the emails are named with epoch timestamps that relate to the creation date of the emails actually enhances this point.

You definitely do not want multiple machines naming files based on a Unix timestamp. It has to be a single machine because the opportunity for overwriting a file is simply too great.

I've shown that the emails were collected from the servers rather than from the users accounts and workstations, but I haven't shown which servers were doing the collection. There are two options, the mail gateway or the departmental mail servers.

As has been pointed out to me, the filenames are Unix epoch timestamps. (Like, duh, Lance.) This invalidates certain parts of my analysis, but doesn't in any way invalidate my conclusions.

The point of the original information was to provide more circumstantial evidence pointing to the location of the email archives. The fact that the emails are named with epoch timestamps that relate to the creation date of the emails actually enhances this point.

You definitely do not want multiple machines naming files based on a Unix timestamp. It has to be a single machine because the opportunity for overwriting a file is simply too great.

As demonstrated above, I believe that the numbers of the filenames correspond to the order that the emails were archived. If so, the numbers that are missing, represent other emails not captured in FOIA2009.zip.

I wrote a short Bash program³ to calculate the variances between the numbering system of the email filenames. The result is staggering, that's a lot of email outside of what was released. Here's a graph of the variances in order as well as a graph with the variances numerically sorted . Graph info down below.

The first graph is a little hard to read, but that's mostly because the first variance is 8,805,971. To see a little better, just lop off the first variance and rerun gnuplot. For simplicity, that graph is here. The mean of the variances is 402839.36 so the average amount of emails between each released email is 402,839. While not really applicable, but useful, the standard deviation is 736228.56 and you can visualize that from the second graph.

I realize that variance without reference is useless, in this instance the number of days between emails. Here is a grep of the emails with their dates of origin.

I do not see the administrators copying the email at the departmental level, but rather at the mail gateway level. This is logical for a few reasons:

• The machine name ueams2.uea.ac.uk implies that there are other departmental mail servers with the names like ueams1.uea.ac.uk, (or even ueams.uea.ac.uk), maybe a ueams3.uea.ac.uk. If true, then you would need to copy email from at least one other server with the same scripts. This duplication of effort is non-elegant.
• There is a second machine that you have to copy emails from and that is the MS Exchange server so you would need a third set of scripts to create a copy of email. Again, this would be unlike an Administrator.
• Departmental machines can be outside the purview of Administration staff or allow non-Administrative staff access. This is not where you want to be placing copies of emails for the purposes of Institutional protection.
• As shown with the email number variances, and if they are representative of the email number as it passed through UEA's email systems, that's a lot of emails from a departmental mail server and more like an institutional mail gateway.
• As the emails have been shown to be directly related to the Unix epoch, it seems certain that a single machine was responsible for naming the files. Having multiple servers writing files out with a filename based on a timestamp will certainly overwrite some files at some point.

So given the assumptions listed above, the hacker would have to have access to the gateway mail server and/or the Administration file server where the emails were archived. This machine would most likely be an Administrative file server. It would not be optimal for an Administrator to clutter up a production server open to the Internet with sensitive archives.