MessageClass Not Preserved on Receipt

[Pete Loveall]

I am using a formregion on OL 2007 to generate emails using a specific form
message class: IPM.Note.myForm (for instance). When this email is sent, the
email is stored in the Sent Mail folder properly with the proper message
class. It is received properly with OL 2003 with the proper message class
(of course, OL 2003 doesn't have the form region to display the mail
properly). It is NOT received properly with OL 2007 (MessageClass =
"IPM.Note"). My addin has to try and guess if ithe incomming mail should be
changed to IPM.Note.myForm I believe this to be a bug in OL 2007 B2TR.

 

[Sue Mosher [MVP-Outlook]]

Can you explain what steps you're taking to generate email messages with that MessageClass value? Is the recipient marked for rich-text format? Do other custom forms transmit MessageClass OK or is it just this one? WHat kind of mail account(s) are involved?

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Pete Loveall]

To use the simplest example (we also set the MessageClass for Reply,
ReplyAll, and Forward), let's look at simply creating a new message using the
form region. The message body is plain text and there is one attachment
(compressed file). The message is sent using SMTP and received by OL 2007
via POP3. As I stated in my initial post, OL 2007 is sending the message
properly as it is put in the Sent Mail folder and it is received by OL 2003
with the proper MessageClass. This is an issue with OL 2007 receiving the
form class.

We hook the application new_mailex event, look at MessageClass on the new
item and it is IPM.Note. Currently, we use certain criteria to guess if it
is our form and change it to IPM.Note.myForm if it is. This change does hold.

Along this lines, it also appears that the display name for the attachment
is lost too. The received DisplayName is the same as the FileName on the
attachment.

Pete Loveall

 

[Sue Mosher [MVP-Outlook]]

I still don't think that tells us how the value for MessageClass is being applied to the original message in the first place. The two methods available are:

-- Create the message with a published custom form.
-- Set the MessageClass in code somewhere along the way.

The message body is plain text

That may be part of the problem. Only a message with a TNEF component (winmail.dat) can transmit a MessageClass value intact to the recipient. A published custom form does that automatically, regardless of the message body format. Otherwise, you'd have to send a rich-text format message. Note that doing so will make the attachment usable only by Outlook recipients.
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Pete Loveall]

#1) For this example, I stated that I was creating the message using the
"Create Form..." selection and the Form Region which is published as a
ReplaceAll for the form. The MessageClass is set by Outlook in this case,
not the addin (the formregion has no code).

#2) The message body is created by using the Message entry field in the
formregion and is not forceably set to anything.

#3) As stated before, OL 2003 receives this message with no problem and sees
the proper MessageClass. OL 2007 B2TR does not. Please concentrate on the
reception of the message by OL 2007 B2TR, not the sending of it.

Pete Loveall

 

[Sue Mosher [MVP-Outlook]]

Thanks. Now we have enough steps to try to reproduce the problem, which was impossible to attempt before.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Sue Mosher [MVP-Outlook]]

I created a simple form region (no code, no addin), created the message with Choose Form, and sent it, then retrieved it on another machine that did not have the form region. The custom MessageClass came through loud and clear, and all three test items (one in each body format) included a Winmail.dat MIME part.

Your symptoms suggest that one of the mail servers that touches the item might be stripping the TNEF (Winmail.dat) content. That's easy enough to confirm if you send to an account you can read in Outlook Express or a Gmail account. If that turns out to be the case, then you'll need to take it up with the manager of the server that's causing the problem.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Pete Loveall]

There is only one mail server involved: Exchange 2003, latest SP. As I say,
it comes through just fine on an Outlook 2003 directly attached to the
server. I am not aware of any setting in Exchange 2003 which says "strip
winmail.dat" for POP3 clients.

 

[Sue Mosher [MVP-Outlook]]

See http://support.microsoft.com/kb/821750/ for information on such settings.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Pete Loveall]

It is in the mail server. Exchange Server 2003 POP3 and/or IMAP4 protocol
servers must be configured for Exchange RTF format. If not, they do not send
the winmail.dat to the client.

Now if I can get someone to figure out how to make tabs work in an ActiveX
control in a FormRegion, the application would be great (another post in this
forum and the InfoPath forum).

Thanks for your help.

Pete

 

[Sue Mosher [MVP-Outlook]]

How about starting a new thread explaining just what you mean by "make tabs work"?

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Pete Loveall]

I did a few days ago. See:

http://msdn.microsoft.com/newsgroup...2cb9&mid=916d90a7-a54e-4101-93fc-7d6d46022cb9