Environment
GroupWise 8
Exchange 2007
Entrust Certificates
Exchange 2007
Entrust Certificates
Situation
- No problems sending and receiving encrypted email among our internal GroupWise users.
- Intermittently encrypted messages from Exchange cannot be read.
- The messages only have the smime.p7m attachment.
- Seems to be random occurrences.
- The same Exchange user can send a message that is readable, then send one that is not.
- Using a SMIME Viewer, that can read the smime.p7m attachment, it appears that by the time the message gets to GroupWise, the required information is not there, and is therefore unable display the encrypted message correctly in GroupWise.
Resolution
Outlook users have to create a new contact with the cert (since they won't import the certs into the GAL) and force Outlook to send as plain text. By forcing plain text, it avoids the problem of Outlook possibly sending in TNEF format, which fails. It is a matter of making sure that the Outlook users always pick the GroupWise users from their personal contact list.
Additional Information
Every time the encryption fails Outlook is sending the message as MS-TNEF and a winmail.dat file. In these cases, GroupWise will never see it as an encrypted message. It will have the smime.p7m attachment with garbled text.
In one working example:
It had an smime.p7m boundary and so it appears that this should be encrypted when it reaches GroupWise.
In one broken example:
There was nothing in the header that would indicate that this was an encrypted email. GroupWise does not remove or change the MIME received from the sender, so this would indicate a problem from the sending side since there is no smime.p7m attachment.
It also appears that this message should show no message body if the view on the client was set for text. It it was set for HTML, then it should show something (We are assuming that there was more beyond the end of the following boundary, though it was not included in the example sent to Novell Technical Support, if there was nothing more beyond that, then there was no data in the email.)
--_000_C52C268E9BA88142AC550A1BCC7E361512C079E5C1LCXCLMB02LCDS_
Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64
Content-Type: application/ms-tnef; name="winmail.dat"
So as far as we can tell, either Outlook is not sending all the data, or the data is being stripped out before it hits GroupWise's GWIA.
Troubleshooting steps:
1) Compare a failed mime received to that of the sent mime. This sent mime would have to come from the Outlook message. If both are bad, then it's something that Outlook is doing. If they don't match, then the problem is likely one caused by that of a spam and/or virus scanners.
2) Try and trap the message at the GWIA level, before it's converted by the GWIA, and look and see. Trying to trap the message at the GWIA may be tough, especially if it's a random occurrence.