Service Email Usage – Handle DSN

In this blog article, we will see how we can handle delivery status notification messages.

This article is created using Pega 7.4 version. There may some changes with the configuration in the latest versions. Please use this article only to understand the concepts

Recap on the use cases. I recommend you to visit the articles in the following order to be on the same line.

https://myknowtech.com/tag/email-processing

1. Create a case with the data from the incoming email.

2. Use approval actions in the assignment notification, to update case automatically from the email service. This use case will use Subject data to identify the corresponding case ID

3. Manage email conversations with the case. This use case will showcase how to use Message ID header to identify the corresponding case ID

4. Handle delivery status notification messages. This use case will showcase, how we can use Thread-Topic  field to identify the corresponding Case ID

This will be the fourth and final use case.

What is DSN message?

It is message send by the email providers, most of the below reasons

1. Email message can get bounced back for various reasons – mailbox is full, invalid email address etc.
2. Autoreply messages, when someone is travelling or on vacation.

Note: For the second option, Pega expects the term Autoreply somewhere in the message! There is some risk if that term is not there!

How to handle DSN message?

The first main configuration point is in listener rule form

Open the email listener  – Process tab

If this unchecked then the DSNs messages will be discarded.

Let’s check this first.

Step 1: In my service case send mail step, I input some wrong email id.

I am sure this mail would bounce back

Step 2: Trace open the service email rule and run the case.

Nothing on tracer and no processing is done. So DSN messages left unhandled.

Okay, now imagine a Bank is using pega application to service their customer. For late payment on loans, Pega sends out an email to the customer email address. Just say, that customer had deleted his email account, so the email will keep on bouncing!!. In this situation, we need to handle these DSN messages effectively, so that the case can be handled.

At least, you should update your case details or notification should be sent out for the case owner.

Okay, let’s handle the DSN messages.

Before let’s learn few custom email headers we send from Pega

Open the agent activity that sends correspondence.

Rule name – Send; Class – Data-Corr-Email

1. X-PegaWork-Handle – Contains the case pzInsKey

2. X-PegaEmail-Handle – Contains the Data-Corr-Email pzInsKey

3. Thread-Topic – Case key ; corr key + subject(will be appended before sending)

These 3 custom headers we send out from Pega.

Now let’s process the DSN messages

Step 1: Switch on DSN processing in email listener rule.

Note: After making changes to listener rule, always restart the listener for the changes to take effect.

Step 2: Open the service email rule and move to request tab

You have an entire block to map the DSN details.

You see a set of field names you can use.

Reporting-MTA – says about the server that reports the DSN mail.

Action – Action performed by the MTA server

Status – DSN status code

Original – All these fields that start with original contains the original message information.

You can use this data for processing the DSN messages. For now, I add only 4 fields in DSN messages

We saw before, Thread-Topic is a concatenation of Case key + Corr key + Subject.

Pega has predefined a rule-utility-function that can parse the thread topic field

You see the function parse and map the data into four fields.

Note: You need to specify the Thread-Topic in the email header block.

Below is the configuration in my request tab.

Save the service email rule.

Let’s test the DSN message parsing.

Step 6: Trace open the rule and send the mail to unknown junk address.

Oh wait, where is the thread topic data. We have rightly configured it in our service email rule, but there is no mapped data?!

If you want to debug the mapping data, you can always check on the raw email data. You know how to check now.

Make a note of the below email thread. You can see the original email and the below one is the DSN message.

The above picture explains that the DSN message from gmail, do not use our headers!!

If you scroll down till the end, you can see Pega set the custom headers in the original email.

Interesting!! Below is the PDN supporting article that can explain the same issue!!

https://community.pega.com/node/631841

So, now how can we handle the DSN messages? How to identify which original mail failed and which case is affected?

Remember, use case 3. You can always use message ID – In-Reply-To headers to identify the original email and the corresponding case.

Note, we still have the DSN status., actions value rightly mapped.

With these data, hope you can build your custom service activity accordingly satisfying your business needs.

As a recap on this use case

– Delivery status notification messages can help you to identify if the outbound message failed.

– Make use of the DSN block in the email request tab and collect all the available information.

– You always have options to identify the case – Through subject ID (Use case 2), through message ID (use case 3) or using thread topic.

– Once you have all data, you can use your logic to handle the DSN messages effectively

Important note: When you create cases through email, make sure you either discard the DSN messages (listener control) or handle the DSN messages effectively. Because it may result in infinite looping!!

Please explore the Email headers and try to make use of the new features if any.