How To Improve The Tikit Bounceback Application On A Microsoft.Net (Msa) (Windows) 2 (Windows 2) 2) (Windows 3) (Minor) 2).5.5 (

Transcription

1 Tikit BounceBack Functional Specification June 2011

2 Statement of Confidentiality Due to the confidential nature of the material in this document, the information contained herein should be regarded as Commercial in Confidence. This proposal and its contents should not be discussed with or divulged to any third party without the prior written consent of Tikit Limited or its subsidiaries. This document shall not be reproduced in whole or in part without the written consent of Tikit Limited. Document Version Control Version Description of amendment Creation Date Author 1.1 First draft June 2010 Steve Todd 1.2 Second draft for conversation with Development May 2011 Steve Todd 1.3 Third draft post-us User Groups June 2011 Steve Todd

3 CONTENTS 1 Introduction Overview Architecture Changes Migrate to the Microsoft.Net platform from Visual Basic Set base limit on mail servers that can be used Core Functionality Enhancements Allow multiple mailboxes to be interrogated concurrently Provide mechanism to make identification of EMS bounced s easier Automate running of BounceBack Define Automatic actions Send Activity Alert s EBFWeb integration... 7

4 1 Introduction This document outlines proposed changes to the architecture and core functionality of the Tikit BounceBack application, to automate some of the functions it currently performs as well as enhancing the functionality available. This document should be considered a discussion document while in draft form only when signedoff by the Directors will any commitment be given to providing the functionality detailed in the document. 1 P a g e

5 2 Overview Currently, Tikit BounceBack is a manual application, which requires user intervention in order to process bounced s. Automation and ease of use are two areas which clients have expressed an interest in improving minimizing the amount of work required in this area will mean more people actually using the functionality effectively and therefore make the Tikit emarketing Solution an even more desirable product set than it already is. Input from clients has been included in this document it is recommended that once this draft is completed, further input be sought to ascertain if Any beneficial additional functionality we could provide has been omitted Any other points of debate 2 P a g e

6 3 Architecture Changes 3.1 Migrate to the Microsoft.Net platform from Visual Basic Migration to the Microsoft.Net platform will provide a user interface consistent with other products in the Tikit emarketing Solution (EMS), and would make it easier to provide the application as a Windows Service. Any XML configuration files could then be amended using the current EBF Configuration tools, thereby integrating BounceBack more tightly with the other current EMS products. 3.2 Set base limit on mail servers that can be used One of the difficulties faced by any application which gets its data from other sources is making sure multiple external applications and versions are catered for. With this in mind, and taking into account what existing clients currently use for their mail infrastructure, our initial build should attempt to accommodate the following mail systems: Microsoft Exchange 2003 (Support ends 04/08/2014 see this page) Microsoft Exchange 2007 Microsoft Exchange 2010 Lotus Notes 8.x IT SHOULD BE NOTED THAT THE OLDER MAIL SYSTEMS MAY BE EXCLUDED FROM THIS LIST AT RELEASE - ANY ADVANCES IN TECHNOLOGY THAT MAKE PROVIDING AN ENHANCED PRODUCT LESS-INTRUSIVE TO CORE IT SYSTEMS CANNOT BE DISCOUNTED PURELY ON THE BASIS THAT OLDER SYSTEMS DO NOT SUPPORT IT. 3 P a g e

7 4 Core Functionality Enhancements 4.1 Allow multiple mailboxes to be interrogated concurrently BounceBack currently connects to the mailbox of the Windows user where the application is running, using local configuration options in an INI file to over-ride these settings if applicable. However, this still means that only a single mailbox may be interrogated at a time by the application should a user wish to use another mailbox, then depending on their mail system they either need to have that mailbox included in their mailbox profile or they need to enter alternative credentials, and then click a button to select a different folder all of which is a very manual process. By migrating to a model similar to emerge where an XML configuration file is used, multiple mailboxes could be defined and BounceBack process each mailbox and/or folder in turn. 4.2 Provide mechanism to make identification of EMS bounced s easier In EMS back in July 2007, the internet headers of mails generated by EMS were enhanced to include the GUID of the mailing being sent out this was defined as X-EBFID. While this allows any incoming process to potentially identify the mailing a bounce related to, it does not provide the contact ID of the person who was mailed having this value would be beneficial in identifying which contact to apply any subsequent actions to, and reduce the amount of processing time each individual mail required from both BounceBack and associated systems like InterAction. However, there can be no guarantee that this value will be present in a Non Delivery Receipt (NDR) from an external system. The simplest way to determine who the receiving contact was with a bounce is to have a unique identifier in the bounce address the NDR is returned to. This will mean changing the Bounces To address on each mail being sent out to include a unique identifier which will be able to identify both the contact and the mailing the bounce related to. This in turn makes automatic processing more powerful, as bounces could be attached to a particular mailing when reviewing the EBFWeb statistics for that mailing. As an example, a mailing sent with a Bounces To address of [email protected] would be changed to [email protected] as the message is generated by the EBF Server, to allow us to interpret where it came from and which mailing it related to. 4 P a g e

8 WE BELIEVE THIS WILL REQUIRE SOME ADJUSTMENT TO HOW UNRECOGNIZED ADDRESSES ARE HANDLED BY CORE SYSTEMS, BUT THE ADDITION OF A SMALL COMPONENT SUCH AS A TRANSPORT AGENT OR EQUIVALENT TO THE MAIL SYSTEM SHOULD ALLOW UNRECOGNIZED INCOMING ADDRESSES TO BE CHECKED AGAINST KNOWN FORMATS FOR RE-DIRECTION TO THE APPLICABLE MAILBOX TO TAKE PLACE. Then, when the mailbox is reviewed by the BounceBack process, the identification element of the process will be straightforward in comparison to the current matching process, and appropriate actions can then take place with regard to the Automate running of BounceBack One of the main complaints with the current version of BounceBack is that it requires users to manually run the program to analyze the contents of a mailbox for bounced messages. Given that this process is simply reviewing the contents of a mail folder, there is nothing to stop this process occurring automatically on a timed or scheduled basis in much the same way as SMTP Express polls a folder to discover new s to send for example. The simplest way to achieve this is to provide BounceBack as a configurable Windows Service. If written in a similar way to the current EBFMessageServer or RSService EXEs, an endpoint can be made available which would allow the EBFServer to retrieve data on bounced s to include in the EBFWeb statistics for the appropriate mailings, in the same manner as Link Tracking data is currently retrieved thereby enhancing core functionality in EMS at the same time. This endpoint could also be used by a standalone UI component to allow users to perform manual BounceBack operations on an ad hoc basis (against an infrequently-used mailbox for example, or for s where the reason for the bounce cannot be determined by the automated process), in addition to any automated bounce processing already taking place. By processing all BounceBack activity through a single server location, all bounce data will be processed and tracked in the same way. Automating BounceBack will require additional business rule configuration: Define Automatic actions There are a number of actions that we would wish to perform on a bounced as we receive it: Add to folder in CRM system Link to Activity in CRM system Set Additional Field Value in CRM system e.g. increment bounce counter on sites where a 3-strike rule is in place for bounced s 5 P a g e

9 Update Notes in CRM system to include broken address Automatic removal of broken address from contact, to reduce confusion between bad address vs. bad contact Send Enquiry Who Knows Whom Other defined contacts/mail addresses Allow inclusion of mailing name(s) bounces were returned from Each of these items would need to be configurable in the EBF Configuration interface a dialog similar to the Completed Message Tasks > Perform Actions dialog in emerge would seem to be a good starting point, with the UI changing depending on the value chosen in the Action drop-down: In a similar way to how the Actions section in the Content Tracking dialog in emerge is used, users could define as few or as many actions as they want for BounceBack to process in its daily automated tasks Send Activity Alert s With processing being automatic in a Windows Service, defining a mailing list to send a summary of actions undertaken in a defined period would be beneficial. This would allow users to see information broken down by individual mailings such as how much processing has had to be done, as well as offer a notification mechanism to alert users if something goes wrong with the processing job itself. 6 P a g e

10 4.4 EBFWeb integration With tighter integration to the EBF Server and a mechanism to match bounced s to message objects, showing an additional tab in the Message Information section of EBFWeb would provide further additional information to end-users. Fields to display here would include: Link to contact in CRM system (as currently happens in EBFWeb) Contact Name address used in the bounced mail The defined Delivery Failure Pattern the was matched to when the bounce was analysed 7 P a g e