Detect auto reply emails programmatically - c#

I have scenario where I would have to track the delivery of the emails I send programmatically and flag those recipients who have set either 'Out of Office" OR have the message delivery failed due to over-sized inbox OR if their email ID doesn't exist. Such instances usually send out automated replies. How can I track them? Does .NET (System.Net.Mail) offer any APIs to do it?

There's no set of checks for auto-responses that produce perfect behavior (detect all auto-replies with no false positives), but the following checks have worked well so far:
header Auto-Submitted with value other than no (see RFC
3834)
headers X-Autoreply or X-Autorespond with any value
header Precedence with value auto_reply
I don't yet have any advice for detecting message delivery failure notifications.

Related

how to add attributes (application-specific data) to a Twilio SMS - 2021

I am working on an appointment confirmation system where I need to bind the SMS response 'Y' or 'N' to some meta data and send that meta data to my API via the Twilio webhook.
I am using.NET SDK from Twilio and trying to add attributes to the SMS message (MessageResource) which their documentation states:
Attributes:
STRING PII MTL: 30 DAYS
"The JSON string that stores application-specific data. If attributes have not been set, {} is returned."
link to docs: https://www.twilio.com/docs/chat/rest/message-resource#message-properties
which is more like metadata which is what I need but when I try finding any 'attributes' property in my C# code with their SDK I can't find it.
Here's my code:
var twilioMessage = MessageResource.Create(
body: msg,
from: _configuration["Twilio:FromPhoneNo"],
to: new PhoneNumber(phoneNumber),
attempt:1,
attributes: "{"id":"test"}" //this property doesn't work
);
var attributes = twilioMessage.attributes; //this doesn't work either
Any help will be highly appreciated.
Twilio developer evangelist here.
I'm afraid you are looking at the wrong documentation for sending SMS messages there. This documentation is for sending a chat (app to app) message. The documentation for sending an SMS is here.
Sadly, SMS messages do not have the ability to bind custom attributes to them. It is simply something that doesn't exist in the protocol.
You are sending an appointment confirmation and expecting a "Y" or "N" response. I am guessing you are trying to add the ID of the appointment in the case that you send confirmations for more than one appointment to the same phone number and you need to work out which appointment the response is about. There's a further issue here in that, as an end user, you cannot reply to a specific SMS messages. SMS is purely chronological.
There are 3 ways I can think of to work around this:
Only send one confirmation at a time. If you are still waiting for a response to a confirmation, don't send another one until you get that response. This might not work if users don't respond to confirmations.
Have the user include the ID of the appointment in the response. This is flaky because it relies on the users getting things right and you want to make things as simple as you can for them
When you need to send more than one confirmation at a time, use different Twilio numbers to send the confirmations. Then you can tie the confirmation response to the appointment by inspecting the Twilio number that the user sent the message to.
Number 3 is the most sound way of doing this. It shouldn't require you to have too many extra numbers, just as many as you might have concurrent appointment confirmations.
Let me know if this helps at all.

What are the ways to set Return-Path in the emails thats being sent out via .NET?

I am facing lot of issues with my current email system that being implemented in our application. There are lot of emails that are going out of the application and bounces back. Here my Return-Path set is by default which is the from address.
How can i set Return-Path to bounce#xxx.com? I tried to set the same in the headers, but it does not work.
Any ideas?
I think that what you want to do is set both the Sender and the From properties on the MailMessage object. The Sender property should be the address where you want bounce messages and the From property should be the address where you want the messages to appear from (in the case of successful delivery).

Outlook Add-In - Custom Headers for Email Tracking

We have written an Outlook add-in in C#, that appends a custom header to outgoing messages.
This add-in has to use a library called Redemption to bypass Outlook's security to modify the headers, and this is all working great.
Our problem lies when sending outgoing mail through an exchange server. We use the additional header as such:
Add a References header with an email address that includes an ID for tracking with our system.
This is a standard email header that all mail clients should pass on when replying to messages. So replying to a message will automatically keep the new message tracked.
All of this works just fine if you send an email from an IMAP account setup in Outlook such as GMail.
Problem is, if you send mail via an Exchange account, the Exchange server overwrites the References header and uses it's own proprietary headers: Thread-Index and Thread-Topic. Email standards suggest to use References and In-Reply-To headers. See this link on this issue.
Does anyone know a way around this? Some algorithm to gain us the following:
Add a header (of any name or kind) to emails that includes a 10-digit ID and 3 letter prefix
Replying to this email from all (or most) mail clients preserves the custom header
I think the following algorithm is going to solve our issue:
Our Outlook add-in will set the References and an arbitrary X- header
Our mail filter will look for References, if found use it (if outgoing mail server was Exchange, it will not be present)
If our mail filter finds the arbitrary X- header and a Thread-Index, it will store the data found in the X- header.
Later if the email is replied-to several times, the mail filter will use the Thread-Index to look up the past info to keep the email tracked.
For those wanting to know internals of the Thread-Index header, it is a Base64 encoded string. The first 22 bytes are the original unique portion and each reply adds an additional 5 bytes on to it. We only use the first 22 bytes to identify the email.

How to group e-mails by thread?

I need to recognize if email message is an response for message sent by my application, to put it into same email thread (something like gmail does). How can I mark an email or what data let me to recognize if it's an answer for one of previous messages in a thread?
I'm connecting through IMAP protocol, but I can easily switch to pop3 if it will be easier...
When you send your e-mail, include a Message-ID header with some globally-unique ID for your message.
When you get the response, it should have a References header that refers to your original Message-ID.
The 'In-Reply-To' header of the child should have the value of the Message-Id header of the parent.
There is one another field in header 'References' which contains message ids of all its parent.
you can user either of them as per your requirement.

WebDAV query trouble - unable to read body of e-mail

Our group (corporate environment) needs to monitor a couple of faceless accounts' Outlook inbox for specific types of bounced e-mails.
WebDAV (using C# 2.0) is one of the paths we've traveled and we're almost there, except for one minor problem: we're getting the response below for the e-mail body element
<a:propstat>
<a:status>HTTP/1.1 404 Resource Not Found</a:status>
- <a:prop>
<a:htmldescription />
<a:textdescription />
</a:prop>
</a:propstat>
The only real commonality is that it only happens on messages that our Exchange server is returning to us as "Undeliverable". Note: All other e-mails come across just fine.
Any thoughts?
It looks like undeliverable messages in Exchange have a content-type of "multipart/report; report-type=delivery-status". Probably because they don't have a body, just a summary of the delivery attempt which can actually all be gathered from the Headers of the message. Perhaps the WebDAV access (I don't have access to an OWA account right now to check) doesn't know what to do with that, i.e. is just thinks the e-mails don't have a body.

Categories