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.
...headers...
Content-Type: multipart/alternative; boundary="=_alternative 0064BB1E85257A3F_="
X-assessedcontent:true
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_=
