Groupwise 7.0.2 and problems sending attachments

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.

Karen from the NGWlist gave me a few ideas where to look for the solution to my attachment troubles. Her first thought was MIME encoding:

“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
c. UTF-8

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.

I was unfamiliar with the differences between 7 and 8-bit encoding, so I checked out the Groupwise 7 documentation. I found that

“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.”

Comments [4]

  1. I have been thinking of using 7 bit as well to see if it would correct this issue. Our GroupWise system is 7.02 (standard update). Normal messages without any attached files were showing attachments ending .000 or .001. After reading your experiences, I have switch over to 7 bit, now the attachments that show are only for messages with actual files attached. The correct extensions show on the attachments as well.
    Thank you for posting your experiences on with this.

  2. You need to apply the latest patch and use MIME encoding UTF-8 or use Windows Default.

    UTF-8 is 8 bit encoding
    Windows Default is 7 bit ASCII encoding

    NB: Using UTF-8 99% of emails will work, using Windows Default I am yet to see any issues

  3. Anyone experience a problem with 7.0 where emails are “sent” with no To: address? This is occuring in an MS-Access application where reports are sent via email (Groupwise) “automatically”. Problem cropped up with the upgrade to 7.0.

    Thanks

  4. As far as the attachment issue, what I’ve found is if a person tries to attach a document that is open, that is where the problem occurs. The person receives an error message, the receiver receives an empty attachment showing 0 kb, but the attachments name is there. Just making sure any item that is sent is not open has solved it for us.

Leave a Reply

Your email address will not be published. Required fields are marked *