Reader to Reader - 28 Apr 2000

Greg Shultz troubleshoots mysterious UUencoded messages and finds the solution in the message header.

Readers

April 28, 2000

2 Min Read
ITPro Today logo in a gray background | ITPro Today

[Editor's Note: Email your Exchange Server and Outlook solutions (400 words maximum) to R2R at [email protected]. Please include your phone number. We edit submissions for style, grammar, and length. If we print your contribution, you'll get $100.]

When a client sold one of its business divisions, the company had to split its Exchange organization. After the split, the Help desk of the sold division received calls from users who said they were receiving UUencoded messages like the one in Figure 1. These messages were coming from UNIX workstations running Sun Microsystems' MailTool and were routed through a Sendmail server. After the split, the client added a new Sendmail gateway for the newly independent company.

I investigated and concluded that the MailTool software was converting the UUencoded messages to a partial MIME format (even though MIME version headers weren't present), resulting in this type of message. After testing all servers in the organization's four sites, I found that half the servers properly converted the attachments. The Internet Mail Service (IMS) properties on all servers revealed that they had similar configurations.

Because the message conversion was OK before the split, I reasoned that the client hadn't configured the new Sendmail gateway properly. The Sendmail gurus acknowledged that the problem might be a Sendmail problem, but they were unaware of a workaround.

I found a fix for this problem within Windows NT. You need to add the HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesMSExchangeIS ParametersSystemInternetContentContentTypeEQMimeVer Registry value. The data type is REG_DWORD, and you need to set a value of 0 to force the IMS to treat messages with partial MIME headers as non-MIME messages. This operation lets Exchange properly convert the UUencoded attachment. The default value—1—causes the IMS to treat the message as a MIME message, even if the MIME version header is missing. The servers that were handling such messages properly had the correct Registry value, but the servers unable to decode the attachments were missing the ContentTypeEQMimeVer value. After I added the new Registry entry to the malfunctioning servers and restarted the servers' IMS, subsequent monitoring confirmed the solution.

—Greg Shultz
[email protected]

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like