How do you handle email bouncebacks with personalized subjects? We send bulk emails to thousands of clients daily. Currently we run a script that combs our inbox and places all emails with the same subject into various folders that match our SQL database. This works great until a personalized email subject is sent. Because these emails all have unique subjects our script ignores these emails. Does anyone have any suggestions on how to handle this? We can't always say ignore the first part of the email because what if the personalized part comes in the middle of the subject. We thought about passing a unique code into the subject that would be hidden...but this doesn't seem to work across all email clients. Any thoughts or suggestions would be really appreciated. Thank you all!
*added so when our script runs it is done through a process that compares the subject to our database using a dictionary that looks for exact matches.
When the email is sent out personalized, are there phrases that you use to personalize the subject? If so, I would keep track of the outbound subject phrases and tokenize the non personalized parts of the subjects. When the message bounces back, and it matches a personalized outbound subject, you can strip out the personalized strings, and you would be left with a matching set of tokens in the subject that match your out bound subject tokens.
If the subjects are sent out automated but completely personalized with no common tokens, you can store the target address and subject on the outbound route. When you get a bounce back that is randomly personalized, you can look in the outbound storage for the same recipient, subject combination and infer that the message is a personlized subject that indeed bounced back.
Related
We send an automated email whenever someone signs up for our app.
The subject is always the same for every user.
Let's say the subject is 'Welcome'.
The problem is that whenever someone replies, it always end up in a single giant thread in gmail.
So the emails from various users are interleaved with each other, which makes it very difficult to manage.
What we want is a single thread per user (i.e per recipient email address) so that we can keep the conversation with each person separate.
I'm aware that gmail has its own way of grouping messages into thread based on the subject line by default.
However, we noticed that some support tools (such as Zendesk) have somehow find a way to keep each email separate even though the same subject line is used. They seem to have a work around.
What I mean is that we have received multiple emails from the Zendesk email sender with the same subject and somehow they end up in multiple threads in our gmail.
They don't seem to use a uniquely generated email either. The from and reply-to address is simply support#domain.com
How do they do it?
We experimented with the 'Message-ID' and 'In-Reply-To' SMTP headers but were unsuccessful.
Sending emails with different Message-ID still end up in the same thread.
See example of a Zendesk email received to my gmail address below:
Since I can't post in the comment, will add to the answer here. Sample headers in an email I received from Zendesk. Note that they use the support email address + the ID of the support ticket as the 'Reply-To' address.
I work in a medical study where study coordinators at several off-site locations will be sending sensitive data via email attachments. These emails will be encrypted, but I cannot have the emails going to anyone but one or two specific recipients. I need a method to restrict who can receive email attachments based on a keyword in the email subject line. We are using MS Outlook 2010.
Ideally, it'd work this way: If the sender's email's subject line includes a keyword like 'RestrictedEmail' then only designated email recipients (for example, king#kong.com or robin#hood.com) can receive the email, else, the email will not send.
I didn't see this elsewhere in archives. Maybe I'm not using the right keywords...
Thanks in advance!
Trap the Application.ItemSend event, look at the message subject (Mail.Subject). If the match is found, loop through the MailItem.Recipients collection and check each Recipient.Address property to make sure only approved addresses are present.
I'm writing an app which allows users to send out a text-only email to a bunch of recipients. I want to try and generate the subject of this email from the body of the message, to avoid the need for a subject field
Is it safe enough to do this? Are these emails likely to fall foul of spam filters?
I'm already scanning the entire email for spam words, so there won't be any in the subject
you could download the widely used spamfilter Spamassassin and search for 'SUBJ' in the *.cf files, this will give you many spamrules that trigger based on subject (like empty subject, all caps, bad words, bad encoding of non-ascii characters etc)
I would suggest that if the mail is from a trusted source then there is not a problem. On the other hand since the mailbox dosent know that the subject is generated automatically it does not matter to them. And the third thing is that you need to check the guidelines that the email filters follow. Check out some ope source mail filter.
I'm generating a bulk mailing each day for users who want to receive the daily deals. I can either send a separate physical email with each user specified on their own unique To header, or I can send one email with all the users on the BCC line.
Obviously if I ever want to create user specific content I will need to customize the emails per user and send them individually, but if I don't want customized email right now, should I just send out the single email with everyone on BCC? Any reason to NOT do that.
Edit: I'm using a third party as my gateway that specializes in delivery with CAN-SPAM compliance, etc.. not trying to do this off my own mail server...
Update: I guess I'm really also looking for some metrics here. Is there a difference in open rates of BCC'ed email vs To field email? What about spam filtering rules that might pre-classify based on the BCC field?
No reason I can think off for NOT doing it. Using BCC is the polite way to send bulk emails.
In this case, it turns out that the correct answer was neither. The gateway provided a custom header API that allowed me to specify all the recipients in a secondary "To" field. The API then handled the blind delivery of the emails, and also did variable substitution for me so I didn't have to transmit all the duplicate content multiple times. The API then handled doing "best practices delivery of the email".
Am trying to determine the best way to persist information from an originating email, through to a reply back.
Essentially, it is to pass a GUID from the original email (c#), whereby when the receiver replies back, that GUID is also sent back for reference.
I have tried setting the MessageID, whereby using Outlook, the In-Reply-To value is set with the original ID, however using some webclient email systems, that value is not created on reply. Is there another way to sent this info through email headers?
Some variation on VERP is probably the most reliable...
http://en.wikipedia.org/wiki/Variable_envelope_return_path
Specifically, instead of having all your replies coming to the same address, encode the information you want to persist into the From address for the email.
For example, in the case of a helpdesk ticket, you could use something like:
From: Helpdesk <support-ticket-123#example.com>
To: End User <user#example.org>
Subject: Ticket #123 - problem with computer.
That way, regardless of what the user edits in the subject or text, you know what ticket is being referred to by the receiving email address.
I don't think you'll be able to do anything that is perfectly reliable by headers alone -- the number of clients that would have to cooperate is immense.
Most systems that do this work by including something in the body of the email that is sent that allows it to identify the message, and including text instructing the recipient to include that block of text in the response. You could also try including it in the subject (and including text in the body to leave the subject unchanged). That's how some mailing list managers I've seen do it.
I stumbled upon this question, and it's been very informative. This, however, leaves me with one question: Will using VERP, or a variation of editing the 'reply-to' or 'from address', cause the messages to be locked up in spam filters?
I have read that spam senders often change the bounce address to prevent their servers from getting clogged with bad email address bounces. Is it a spam risk to assume this approach?
The most reliable way is to put the ID in the subject, which should be preserved throughout replies.
(It doesn't hurt to tell your users that they should keep the subject intact.)
RT, a popular ticketing system, does this. They use a simple subject format like "[Ticket #123]" and key off of 123.