Re: what can be trusted in email header?

"hba2pd" wrote in message news:1186043316.728122.155670@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

In my previous posts, I got a following response

Peter Durkee wrote:
How can they fake these email header information?

The To, Cc, Subject, From, and other headers are all specified by the *sender* of the e-mail. The e-mail client can enter whatever headers it wants into an e-mail because those "headers" are NOT headers added by mail servers. Those "headers" are just part of the body of the message sent by the sender. In a message, there is the "header" portion at the top, a blank line delimiter, and the "body" of the message. It is no different than if you opened Notepad, specified whatever headers you wanted at the top, added a blank line, and then the body of your message. All of this is sent in the DATA command sent by the e-mail client to tell the sending mail server what is the content of the message.

The e-mail client displays *fields* within its UI where you enter a list of Recipients. You entering recipients in the To, Cc, and Bcc fields in your e-mail client are not what tells the mail server as to where your e-mail gets delivered. When sending your message, your e-mail client compiles an aggregate list of all recipients from the To, Cc, and Bcc fields, and then it sends a RCPT-TO command to the mail server, one for each recipient. So if you have 10 recipients (say 5 in the To field, 3 in the Cc field, and 2 in the Bcc field), the e-mail client sends 10 RCPT-TO commands to your mail server followed by a single DATA command for the content of your message (which, remember, is the "headers", blank line, and "body" sections of that one document).

In fact, listservers that send out bulk mails have the sender send them the body of their message completely separately of the list of recipients. The sender sends their listserver a list of all recipients which is their mailing list maintained up on the listserver. Later the sender decides what to send as the message and just sends that. The list of recipients is already up on the mail server.

I'm not even sure I'd go so far as to say you can always trust the IP
address.

The only headers you can trust are those that were added by your receiving mail server. If the spammer is operating their own mail server then they can insert whatever delivery headers they want (headers by mail servers get prepended to the message above the "header" section that was already included in the message sent by the DATA command). So the spammer can obviously insert whatever header they want. They can also insert bogus headers by including them in the "header" portion of the message that was sent in the DATA command.

The Received header added by *your* receiving mail server is the only one that can be trusted. Every host knows the IP address of whatever host connects to it. It is a requirement for TCP packets to pass between them to send traffic. The receiving mail host will add its Received header and show the IP address of the host that connected to it. That is the only host identification that may be true in the headers that got prepended to the message.

You can trace backwards through the Received headers. Your receiving mail host's Received header is the topmost one (headers get prepended as the message passes thorugh each mail server although relays may strip out the headers and insert a whole new bunch just for itself). The "by" host is your receiving mail host. The "from" host is who connected to your receiving mail host. The next Received header (top-down) must specify its "by" host is the same as the "from" host in the previous Received header since they are supposed to chain together. Tracing can be complicated since some mail servers will bounce mails within their internal network and not compose full Received headers. If, at some point, the "by" host in the next Received header doesn't match the "from" host in the prior Received header then tracing stop since you probably hit a bogus Received header. That is not an absolute, however. Tracing through headers takes practice and sometimes they just don't make sense, so the only one you can trust is the last prepended Received header that was added by your own receiving mail host.

You could try using SpamCop's parser to see how well it traces through the Received headers but, again, it isn't perfect. Although the RFCs suggest how Received headers should be composed, there are far too many "RECOMMENDED" and "SUGGESTED" conditions within the RFCs to enforce a single format that would be enforced by all mail servers (because receiving mail servers could then reject those without properly formatted Received headers).

If you want help on tracing through e-mail headers, try posting over at the SpamCop newsgroups (you can even use their NNTP server at news.spamcop.net). They may have FAQs to help you out or you can Google on article explaining how to trace through e-mail headers. Even then, it takes practice and sometimes it just isn't worth your time.

The whole e-mail scheme is antiquated based on a very small-sized community when the RFCs were created some 30 years ago. It was based on a trusted model (i.e., senders were trusted primarily because the community of e-mail users was pretty small). The trusted model doesn't work anymore as it has long been abused. There have been attempts to bandaid the trusted model with SPF (but spammers put in fake SPF records in the header in trying to fool recipients that is was validated using SPF) and domain keys (designed by Yahoo and which is flawed; see http://www.bluebottle.com/domainkeys-is-flawed.php). Digital signing was an attempt to identify the sender but then you can get freemail certs from Thawte (now owned by Verisign) that do not identify anyone and only identify the e-mail address to which the cert is registered. Unfortunately there is strong resistance to generating new RFCs that instead assume a non-trusted model for e-mail.

.

Relevant Pages

  • Re: Header manipulation...?
    ... Pac Bell has a very poor reputation. ... or directly from a zombie host on one of their networks. ... Well, without seeing the headers, it's hard to say. ... The first header was put there by the poster's mail server, ...
    (comp.security.firewalls)
  • Re: Returning emails to sender
    ... Outlook has rules to look at only some of the headers (the ones the sender ... which header has that string. ... you could test on ir2.motleyfool.com being in the Received header, ...
    (microsoft.public.outlook.general)
  • Re: How do they blank out IP addresses etc?
    ... ]>>>should be at least one received header in every message. ... Those were the complete headers I ... Your machine is seriously deficient if your MTA ... Sendmail or its ilk receive mail. ...
    (comp.security.misc)
  • Re: How do they blank out IP addresses etc?
    ... >>They were the real headers. ... >should be at least one received header in every message. ... Those were the complete headers I ... Outlook Express using Message Properties, Details, Message Source ...
    (comp.security.misc)
  • Inspecting Received headers
    ... (Exchange Server 2003, Outlook 2003) ... I'm interested in the Received headers in particular, ... We also use an MX host at our ISP as a backup. ... Is there a tool that will help us extract the Received headers, ...
    (microsoft.public.exchange.connectivity)