0

In the process of troubleshooting an email message display issue, I noticed that an email header contained HTML.

Example:

From: <bob@foo.com>
To: <john@foo2.com>
Date: 11 Feb 13 12:00:23
Subject: Foo Test
Message: <html><head><meta http-equiv="Content-Language" content="en-us"
         <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
         <title>Foo Test 123</title><body>Hi
Message-ID: <slkdsjflksdjflkslsjldkfjlsd-sldkfjslkdjfl@foo.com>

The message header is added by an upstream server that I don't manage. The original issue I was seeing was that the HTML text in the header was missing a tag so the email reader thought that the rest of the message (including other headers) were part of the message body (which resulted in the mime source showing up in the body instead of the rendered HTML.

This seems definitely wrong to me - I can't imagine any scenario where having HTML in the headers itself would be helpful. That said, I can't seem to find the section in the RFCs that explicitly define what can (or cannot) be in headers. Can someone point me in the right direction?

Specifically I want to know: Are there any restrictions on what type of content can be placed in email headers and what type of characters can be specified in header names/values?

Mike B
  • 11,871
  • 42
  • 107
  • 168

3 Answers3

1

Where does the "Message" header come from? Does the message contain a body or did that somehow get stuffed into the "Message" header? "Message" isn't a standard IMF header defined in RFC 5322 and it isn't in IANA's permanent or provisional lists. There might be a mail reader somewhere that interprets it, but for the most part "Message:" may as well read "X-this-will-likely-be-ignored:"

Gerald Combs
  • 6,441
  • 25
  • 35
0

There are very few restrictions on what can be placed in the header. rfc5322 section-2.2 only says that the header field name has to be printable characters. As long as that is true and the content is "folded" correctly, you CAN put most anything in the headers.

I've also seen headers being incorrectly rendered as body if the encoding is incorrect and there ends up being an blank line transmitted so that the client thinks the body is starting, so you can check for encoding to make sure that it isn't the culprit.

I think that Gerald is correct however in that you might want to ask less of if the message format is legal and more of who and why somebody is adding this to the header.

MxToolbox
  • 1
  • 1
-3

This is not HTML, but is instead the method described by RFC 822 (section 3.4.6) for delimiting mailboxes. The pertinent section reads as follows:

There are three types of brackets which must occur in matched
pairs, and which may NOT be nested:
o Colon/semi-colon (":" and ";") are   used  in  address
  specifications  to  indicate that the included list of
  addresses are to be treated as a group.
o Angle brackets ("<" and ">")  are  generally  used  to
  indicate  the  presence of a one machine-usable refer-
  ence (e.g., delimiting mailboxes), possibly  including
  source-routing to the machine.

It is also explained in section 6.1 (Syntax) as follows:

mailbox     =  addr-spec                    ; simple address
            /  phrase route-addr            ; name & addr-spec
route-addr  =  "<" [route] addr-spec ">"

Mainly, this is used to allow for clear-text display of a person's name, as well as their email address, such as

John Doe <jdoe@somewhere.com>

which, in the example you gave, the name is given as blank, followed by the email address.

  • Uh, did you not see the `Message: – ceejayoz Mar 11 '13 at 16:46
  • I was addressing the [IANA Permanent Message Header Fields](http://www.iana.org/assignments/message-headers/message-headers.xml). Message is not a standard field, like Message-context and Message-id, so it may not be parsed by mail clients. (I.e., something akin to expecting Firefox to recognize Internet Explorer-unique HTML markup.) – Steven Foust Mar 11 '13 at 17:16
  • It's very clearly HTML, not a mailbox name. Yes, it's a non-standard header, but that doesn't stop it from being HTML - it just means it's likely ignored by virtually all clients. – ceejayoz Mar 11 '13 at 17:43