The Malformed MIME Dilemma

The company that I work for has an anti-virus gateway. The anti-virus gateway is a server which is positioned between our internal email servers and the outside world. It filters out SPAM emails and viruses while it allows legitimate emails to pass through it to the internal email servers so that they can be delivered to their intended recipients. If the anti-virus gateway cannot fully scan an email for viruses, it filters the email out and often sites “malformed_MIME” as the cause.

Obviously, its this guy’s fault.

MIME stands for Multipurpose Internet Mail Extensions. MIME is used to describe information about the content of an email and how it is formatted. There are standards that determine how a MIME email should be composed. One of these standards is RFC 5322 (formerly RFC 822 and RFC 2822). When an email is created in a fashion that doesn’t comply with RFC 5322, anti-virus software is often unable to effectively scan the entire email for viruses.

The company that I work for receives emails from hundreds of vendors each week. Some of those vendors use custom or specialty software to automatically create emails. The vendor’s email software may not create emails in a way that conforms to RFC 5322. When this happens, the email gets filtered out by my company’s  anti-virus gateway and business is hampered.

Some companies in this situation have decided to allow unscannable emails with malformed MIME types to be delivered normally. This behavior is risky, as the bad guys have found ways to use emails with malformed MIME types to crash email servers and hide viruses in emails so that anti-virus software has a hard time detecting it. It is also common for SPAM to have malformed MIME types. By not blocking emails with malformed MIME types, these companies may be delivering more SPAM to their users as well.

At this time, my organization is still blocking unscannable emails. We are also working with vendors who send us emails with malformed MIME types when they request information to investigate the matter further.

Has this ever been a concern for your organization? What do you think about this issue? Participate in the poll and post a comment!

Further Reading:


How to publish a network share in Citrix XenApp 4.5

Pictured above: A Citrix user who can't find his files.

From time to time, a Citrix user may need convenient access to a shared folder on the network. The easiest way to provide this access is to publish an icon that acts as a shortcut to that specific folder. The problem is that in XenApp, you can’t just publish a share or directory; you have to publish explorer.exe with the specific UNC path to the folder that you want to make available. Creating the icon is simple enough but this article serves as a quick reference for those who may not do this often.

The process:

  1. Open up the Citrix Access Management Console and expand Citrix Resources – XenApp – (Your Farm Name) – Applications.
  2. Right-click on “Applications” and select “New – Publish Application”.
  3. Click on the “Next” button to skip past the welcome screen.
  4. In the field under “Display name:” type in the name of the folder that you are publishing. In the field under “Application description: “ type whatever you like then click on the “Next” button.
  5. Make sure that the radio button next to “Application” under “Choose the type of application to publish.” is selected. The radio button next to “Accessed from a server” under “Application type” should be selected as well. The drop-down box under “Server application type:” should have the “Installed application” option selected. When the settings match the picture below, click on the “Next” button.
  6. In the field under “Command line:” enter “%windir%\explorer.exe “\\UNC\Path\To\Folder”. You can leave the “Working directory:” field blank. Once you have entered in the appropriate information, click on the “Next” button.
  7. Click on the “Add…” button to choose which Citrix server(s) explorer.exe will be available to run on when the user clicks on the icon for the published application (the folder/share that we are publishing). The “Select Servers” dialog box will pop up with a list of the Citrix servers in your farm that you can add to the list of servers to run the application from. When you have completed the list of servers, click on the “OK” button then the “Next” button.
  8. The radio button next to “Allow only configured users” should be selected as well as the “Citrix User Selector” option from the “Select directory type:” drop-down box. Click on the “Add…” button to bring up the “Select Users or Groups” dialog box. From here, you can click on the “Add List of Names… “ button to type in your user’s names manually. You can also put a check mark in the box next to “Show users” then navigate and double-click on the user that you would like to add.  Once you have selected all of the users that you would like to allow access, click on the “OK” button, then click on the “Next” button.
  9. Note: At this point you may get an error message “Failed to read icons from file: %windir%\explorer.exe”. This is okay. Click on the “OK” button.
    From this screen, you can change the icon for the published application, and determine where it will appear for the user. For the sake of brevity, you can accept the defaults and click on the “Next” button.
  10. Click on the Finish” button to publish the application immediately. If you need to fine tune your options, you can always go into the published application’s properties by right-clicking on it in the Citrix Access Management Console and selecting the “Properties” option.

Your newly published application should appear in your Applications folder in the Citrix Access Management Console . The application shortcut should also appear for the users that you allowed access to the published application when they log in to the Citrix environment.


If you have done this from a XenApp 6/6.5 farm, you may notice that when you launch the published share, it immediately disconnects/closes. This can be fixed by adding an entry the registry on the XenApp server. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI and create a new DWORD called LogoffCheckerStartupDelayInSeconds and give it a value of 10.

Further Reading:

Exchange 2007 SP3 Rollup 3 – Unforseen Consequences

Did not see that coming.

If you have installed Rollup 3 on your Exchange 2007 SP3 email server then you might experience the following: When Mac users who send emails with .tiff or .pdf attachments to Windows users, the Windows users won’t be able to view the attachments! Sometimes Windows users who receive the attachment laden email, won’t even see the telltale paperclip symbol on these emails. It is only when the email is viewed from OWA or another Mac client that it’s attachments are made apparent.

Even though the rollup was released in April, Microsoft still hasn’t released a publicly available patch for it. At this time, you’ve got three things that you can do to try and resolve this issue:

  1. Uninstall Rollup3
  2. Call 1-800-microsoft and talk Microsoft support into giving you the hotfix
  3. Entering the following command in power shell on your Exchange server has reportedly helped some people: set-OrganizationConfig -ShowInlineAttachments:$true

Further Reading: