Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

MIME multipart/alternative contains X-header bypasses filter

An email is modified by another product that is scanning and making a qualitative decision on the content of the email. It places its assessment in an X-header which is intended to be caught by an Ironport filter and actions taken such as routing and further message manipulation. The originating system cannot perform all of the policy work and decisions made by Ironport and neither can Ironport make the qualitative decision on the email so these two systems need to cooperate.

The originating system places the X-header inside a mime miltipart/alternative segment. RFC's 2046 and 2821 seem to apply and indicate that a multipart/alternative mime part is allowed to contain headers, but indicate the purpose of doing that is to use character encoding other than US-ASCII. RFC 2046 also hints that the alternative parts are different renderings of the same data. Not the case here where the product has created 1 alternative containing only the header and 2 further parts for text and html rendering.

IRONPORT does not see the X-header in the alternative MIME part. The filter that checks for it does not fire and quarantine representations of the email show only the last two alternative parts.

QUESTION: Can I legitimately say that one of Ironport or other product is not obeying the RFC? 

My impression is that by convention, no system puts X-headers into an alternative MIME part or if so, the headers should be repeated in all of the alternatives as the message body is repeated.

sample of the format.


Content-Type: multipart/alternative; boundary="=_alternative 0064BB1E85257A3F_="


This is a multipart message in MIME format.

=_alternative 0073D36D85257A3D_=

Content-Type: text/plain; charset="US-ASCII"

email message .

Content-Type: text/html; charset="US-ASCII"

email message with html tags

=_alternative 0073D36D85257A3D_=

Everyone's tags (3)
New Member

MIME multipart/alternative contains X-header bypasses filter

Have you tried changing the condition to "Message Body or Attachment?" My guess is that the ESA should pick up on it that way.

I believe that the x-header there ends up being part of the Content-Type declaration but I wouldn't swear to it.

New Member

MIME multipart/alternative contains X-header bypasses filter

Thanks for the input. That sounds like it would catch the content and I'll try it out. It is a more expensive test I'd like to avoid. I'm really wondering which of my vendors is correct on their interpretation. I think the support guy has a case open with Cisco so we'll see how that ends up.

CreatePlease to create content