Q:

What information can be gained from an Email Header?

What information is present in an Email Header that can be used to track a sent mail? For example, are some of these present?

Web Browser used?
Operating system
Type of Network (broadband/dial up)?
Type of system Laptop/Desktop etc.

A:

The RFC 5322 defines what email message headers should look like, and some of the required ones like From, Date, and Message-ID. Most email headers are actually optional and appended to the message by the client and email relays for traceability, usability, and debugging purposes. The email message can contain any number of the 350+ recognized ones. It can also contain any number of custom headers.
Nothing stops Hotmail, GMail, or others from appending the browser's user-agent field to the email headers. Nothing stops Thunderbird from appending your connection type and details about your operating system. However, currently, email clients (web-based or desktop) don't append such information to the email message headers. We're also not aware of web-based email services appending information they have on you to the email message headers.

A:

Some of the most useful headers are:

User-Agent
usually reveals client MUA and version, often OS and architecture
Received
all sorts of things, overall you get to see (most of) the store-and-forward hops, but within each such header you can see:

IP addressing, possibly determine IPv6 support
system name, hostnames and internal domain name, possibly deduce naming conventions, deduce use of DHCP
possibly deduce MTA software on each hop (based on Received header format, queue identifiers and format)
local time and time zones, possibly per-hop delays
TLS support (per-hop)
SMTP AUTH user name or client-cert use (likely first hop only)
the first (closest to the end of the headers) Received usually indicates the client that originated the SMTP message, in the past I've used a regex on the reverse DNS name added by sendmail to tag potential DSL/domestic naming conventions: (dsl|dial|ppp|dyn|user|modem|cable|catv|dhcp|pool|node|cust)

Message-ID if MUA generated it may reveal MUA details, and may contain host identifying information. If added by the first hop it may reveal MTA details. This field is intended to uniquely identify a specific message.
Return-Path the envelope sender, may indicate attempted forgery
X- headers often reveal scanning, anti-virus, anti-spam components; TLS support. 
Many systems (including MS-Exchange) add X-Originating-IP. Hotmail adds an "obscured" X-EIP (evidently a source of much excitement).

After the Received headers, the X- headers are likely the most informative, but system specific and not always well defined, or documented (by their nature).
However, your question is phrased so that you are most likely talking about webmail originated messages. Browser+webmail is of course not an SMTP based MUA, the construction of the SMTP message happens server-side (the webmail software in effect becoming the email client). There's a further complication here too: a HTTP proxy may hide the client from the webmail server (analogous to an open SMTP relay).
It's up to the webmail provider as to how much client detail (usually very little) is included in the headers, the client (browser) IP is not typically included. Gmail say it might be there, I've observed that it's not for web mail, but it is for SMTP submitted mail, and see this discussion: Email headers from messages sent via Gmail online client contain private IP addresses. What are these addresses? . Hotmail obscures it (see above)
For the four specific items you ask about: you might get the IP, and hence the whois/reverse-DNS, which should tell you something about the source network. The other items, no, not for webmail.
See this for some discussion of IP addresses in headers: Email header IP address
The webmail provider will (in theory) be able to track an email in their own logs, using one or more of the Message-ID, the queue/spool ID (recorded in Received), or a custom message identifier (possibly in an X- header). 
It's also worth remembering that SMTP is a fairly loose protocol, any "synthetic" headers injected by a sender (or malicious server) are dutifully passed on. Systems such as DKIM allow at least testing the authenticity and integrity of some headers.

