NAV Team: Preventing the Winmail.dat when not using Outlook as the default mail client

[Blog bot]

This is one of those scenario’s that is very difficult to troubleshoot because many external components are involved or could be involved like Dynamics NAV, Outlook, an ISP’s mail server, an internal or hosted Exchange Server, different webmail clients, Outlook Express and of course third party mail clients. Partners, end customers and Microsoft do not control all these components. Last but not least, there appears to be a difference in behavior when CU397 is being modified to directly send the message without having the E-mail message composed in Outlook first. Still, the receiver does not like to receive an E-mail with an attachment called Winmail.dat. Especially if it is an important PDF file or DOCX file containing an invoice or Sales Order. Here is however what we can say about this issue and what you can do about it.

When a Microsoft Exchange 20xx Server user sends a Simple Mail Transfer Protocol (SMTP) e-mail message with an attachment to a mail-enabled contact in the Global Address List, the mail-enabled contact may receive a Winmail.dat file attachment with the e-mail message instead of receiving the correct file attachment.

This issue may occur if the following conditions are true for the mail-enabled object on the Exchange computer:
• The default message format is set to Rich Text Format (RTF).
• The MAPI Recipient attribute is missing, is set to null, or is set to true.

Note The previous typically occurs if the mail-enabled contact is added by using a script.

You could change the settings in Active Directory Users and Computers so that the mail-enabled contact does not use RTF as the default message format. To do this, follow these steps:
1. Open Active Directory Users and Computers. To do this, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
2. Click the container where the mail-enabled contact is located.
3. Right-click the mail-enabled contact in the right-pane, and then click Properties.
4. Click the Exchange Advanced tab, and then click to clear the Use MAPI rich text format check box.
5. Click Apply, and then click OK.

The sender can avoid sending TNEF attachments by turning off TNEF in Outlook. When Outlook is configured to send e-mail in "Outlook Rich Text Format", it may use TNEF. When it sends in "HTML" or "Plain Text", it uses standard, compatible formats. There are many webmail clients and third party E-mail clients out there that do not completely support TNEF format:
How e-mail message formats affect Internet e-mail messages in Outlook
http://support.microsoft.com/kb/290809

This has to be done for every user, who sends the mentioned important mails.

We have also seen cases where we use CU397 to send emails with attachments. For a particular group of recipients using a third party SMTP server, the attachments are being received as Winmail.dat if and only if the email was opened after it was created by CU397 (OpenDialog parameter of NewMessage function is set to TRUE). Sending the email without any user interaction (OpenDialog parameter of NewMessage function is set to FALSE) does not exhibit this behavior. Creating a new E-mail through Outlook's GUI also does not exhibit the behavior. This behavior is also not seen if the mail server of both sender and receiver is an Exchange Server.

You could also try changing the BodyFormat property in CU397 to plain text:

OSendMail.BodyFormat := 2 - creates HTML formatted e-mail 
OSendMail.BodyFormat := 1 - simply text

Unfortunately, there are still scenario’s where this all did not lead to a scenario where the receiver does receive the attachment correctly. The following could lead to a final resolution, but some care needs to be taken into account if you are also running E-mail logging as a process. To resolve the issue, please adjust the following code in CU397:

Old Code:

OSendMail."To" := ToName;
OSendMail.CC := CCName;
OSendMail.Subject := Subject;
OSendMail.BodyFormat := 2;
MailGUIDValue := CREATEGUID;
OSendMail.SetUserProperty(GetMailGUIDFieldName,1,FORMAT(MailGUIDValue));

New Code:

OSendMail."To" := ToName;
OSendMail.CC := CCName;
OSendMail.Subject := Subject;
OSendMail.BodyFormat := 2;
// MailGUIDValue := CREATEGUID;
OSendMail.SetUserProperty(GetMailGUIDFieldName,1,FORMAT(MailGUIDValue)); If the following is true, then please have a look at the following:

1. the end customer uses Dynamics NAV and sends out an E-mail using a slightly modified CU397 where OpenDialog parameter of NewMessage function is set to TRUE
2. the end customer uses Dynamics NAV with E-mail logging enabled

Removing the MailGuidValue will cause multiple interaction log entries to be created when using e-mail logging. 
The MailGuidValue property is only used by e-mail logging to recognize mails as a part of an existing interaction log entry.  .

Then, if you don’t use the email logging, removing it will have no significant/catastrophic effect.

Development has confirmed they are looking at the E-mail logging functionality for version 7; especially since Outlook 2010 does not support CDO anymore:
http://blogs.msdn.com/b/deva/archive...look-2010.aspx

Regards,

Marco Mels
CSS EMEA

This posting is provided "AS IS" with no warranties, and confers no rights



Источник: http://feedproxy.google.com/~r/Micro...il-client.aspx