Le Café Central de Deva
... Deva blogs!!
I changed the way of blogging. Re-designed the site & started using the latest Windows Live Writer 2011!! Additionally added Microsoft Translator gadget available @ top of page, so that you can change the page in your preferred language!!
Issue with TNEF:
The use of TNEF is commonly affected by settings in Outlook that are referred to as "Microsoft Outlook Rich Text Format." Rich Text Format and TNEF are not exactly the same, but they are closely related.A TNEF-encoded message contains a plain text version of the message, and a binary attachment that "packages" various other parts of the original message. In most cases, the binary attachment will be named Winmail.dat, and may include:
The formatted text version of the message (font information, colors, and such)
OLE objects (embedded pictures, embedded Office documents, and such)
Special Outlook features (custom forms, voting buttons, meeting requests, and such)
Regular file attachments that were added to the original message
In addition to the information listed above, the path to your personal folders file (PST) file and your logon name are embedded in the winmail.dat file. Although this data is not explicitly exposed to the recipient, if the recipient opens the winmail.dat file for editing in a binary or text editor, he can see the path and logon name. Note that no password information is revealed. To ensure that the path to your PST file or your logon name is not included in the winmail.dat attachment, use the steps in this article to send mail that does not include winmail.dat.Some Outlook features require TNEF encoding to be understood correctly by an Internet e-mail recipient who also uses Outlook. For example, when you send a message with voting buttons to a recipient over the Internet, if TNEF is not enabled for that recipient, the voting buttons will not be received. Alternatively, for sending messages with regular file attachments, TNEF is not needed. If you are sending e-mail with file attachments to a recipient who does not use Outlook or the Exchange Client, you should manually choose to use a mail format that does not require TNEF (such as plain text). By not sending TNEF messages, the recipient will be able to view and save the attachments as expected.
Issues when Send & Receiving mails:
When a message containing TNEF information is received by a mail client that does not understand TNEF, there are three common results:
The plain text version of the message is received and it contains an attachment named Winmail.dat. The Winmail.dat attachment does not contain any useful information when opened since it is in the special TNEF format.
The plain text version of the message is received and it contains an attachment with a generic name such as ATT00008.dat or ATT00005.eml. In this case the client is unable to recognize the TNEF part of the message, and is unable to recognize the Winmail.dat file name, so it creates a file name to hold the TNEF information.
The plain text version of the message is received and the client ignores the Winmail.dat attachment. This is the behavior found in Microsoft Outlook Express. Outlook Express does not understand TNEF, but it does know to ignore TNEF information. The result is a plain text message.
In addition to the receiving client, it is not uncommon for a mail server to strip out TNEF information from mail messages as it delivers them. If a server option to remove TNEF is turned on, clients will always receive a plain text version of the message. Microsoft Exchange Server is an example of a mail server application that has the option to remove TNEF from messages.
Internet Standards - Message Encoding:
The Internet standards for encoding messages such as Multipart Internet Mail Extensions (MIME) and UUENCODE are used independently of TNEF. TNEF can exist in a MIME-encoded message as a MIME body part of type "application/ms-tnef," or in a UUENCODED message as an attachment named Winmail.dat.When a TNEF message is sent using MIME, an entry similar to the following is added to the message:
------ =_NextPart_000_01BA6275.348C1000 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IisSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAEAAQ ABBJAGAEgBAAABAAAADAAAAAMAADACAAAACwAPDgAAAAACAf8PAQAAAHQAAAAAAAAAtTvC [. . .]
Alternatively, if a TNEF message is sent using UUENCODE, information similar to the following is added to the bottom of the message:
begin 600 WINMAIL.DAT M>)\^(C<.`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$%@ ,` M#@```,L'" `$``<`)P`O``4`0 $!"8 !`"$````S,S5$,C,W,#%"0T-#13$ [. . .]
In either case, the TNEF encoding is sent to the recipient and must be understood by the receiving client to correctly display the encapsulated information.
For more information, please read this article
TNEF & Winmail.dat
Exchange Server 2003 uses transport neutral encapsulation format (TNEF) to convert MAPI messages to RFC 822 format. TNEF appears on a message as a MIME attachment of type application/ms-tnef. The attachment is called Winmail.dat. It contains the full message content and any attached files. Only MAPI clients, such as Outlook, are able to decode the Winmail.dat attachment. Non-MAPI clients are unable to decode TNEF and might show Winmail.dat as a typical, but useless file.
Note: Recipients with mailboxes on an Exchange server, who use Internet clients to access their messages, are not considered non-MAPI recipients. This is because the Exchange store that hosts the mailboxes can produce the necessary RFC 822 content in non-MAPI format when users download MAPI messages from their Inboxes using a POP3 or an IMAP4 client. There are several possible Exchange-to-Exchange transfer scenarios that require MAPI to RFC 822 conversion:
Note: Within a routing group, Exchange Server 2003 always uses S/TNEF, because in all remote delivery cases, the message is guaranteed to take either an SMTP hop directly to a server running Exchange 2000 Server or Exchange Server 2003 or go to the Exchange MTA. Exchange 2000 Server and Exchange Server 2003 support binary MIME. On the other hand, if the message is passed to the Exchange MTA for delivery to a server running Exchange Server 5.5 through RPCs, message conversion is not required, because the RFC 822 format is not used.
Note: Non-MAPI recipients typically prefer to receive a message in plain text or HTML without TNEF, because their clients cannot decode the Winmail.dat file that includes the message and all attachments. TNEF encapsulation prevents non-MAPI clients from accessing attachments. Non-Microsoft tools, such as EPOC WMDecode for Windows, might be able to extract attachments from Winmail.dat files.
You can control the TNEF format behavior for sending messages by adding the following registry key. The number nn represents the virtual server instance for this machine.
HKey_Local_Machine\Software\Microsoft\Exchange\StoreDriver\Exchange\ nn \EnableTnef
A value of 0x0 disables TNEF, and messages are generated without using TNEF. A value of 0x1 will generate a message using legacy TNEF when S/TNEF would ordinarily be generated. A value of 0x2 has no effect, as that is the default behavior.
Do you know?
MS Exchange 2000 Server application development-related technologies and features were changed in MS Exchange Server 2003. Some technologies were enhanced, while others were removed, or are not supported in specific scenarios.
Exchange 2000 Technologies not Included with Exchange 2003:
More information is available at this following article, please click here
Microsoft have done changes in Exchange Server 2003 SP2. It includes new DLLs for several key APIs, and includes some key changes in behavior. While Exchange Server 2003 SP2 does not include any changes to the objects, classes, and interfaces, it does introduce key differences in how some of the APIs work.
The following API libraries that ship with Exchange Server 2003 or with Microsoft Outlook 2003 have been updated in Exchange Server 2003 SP2:
Important: These changes only affect the libraries that ship with Exchange Server 2003. The libraries that ship with Microsoft Windows XP, Microsoft Windows 2000 Server, Microsoft Windows Server 2003, and Microsoft Exchange 2000 Server are not affected by these changes.
For more information, please find the detailed article available
I have found this wonderful piece of code(Visual Basic 6.0), used to create mailbox store.
'//////////////////////////////////////////////////////////////////////////////////'// Name: CreateNewMailboxStoreDB'// Purpose: To create a new Mailbox Store (MDB) with a given name'// Input: strMDBName = contains the name of the new MDB to be created'// blnMount = True if the new MDB will be mounted after creation or False if the new MDB will not be mounted'// strComputerName = contains the name of the Exchange 2000 server'// strSGName (Optional) = contains the name of the storage group to create the new MDB in; if it is empty then the new MDB will be created in the'// default Storage Group'// strMDBUrl (Optional ByRef) = contains the URL to the new MDB created;'//'//////////////////////////////////////////////////////////////////////////////////
Public Sub CreateNewMailboxStoreDB(ByVal strMDBName As String, ByVal strComputerName As String, Optional ByVal blnMount As Boolean, _ Optional ByVal strSGName As String, Optional ByRef strMDBUrl As String)
Dim iServer As New CDOEXM.ExchangeServer Dim iMDB As New CDOEXM.MailboxStoreDB Dim arrStGroup() As Variant Dim i As Integer Dim strTemp As String
' Set the name of the MailboxStoreDB iMDB.Name = strMDBName
' Bind to the Exchange Server iServer.DataSource.Open strComputerName
' Start to build the URL to the MailboxStoreDB - first part strTemp = "LDAP://" & iServer.DirectoryServer & "/" & "cn=" & strMDBName & ","
' Set variant array to the ExchangeServer.StorageGroups arrStGroup = iServer.StorageGroups
' Look in the StorageGroups array if the StorageGroup with strSGName exists If strSGName = "" Then ' Finish to build the URL to the MailboxStoreDB - add last part strMDBUrl = strTemp & iServer.StorageGroups(0) Else For i = 0 To UBound(arrStGroup) If InStr(1, UCase(arrStGroup(i)), UCase(strSGName)) <> 0 Then strMDBUrl = arrStGroup(i) End If Next If strMDBUrl <> "" Then ' Finish to build the URL to the MailboxStoreDB - add last part strMDBUrl = strTemp & strMDBUrl End If End If
' Save the New MailboxStoreDB iMDB.DataSource.SaveTo strMDBUrl
' Mount the MailboxStoreDB if blnMount is True If blnMount = True Then iMDB.Mount End If
' Cleanup Set iServer = Nothing Set iMDB = Nothing
Find the small article which talks about how to configure the pickup directory in Exchange Server 2007.
Exchange Server 2007 & configuring Pickup directory:
Its' quite interesting to configure the pickup directory in Exchange Server 2007 environment. As we know that the Pickup directory is used by administrators for mail flow testing, or by applications that must create and submit their own messages. If we copy the correctly formatted e-mail message files to the Pickup directory are submitted for delivery.
Some points to remember:
By default, the Pickup directory is located at C:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup. The directory must be local to the Exchange 2007 computer.
By default, the Pickup directory exists on every Exchange 2007 computer that has the Hub Transport server role or the Edge Transport server role installed.
To configure the Pickup directory location, we can make use of "Set-TransportServer" cmdlet. This cmdlet lets you configure any transport configuration parameter on a Microsoft Exchange Server 2007 Hub Transport or Edge transport server.
The Set-TransportServer cmdlet manipulates the following groups of parameters:
Note: The Set-TransportServer cmdlet does not require the Identity parameter to be specified when you run the command. When you use the Set-TransportServer command, you can set any number of parameters at the same time.
Configuring the Pickup Directory Location:
To set the Pickup directory to C:\Pickup Directory on an Exchange 2007 computer named Exchangesvr, run the following command:
Note: Setting the value of the PickupDirectoryPath parameter to $null disables the Pickup directory. The directory that is specified by the PickupDirectoryPath parameter and the ReplayDirectoryPath parameter can't be the same.
Still issues or not successful to configure Pickup directory location, you can create the new Pickup directory and apply the correct permissions to it before you use the PickupDirectoryPath parameter with the Set-TransportServer cmdlet.
Run the following command in Exchange Management shell,
Please find the Outlook 2007 PIA documentation available @ online