Return-Path: <matt@berkeley.example.org>
The Return-Path indicates the real sender of the email. This is (by default) where replies go, including bounced messages indicating a problem delivering the mail.
Received: (qmail 22143 invoked from network); 31 Mar 2004 19:38:43 -0000
Received: from unknown (HELO nat.example.com) (67.85.216.139) by 10.8.4.66 with SMTP; 31 Mar 2004 19:38:43 -0000
Received-SPF: pass (10.8.4.66: SPF record at example.com designates 67.85.216.139 as permitted sender)
Received: from matt by nat.example.com with local (Exim 3.36 #1 (Debian)) id 1B8lXu-00050d-00 for <matt@example.org>; Wed, 31 Mar 2004 14:38:42 -0500
The Received headers indicate the path the message took to arrive. When a message gets forwarded through a new system, it adds it's header on top of the others, hence the first mail server is at the bottom, the next right above it and so on.
In this case, 'matt' was a local user to nat.example.com. Matt submitted the message locally to nat.example.com, intending for it to go to matt@example.org. nat.example.com accepted the message and forwarded it to the final host at 10.8.4.66
The Received-SPF header indicates that the message was sent by a valid mail server for the domain, and is not likely to have been forged by a spammer.
Below we have an alternate series of headers. Please realize that a real message would not have both sets.
Received: (qmail 26820 invoked from network); 1 Apr 2004 16:19:30 -0000
Received: from unknown (HELO cliff.cs.example.edu) (128.213.1.9) by 10.8.4.66 with AES256-SHA encrypted SMTP; 1 Apr 2004 16:19:30 -0000
Received-SPF: none (10.8.4.66: domain at cs.example.edu does not designate permitted sender hosts)
cs.example.edu does not advertise the correct identity of its outgoing mail servers which allows spammers to pretend to be from this domain. This allows for so called 'joe-jobs' which result in lots of bounced messages and angry replies going back to cs.example.edu from a spam sent by spammer@spamhappy.biz
Received: from egg.cs.example.edu (egg.cs.example.edu [128.213.7.24]) by cliffclavin.cs.example.edu (8.12.10/8.12.10) with ESMTP id i31GJTn7070365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <target@example.org>; Thu, 1 Apr 2004 11:19:29 -0500 (EST)
SMTP has the option of encrypting the conversation. This means that the only people who can see the message are those on the server it is going through. Unfortunately, most servers don't support encryption, and even when they do, it means that more than just the sender and recipient see the message. Here, the conversation is encrypted with a 256-bit cipher.
Received: from egg.cs.example.edu (localhost [127.0.0.1]) by egg.cs.example.edu (8.12.9/8.12.6) with ESMTP id i31GJSbj026545 for <target@example.org>; Thu, 1 Apr 2004 11:19:28 -0500 (EST) (envelope-from sender@egg.cs.example.edu)
Received: from localhost (sender@localhost) by egg.cs.example.edu (8.12.9/8.12.6/Submit) with ESMTP id i31GJQOg026540 for <matt@example.org>; Thu, 1 Apr 2004 11:19:28 -0500 (EST) (envelope-from sender@cs.example.edu)
Date: Wed, 31 Mar 2004 14:38:34 -0500
From: Matthew Wronka <matt@example.org>
To: example@nonce.matt.example.org
Subject: Example signed Message
Message-Id: <20040401181054.GA27170@example.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="WIyZ46R2i8wDzkSu"
Content-Disposition: inline
This means that the message will be in multiple parts, including a part that proves the authenticity of the sender, and that this part of the message should be shown 'inline', i.e. not as an attachment.
User-Agent: Mutt/1.4.2.1i
X-Website: http://matt.example.org/
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
berkeley.matt.example.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60
Content-Length: 711
Any header beginning with an 'X-' is a non-standard header. These can be added by any computer the message passes through. Here the sender has put his website as a header. The message has also been checked for spam.
--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
This is a signed message part. You can read it, but not change it.
Good bye.
--Matt
--=20
Matthew Wronka <matt@example.org> http://matt.wronka.org/pgp/pgp.key
I speak only for myself. Below courtesy of /usr/bin/fortune:
That secret you've been guarding, isn't.
Here we see the first part, which consists of a plaintext message. the use of 'sig-dashes' or '-- ' (note the space) is used to distinguish the senders sig from the rest of the message. The trailing space is converted to the hexadecimal value of '20' by the mail client.
--WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature
Content-Disposition: inline
This is the second part of the message, and we see that this is supposed to be displayed inlnie again (not as an attachment) and is a signature that verifies who sent the first part of the message.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAbFsu8BY3YCq5Ky8RAi0EAJ4ti8OU2WTK4woqoU4yWQ3acYKx+wCfWgRc
z1IuXhJe7phrbtmDM+M7A/k=
=j+OO
-----END PGP SIGNATURE-----
The part between the BEGIN ... END lines is a one-way-hash of the messge above. It's used by PGP/GPG to prove who sent the above portion. It is improbable that this could be faked, and even the slightest change above causes major changes in this hash.
--WIyZ46R2i8wDzkSu--
As you might have noticed above, this line distinguishes the boundaries between the different parts of the message. It cannot appear anywhere else in the message or its sub-parts, except in this role.
--