ListManager by default handles all error mail, including bounces (transient and permanent failures). However, the error mail settings must be correct for your list in order for it to function properly.
By default, ListManager will try to send a message three times—one initial send, and two retries. If a mail server reports that an address is permanently non-deliverable, ListManager will only attempt to deliver to it once for that mailing. This kind of bounce is a permanent failure. A message that is undeliverable for other reasons (e.g., mailbox is full or mail server does not respond) is a transient failure. If an address is undeliverable for the initial send and all the retries, it is considered to have bounced once.
Even if a mail server initially accepts the message and later determines that the user does not exist, ListManager will be able to record that address as having bounced. In this situation, the receiving mail server will reply to ListManager with error mail. This error mail will go to the bounce email address and will contain the user’s unique member ID number, so ListManager will be able to track it back to the particular address unable to accept mail. This kind of bounce will not appear in delivery reports, as the mailserver initially reported that it accepted the message. Many large ISPs (e.g., AOL) accept all mail and bounce back undeliverables later.
Hold Users
This option determines whether members who bounce a great deal of mail have their membership automatically "held" by ListManager so it does not continue to send mail to them.
By default, this setting is set to Yes. It is recommended that you retain this setting so ListManager holds users who bounce email.
When people's email addresses go bad (for instance, they change to another Internet Service Provider), each email message sent to their old address bounces back to ListManager. By default, ListManager will analyze the failures and determine who is causing them. If a member's email address appears to be invalid for several days in a row (based on your Bounce limit setting, see below), ListManager automatically disables their membership so that ListManager no longer sends them mail.
In most situations, automatic holding of users is a desired feature. In some situations, such as with internal mailing lists, where email address problems can be temporary (or must be repaired by a email system administrator) you can disable this feature. ListManager will then never put a membership on "hold".
When a user is placed on hold, ListManager can send the user an email message indicating that this has occurred as well as a copy of the most recent error message ListManager received from this user. This notification message, if the user receives it, can be very helpful to the user in determining why their email was being rejected by their mail system, and allows them to "unhold" their membership.
Bounce Limit
Determines the number of consecutive failed deliveries an address may have before being set to "held" status. Note that these failed deliveries may be days, weeks, or months apart, so long as they are consecutive (i.e., no successful deliveries between them). A successful delivery "resets" the count for an address, so addresses with intermittent delivery problems are not removed.
The default setting is two (2) bounces for announcement and email marketing lists, and five (5) bounces for discussion lists. If set to one (1), addresses that bounce will be put on hold after only one permanent delivery failure.
When analyzing the failed deliveries, ListManager counts only one bounce per day, per member, so an email address does not typically go on hold due to delivery problems on a single day.
The lower the number, the more quickly bad email addresses will be set to held—and the greater chance that someone with transient server problems will be inadvertently held. If you want your members to be placed on hold if they bounce any messages at all, you can set this number to 1. Setting Bounce Limit to 1 is strongly recommended if you are using old data with many bad email addresses.
We recommend the following settings:
|
Frequency |
Bounce Limit |
|
Daily |
5 |
|
Biweekly |
3 |
|
Weekly |
3 |
|
Bimonthly |
2 |
|
Monthly |
2 |
Note that failed send attempts are recorded in the lyrCompletedRecips table: a total of the number of bounces for an address is no longer contained in the members_ table.
Redirect All Bounces to Email Address
If blank, ListManager handles all bounced mail for you. If you don't want ListManager to handle your bounce mail, specify an email address to where all error mail should go.
This option is provided for advanced users, and it should be left blank unless you are prepared to handle the bounce mail at another address.
Any email address you specify here will replace the Mail From: header in your outgoing mail message. Normally, the mail transaction Mail From: address is the error handler of the server, and error mail is defined by Internet standards as going to this address.
If you change this setting ListManager will no longer receive error mail and will no longer be able to automatically process bounces, error messages, bad deliveries, etc.
It is STRONGLY recommended that you do not modify this setting.
Notifying Users of Their Held Status
When a member bounces too much email, their status can be changed to "held". That means their email address has been declared as "invalid" or "inoperational" and they no longer receive list postings.
ListManager has the capability to send a notification message to people on hold, to tell them about their status and give them the option of un-holding themselves. A member can unhold themselves by sending email to "unhold@…" at your ListManager hostname (e.g., unhold@lists.example.com).
If you choose to "never notify" the member will receive no notification, ever. Thus, they will not have a real opportunity to "unhold" their membership.
Although it is possible to inform users that their membership is on hold because of bounces, it is not recommended; since the address is bouncing mail, a hold notification would likely bounce as well. Notifying users of their held status can greatly slow down the performance of your ListManager server.
Notify How Often
This setting determines the frequency at which ListManager notifies held members. You can choose to never notify held members, notify them every night, every few days or whatever interval you choose. This setting should be a number lower than that used for Notify for How Many Days, or members will never receive a held notification.
By default, your list is set to not notify held members.
Notify for How Many Days
This setting determines for how many days a member who has been placed on hold should receive a notification message. This setting does not directly correlate with how many notifications the member will get; it only means that the member will receive notifications for a specific duration.
By default, your list is set to never notify held members.
Thus, you can determine how many notifications someone will get if you divide the Notify for How Many Days value by the Notify How Often value, and drop the remainder. For example, if your "Held Notify Days" is set to 11 and your "Held Notify Interval" is set to two, you would divide 11 by two, and drop the remainder. These settings result in five notifications.