IronPort and HTML Email

[todd.tucker]

Hello,

We are running into a problem since switching to IronPort email filtering from our Exchange Servers using SMTP.  We have several websites running PHP and using the PHP mail() command to send HTML email directly from applications.  We set the Content-Type: text/html header and send them on through a relay_host and Postfix.  Formerly, these emails were sent and processed correctly to render in an email client.

Since switching to IronPort, our HTML emails now come through as HTML code with a few extra headers listed at the top, one of which is our "Content-Type: text/html" header.  I have noticed, in looking at the raw source of the email, that there is now a "Content-type: text/plain" header which is processed before our html header.  I would imagine this is the source of our issues.

Can anyone help with a setting in IronPort that would make it honor the headers sent with the original email without putting its own Content-Type at the top?


Thanks,
Todd

[Libin Varghese]

Hi Todd,

A common cause for the email headers and html tags to appear in the body of the email would be the headers injected not being in a RFC compliant format or missing parameter within the boundary field.

The IronPort appliance does conform to RFC specifications and should have no issue with headers terminated with CR/LF (\r\n) sequence.

To investigate this issue further, and to review exactly what the email looks like as it's received by the IronPort you could create an injection debug log to record the SMTP conversation. I've included steps to configure this log below:

1) Go to System Administration -> Log Subscriptions -> Add Log Subscription.

2) Choose the following options:
Log Type: Injection Debug Logs
Log Name: Inject
IP Address or Hostname: (IP address of Postfix server)
Number of Injection Sessions: 10

3) Submit the page

4) Commit your changes

5) Wait for example emails to be sent

6) Access your IronPort via FTP and download the log file from the Injection folder

Thanks
Libin Varghese

[todd.tucker]

Thank you for the information, Libin.

We are using the PHP Pear Mail_Mime library and creating HTML email.  I have never found this to be non-compliant with any RFC specification on email.  I can clearly see that, even in a multi-part mime email message, IronPort is inserting a Content-Type: text/plain above each individual part:

Text Portion:

--=_ee124aa6f4d3ba21c25afe238097361b

Content-Type: text/plain

Content-Transfer-Encoding: quoted-printable

Content-Type: text/plain; charset=ISO-8859-1

HTML Portion:

--=_ee124aa6f4d3ba21c25afe238097361b

Content-Type: text/plain

Content-Transfer-Encoding: quoted-printable

Content-Type: text/html; charset=ISO-8859-1

Is there no setting in which this would happen automatically?  I can get a copy of the raw email source as submitted to Postfix if it would help.

It will take quite a while to get all of the admins together and create the debug logging mentioned above, so I'd love another answer, but I will get to work on the above procedure.  Please let me know if there is anything else we can look at in the meantime.

Thanks!

Todd

[todd.tucker]

A ha!

Very odd, but your message from earlier led me to start investigating different EOL settings for Mail_Mime.  I had the standard "\r\n" set for EOL as you mentioned.  I switched it to "\n" for Mail_Mime and now multipart emails come out correctly.  Not sure why this is the case, but it DOES work.  

So, for anyone searching this message on sending email from PHP using Mail_Mime and sending HTML email, this is the setup I use to start a multipart HTML message using the uff-8 character set:

        $mime = new Mail_mime(array('eol' => "\n",

                                    'text_charset' => 'utf-8',

                                    'html_charset' => 'utf-8'

                                   ));

Thanks for your help, Libin!

[Libin Varghese]

I'm glad the information helped.

Libin