SherwoodHosting Web and Email Hosting - RFC 822 May help explain source of spam

The message header is a log of hops that the email message went through to get from the sender to the recipient- at each server or gateway, a timestamp and other information is listed. The email message header is buried within the mail message format and is not usually readily visible. The mail message header is lost if a message is forwarded (and replaced by the current email transactions), thus if you're trying to let someone else view the message header, you'll need to find it and cut and paste the header (gibberish to most folks!) back into an email message that you send.

For instance in Outlook, open the message (not in the preview pane), View> Options>
And look in the bottom section called "internet headers"
(Finding this in outlook is not all that obvious! "View> Message Header>" is something different, it toggles displaying the From/To/Subj information in your message window. Options is what contains the "internet header" which is more commonly known as the message header.)
This text is selectable live text that you can copy and then paste afresh into a new mail message in order to forward the header information to your tech support person.

Product: Spamnet for Outlook & Outlook Express ($40, PC only) - Once someone in the spamnet community says a particular source of email is spam, then it's blocked for everyone. "Blocked" means outlook moves it to your SPAM folder where you could retrieve a message filtered in error. No subscription involved.

Product: Inboxer plugin for Outlook ($30) When you declare an email source to be spam, all further emails of that nature are placed into the SPAM folder in Outlook.

Note the above are client-side filters and would not filter spam at the server. These do nothing about viruses, that's a separate topic.
We have not tried these products nor endorse them, they just look interesting.

Here are the headers that are defined by RFC 822:
(see bottom for how to parse the header for spam origins)

FROM / RESENT-FROM
This identifies the person, system, or process that originated the message. If this field does not contain this information, use the SENDER field. If it does, then using the SENDER field is both redundant and optional. In either case, the field must contain machine usable addresses, and not lists or groups.

SENDER / RESENT-SENDER
This field is used to indicate the author of the message, and is optional if the information is the same as the FROM field. However, in cases when then sender did not author the message, or to identify the author as an individual member of a group, then this field should be used. When the SENDER field is needed, it should specify the name of the author, rather than the mailbox from which it was sent. An example for using the SENDER field would be if a secretary sent email for his supervisor. The supervisor would be identified in the FROM field, and the secretary would be identified in the SENDER field.

REPLY-TO / RESENT-REPLY-TO
This field identifies the mailbox(es) to which replies should be sent. This field differs from the RETURN-PATH field (discussed below) in that the REPLY-TO field directs replies to a particular mailbox, and the RETURN-PATH is used by Mail Transfer Agents (MTAs) to identify a path back to the message originator. If the REPLY-TO field is not present, the reply address defaults to the address in the FROM field.

CC / RESENT-CC
This field identifies the secondary recipient(s) of the message.

BCC / RESENT-BCC
This field specifies additional recipient(s) of the message, but the information in this field is not included in the message copy that is sent to the primary and secondary recipient(s). RFC 822 does not specify whether the contents of the BCC field appear in the message copy sent to any other recipients included in the BCC field.

Note that the RESENT- fields are used when a message is forwarded, and refer to the original recipient of the message. In other words, the FROM field identifies the author of the message, and the RESENT-FROM field identifies the recipient that forwarded it.

Trace fields
This information is used to provide an audit trail, and a route back to the sender. Check The Network Information Center, SRI International, Menlo Park, CA for the current list of known values registered for use with "via" and "with". See the discussion of the RECEIVED field below.

RETURN-PATH:
Used by the final MTA to identify the path back to the message originator.

RECEIVED:
This is a dynamic field used by the MTAs to record the path taken to deliver the message. Each MTA adds to this field as the message traverses its path to the recipient(s). The field can contain both the sending and receiving hosts, as well as the time the message was received. Details such as the physical components (using "via"), and protocols ("with") may be included. If the address is expanded or reinterpreted, such as expanding a group list, then "for" may also be included.

MESSAGE-ID / RESENT-MESSAGE-ID:
Identifies a particular version of a particular message, and is guaranteed to be unique by the host that generates it. If additional revisions of the message are created, they will receive another, unique, ID.

IN-REPLY-TO:
Identifies the correspondence to which the current message replies.

REFERENCES:
If the message references other correspondence, the references would appear here.

COMMENTS:
This field allows comments to be added to a message without altering the original message.

ENCRYPTED:
The two <word> parameters of this field are used to identify the software that encrypted the body and, optionally, to help the recipient to select the proper decryption key. Note that headers must remain accessible to the MTAs that use the information to relay the message. Therefore, header information is never encrypted. Care must be taken if the headers contain addresses or SUBJECT lines that include sensitive information.

EXTENSION-FIELD:
This field is used for any extension field registered with The Network Information Center. The names of any extension will never begin with "X-".

USER-DEFINED-FIELDS:
This field may be used to define additional headers for individual users. All user-defined information must begin with "X-", to distinguish it from standardized extension field names registered with The Network Information Center.

As a mail server processes a message, it adds a special line, the Received: line to the message's header. The Received: line contains, most interestingly,

the server name and IP address of the machine the server received the message from and the name of the mail server itself.

The Received: line is always inserted at the top of the message headers.

If we want to reconstruct an email's journey from sender to recipient we also start at the topmost Received: line (why we do this will become apparent in a moment) and walk our way down until we have arrived at the last one, which is where the email originated.

Received: Line Forging
Spammers know that we will apply exactly this procedure to uncover their whereabouts. To fool us, they may insert forged Received: lines that point to somebody else sending the message.

Since every mail server will always put its Received: line at the top, the spammers' forged headers can only be at the bottom of the Received: line chain. This is why we start our analysis at the top and don't just derive the point where an email originated from the first Received: line (at the bottom).

How to Tell a Forged Received: Header Line
The forged Received: lines inserted by spammers to fool us will look like all the other Received: lines (unless they make an obvious mistake, of course). By itself, you can't tell a forged Received: line from a genuine one.

This is where one distinct feature of Received: lines comes into play. As we've noted above, every server will not only note who it is but also where it got the message from (in IP address form).

We simply compare who a server claims to be with what the server one notch up in the chain says it really is. If the two don't match, the earlier Received: line has been forged.

In this case, the origin of the email is what the server immediately after the forged Received: line must say about whom it got the message from.