|
General Bounce Information Managing bounces is one of the most important steps you can take with email marketing. Remote servers (those responsible for delivering to your customers) tally up the number of failed emails to their domain and will score you based on the percentage. If your bounce percentage is high, they can start blocking you on the fly to other emails in their domain. Identifying bounced emails the first time, and filtering them or removing them from your list is critical for email deliverability. In order for Campaign Enterprise to manage bounces, you must set up an email account exclusively for Campaign Enterprise's use. Create a new POP3 or IMAP4 email account as though Campaign were a new employee. This account cannot be an alias of another account and must be exclusive to Campaign. Once you configure the account, use it as the return path address, which is identified as the bounce email address on the compose message page in the Campaign edit screens. The Return Path email address is where non-delivery failure notifications go, also known as NDFs or bounces. These are notices from your mail server, or subsequent mail servers in the delivery chain, indicating a problem with sending the message. A permanent NDF is considered a hard bounce, either the domain or address doesn't even exist. These are identified by Campaign as a hard bounce, and can be filtered or removed from your list immediately in most cases. A temporary NDF is a notice from an email server that there was a problem with delivery, but your mail server may retry the message on a scheduled retry. You'll need to talk to your mail administrator about the number of retries your server has. These are identified as soft bounces by Campaign and you can use more discretion on filtering or fixing these addresses. Managing Bounced Emails with Campaign Other write back features in Campaign Enterprise use the unique id, but the id is frequently stripped out of bounced email messages. The only thing that is always preserved is the original to address. Unlike other features with Campaign Enterprise, the record that bounces is updated by comparing the original to address with the address field in your source table, not the unique id. Since this is the case, you will need one bounce email account for each table to which you are connecting. Scenario One In the example below, there are three different campaigns, all using the same source table. In this case, all the campaigns use the email address for bounce account 1, but only one campaign needs to actually have bounce enabled. All bounces, regardless of which campaign sent them, will update in the source table. 
Since the source table is updated, all three campaigns will be able to identify the bounced emails and apply the filter to prevent those emails from going out again. Using this scenario, you can create a Bounce Campaign, which is open to the entire table, no filtering, and enable it to monitor the account. It will monitor the account for all of the campaigns connected to that table and using that bounce email account. Scenario Two This example shows how bounces should be managed with multiple tables, one for each campaign. Since the source table has a specific group of addresses, you cannot check that account with the same bounce account being used by another campaign, the email address may not appear in the table. Each campaign would use the email address for the specific bounce account to which they are connected. 
Scenario Three
Finally, you can set up your bounce account to monitor an email account that accepts wild cards. With this option you can use VERPS, or Variable Envelop Return Paths. This is explained in more detail in these two articles. Using VERPS More on VERPS Unfortunately, MS Exchange Server 2010 does not support email accounts with wild cards. For more information on setting up your bounce email account, check with your email service provider.
0 Comments
By: Chris Lewis
Email bounces that occur when you send out email from any email software sending program can occur in two different way: An Error During Sending - During sending, if your SMTP server deems a certain email address as permanently undeliverable, then your SMTP server will return a 500-series error code which tells Campaign Enterprise or Email Marketing Director to hard bounce that email immediately. These kind of immediate hard bounces usually only occur for two reasons: The email address was malformed or the mail system you are sending through has "authority" over the domain of the email being sent and can just right on the spot if the email address is good or not. We see this happen a lot with Exchange servers where you both you the Exchange Server for receiving and sending emails. If your company domain is hosted on the Exchange server then the SMTP server of the Exchange server will only allow valid email addresses to be sent with those domains. Returned Email - This is the most common way bounces are recorded because most of the time your SMTP server does not have the immediate authority to say whether or not an email address is valid. In this scenario your SMTP server simply relays the email message you sent to the SMTP server that has authority for the domain (from the MX record). When your SMTP server is talking to the target SMTP server, the target SMTP server might say "that email box does not exist" which is a 500 series error. This triggers your SMTP server to send the email back to you (or your bounce account). This can take seconds to hours to happen. So, overall, bounces are somewhat difficult to deal with since they may happen from several different source, and since there is no standard for the formatting of bounces, it become the task of our software to decipher a bounced email which may have all or just part of the original message. In the next article, we will discuss the different ways to deal with the returned emails. One of the biggest complaints about Campaign Enterprise is the fact that you must set up a separate bounce email account for every table or record set to which you are connected. If you have multiple campaigns pointing to the same table, you can configure one of your campaigns to process the bounces. Regardless of which campaign sent the email, that campaign can find the record in the table and update it accordingly. Should you connect to separate tables, managing bounces becomes more problematic and you have to have multiple campaigns monitoring multiple accounts, increasing the pop processing load.
Now, you can change all that in Campaign Enterprise Version 11. With the introduction of variable envelope return paths (VERPs) you only need one bounce email account to monitor all of your campaigns, regardless of the source table. Here is how it works:
Variable envelope return path (VERP) is a technique used by some electronic mailing list software to enable automatic detection and removal of undeliverable e-mail addresses. It works by using a different return path (also called "envelope sender") for each recipient of a message.
Any long-lived mailing list is going to eventually contain addresses that can't be reached. Addresses that were once valid can become unusable because the person receiving the mail there has switched to a different provider (possibly as a result of changing jobs or schools). In another scenario, the address may still exist but be abandoned, with unread mail accumulating until there is not enough room left to accept any more. When a message is sent to a mailing list, the mailing list software re-sends it to all of the addresses on the list. The presence of invalid addresses in the list results in bounce messages being sent to the owner of the list. If the mailing list is small, the owner can read the bounce messages and manually remove the invalid addresses from the list. With a larger mailing list, this is a tedious, unpleasant job, so it is desirable to automate the process. Unfortunately, most bounce messages have historically been designed to be read by human users, not automatically handled by software. They all convey the same basic idea (the message from X to Y could not be delivered because of reason Z) but with so many variations that it would be nearly impossible to write a program to reliably interpret the meaning of every bounce message. RFC 1894 (obsoleted by RFC 3464) defines a standard format to fix this problem, but support for the standard is far from universal. Microsoft Exchange can sometimes bounce a message without providing any indication of the address to which the original message was sent. When Exchange knows the intended recipient, but is not willing to accept email for him, it omits his address. If a message is sent to joe@example.com and the server knows that this is Joe User, it will bounce the message saying that the message to Joe User could not be delivered, leaving out the joe@example.com address altogether. VERP is the only viable way of being able to handle such bounces correctly. The hard part of bounce handling is matching up a bounce message with the undeliverable address which caused the bounce. If the mailing list software can see that a bounce resulted from an attempt to send a message to user@example.com then it doesn't need to understand the rest of the information in the bounce. It can simply count how many messages were recently sent to user@example.com, and how many bounces resulted, and if the proportion of bounced messages is too high, the address is removed from the list. While bounce message formats in general vary wildly, there is one aspect of a bounce message that is highly predictable: the address to which it will be sent. VERP takes full advantage of this. In a mailing list that uses VERP, a different sender address is used for each recipient. http://en.wikipedia.org/wiki/Variable_envelope_return_path In previous versions of Campaign Enterprise, each subscriber list had to have its own POP or IMAP account to collect the bounced emails which could then be removed from that list. This was very inefficient and difficult to manage especially when using a lot of accounts. With the traditional method, the subscriber's email address is difficult to harvest from these emails, with about 70% accuracy at best. How To Implement Using VERPs, you can have one email account to handle all your bounce handling needs (if capacity is sufficient and your mail server allows variables). For the "bounced email address" setting on the Message tab in Campaign Enterprise you would entered something like this: Sales{VERPS}@arialsoftware.com When sending, this will case the Campaign Enterprise system to replace the {VERPS} merge field here with encoded information concerning the campaign and the unique ID used for the subscriber. The result may look like this: Sales--000120E0F14512@arialsoftware.com As you can see, this is not a very readable email address, but it is something you and the recipient never see and it has all the information the Campaign Enterprise system needs to be 100% accurate in remove the bounce. So, to use this new ability, you will need to create an email account that has a "catch-all" ability. The purpose of this type of account is so that any emails that come in to a certain domain that cannot be matched up to a specific POP account will be dropped into this "catch-all" account. For instances, say an address like johnsmith@arialsoftware.com did not have a pop account associated with it on the arialsoftware.com domain. Then this message would be dropped into the "catch-all" account. Some email systems will allow you to set up multiple "catch-all" accounts based on a wild card. For instance, you could create an account like john*@arialsoftware.com and any emails that did not have a specific POP account but started with John would be send to this pop account. On the Bounce tab in Campaign Enterprise, you will need to specify the POP account you have set up for bounces. You may only have already set up this bounce account for other campaigns so it will only be a matter of selected the account from the list. That's it! Now, one issue VERPs does not address is determining if a bounce is hard (500 series error) or soft (400 or less series error). What the current system does is examine the bounced email for any indications of error numbers, and if not found, then keywords are searched for. As stated above, formats for bounced emails vary wildly and as many formats as possible are examined. -- Arial Software |
Archives
December 2017
Categories
All
|
RSS Feed
Arial Software info@arialsoftware.com Ph 949.218.3852