For the past month or so some of our Groupwise users have been reporting problems sending email attachments. The most common complaints included:
- The recipient could see the attachment but it had no file extension following the file name
- The attachment would have an extension like .001 rather than .doc, .xls, etc.
This problem was only reported with attachments sent to Internet addresses while messages sent inside our Groupwise system could be viewed as expected. This behavior was found in messages created in both the Groupwise Client for Windows and WebAccess.
Our entire Groupwise system runs on Netware and was patched up to GroupWise 702 Agent Hot Patch 2 Rev 1 SP2, which is currently (as of 12-19-2007) the most recent recommended patch level.
I decided to try out the beta GWIA agent, GroupWise 7.0.2 GWIA Post HotPatch 1a – Rev B. 7.0.2HP, even though nothing in the associated readme lead me to believe this would fix my issues. I just suspected since the problem was only seen with Internet email, GWIA must be the culprit.
I installed the patch per the readme and restarted GWIA and was temporarily able to send out attachments without any problem – most of the time. I was still hearing reports of sporadic problems with attachments, but the attachments sent properly from my machine every time.
“It could be the Mime-Encoding setting on the clients (Tools | Options | Send) We had the same issue with external e-mails being garbled, it was caused by the upgrade to GroupWise 7, the clients settings for Mime-Encoding was changed to UTF-8 where GW6.5.7 clients do not like this, we forced a change to all the user.db’s and set the Mime-Encoding to ISO, this helped with our problem.”
I checked the client settings on my machine (which had no sending problems), and they were set to UTF-8. I used GWcheck to change the MIME-Encoding settings for our entire post office by following this procedure:
1. Start GWCheck
2. Under Database Type, select Post Office.
3. In the Database Path field browse to and select the post office directory.
4. Under Object Type, select User/Resource.
If you want to perform the conversion on all user and resource databases in the post office, specify ALL in the User/Resource field.
5. In the Action drop-down list, select Reset Client Options.
6. In the Support Options field on the Misc tab, type setmimeencoding=number, where number is one of the following character set numbers:
a. Windows default
b. ISO default
Click Run to perform the conversion of user and resource databases from UTF-8 to the selected character set.
Unfortunately the problem persisted. I had no idea what else to try, and the client was not too happy.
I was scouring support.novell.com for possible solutions, and came across TID 10100678. This TID didn’t describe the symptoms of my problem, but it did mention systems were affected once they upgraded from Groupwise 6.5 to 7. I was desperate, so I gave it’s fix a try:
From ConsoleOne, in the GWIA properties | SMTP/MIME Tab | Settings – Click the ‘Use 7-bit encoding for all outbound messages‘ box.
If this does not work, edit the gwia.cfg and add the following switch: /force7bit
I made this change and reloaded the agent, and my users were once again able to send attachments without any issues.
“By default, the Internet Agent uses 8-bit MIME encoding for any outbound messages that are HTML-formatted or that contain 8-bit characters. If, after connecting with the receiving SMTP host, the Internet Agent discovers that the receiving SMTP host cannot handle 8-bit MIME encoded messages, the Internet Agent converts the messages to 7-bit encoding.
With this option selected, the Internet Agent automatically uses 7-bit encoding and does not attempt to use 8-bit MIME encoding. You should use this option if you are using a relay host that does not support 8-bit MIME encoding. This setting corresponds with the Internet Agent’s /force7bitout switch.”