The Sage CRM E-mail Manager is a service that runs as a background process on the CRM server. Its job is to process inbound email ( and optionally to send automatic replies) according to predefined business rules defined a script file. These script files are called 'templates'.

The article "A round up of essential articles about configuring the Advanced E-Mail Manager" is a good starting point to read and learn about the Advanced E-mail Manager.

In this article I want to just look at the eMail Object itself which is available to use in the script templates. Once of the peculiarities of the object is that it is only available to the template scripts and offers much more sophisticated mail handling than the simple MessageBlock object which would otherwise be used in general scripts within Sage CRM. The Mail object allows you to work with attachments on inbound and outbound mail.

The Advanced E-mail Manager executable is installed on the Sage CRM server within the services folder, typically

C:\Program Files (x86)\Sage\CRM\Services

The eWareMailManager.exe is then run as a service.

The service uses settings defined in Sage CRM to monitor an email account and then process the inbound emails and then carry out work within Sage CRM according to the rule defined in a script template.

The templates are JavaScript files into whose namespace 6 objects are passed.

These objects are as follows

1. UserQuery - eWareQuery object that contains the details of the user who sent the email...should there be one.
2. PersonQuery - eWareQuery object that contains the person details of the sender of the email
3. CompanyQuery - eWareQuery object that contains the company details of the sender of the email
4. eWare - eWare object itself...logged on with admin user
5. MsgHandler - The log function (To catch errors) is only used from this object
6. eMail - This is the interface to the email itself

This last object included in the template is 'eMail'. This eMail object actually is defined in the eWareMailManager.exe itself NOT in the main eWare.dll which is the main dll that provides all the other objects. The Mail Manager uses the logon credentials stored in the registry to instantiate the eWare (aka CRM) object.

You can see the use of the eMail object in the example code snippet below

[code language="javascript"]
function createComm(EntityName)
{
var commRecord = CRM.CreateRecord("communication");
commRecord.Comm_Action = "EmailIn";
commRecord.Comm_Type = "email";
commRecord.Comm_Status = "Pending";
commRecord.Comm_priority = "Normal"
commRecord.Comm_Datetime = mydate.getVarDate();
commRecord.Comm_Note = eMail.Subject;
commRecord.Comm_Email = eMail.Body;

if (eMail.SenderName != "")
{
commRecord.Comm_From = "\"" + eMail.SenderName + "\" " + "<" + eMail.SenderAddress + "> "
}
else
{
commRecord.Comm_From = eMail.SenderAddress;
}
commRecord.Comm_To = GetMailList(eMail.Recipients);
commRecord.Comm_CC = GetMailList(eMail.CC);
commRecord.Comm_BCC = GetMailList(eMail.BCC);

if (eMail.Header("Reply-To") != "")
{
commRecord.Comm_ReplyTo = eMail.Header("Reply-To");
}
else
{
commRecord.comm_replyto = eMail.SenderAddress;
}

...

}
[/code]

Below you can see that I have attached the eWareMailManager.exe to the object browser of Visual Studio.

This has allowed me to look at the different exposed properties and methods of the eWareMailManager.exe.

Any email message consists of two components, the message header, and the message body, which is the email's content. The message header contains control information, including, minimally, an originator's email address and one or more recipient addresses. Usually additional information is added, such as a subject header field. The eMail object has access to header information like the CC lists directly as properties.

The eMail object has a method Header() that allow you to reader other headers that may be present.

• commRecord.Comm_ReplyTo = eMail.Header("Reply-To");

These are some other SMTP headers that may be referenced.

• Message-ID: Also an automatically generated field; used to prevent multiple deliveries and for reference in In-Reply-To: (see below).
• In-Reply-To: Message-ID of the message that this is a reply to. Used to link related messages together.
• Return-Path: When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. The return-path line preserves the information in from the MAIL command.
• Error-To: Indicates where error messages should be sent. In the absence of this line, they go to the Sender:, and absent that, the From: address.

The Headers available are shown within the source of the inbound email.

There are a few other interesting things you can do with headers. For example, depending on what software the customer is using for their outbound mail, custom headers can be inserted so that (for instance) you could assign auto-generated cases for review to someone if they had a relatively high spam score (X-Spam-Score if you're using SpamAssassin, X-Forefront-Antispam-Report if you're using TMG). Another usage that might be useful is using the Content-Language header (if defined) to assign inbound communications to members of a particular team who speak the sender's language.