|Sign In||Sign Out||Mailing Lists||Unsubscribe or Change Settings||Help|
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = configset listname bounce_rules <<TAG [VALUE LINES] TAG - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Default Value : no default Data Type : bounce_rules Category : bounce Password Notes: Visible only with password. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = EXAMPLE: configset listname bounce_rules <<ENDTAG remove-noprobe-quiet $consecutive > 40 ignore ALL ENDTAG The bounce_rules setting determines how error messages due to delivery failures should be processed. Each rule consists of at least two lines. On the first line are one or more actions, separated by commas. On the second and succeeding lines are conditions under which the actions occur. Blank lines are used to separate rules. When a bounce message is received, Majordomo first takes it apart and extracts the address of the user who is bouncing messages. Statistics are then generated, and then the bounce_rules are consulted to see what action should be taken. Currently there are four basic actions (inform is the default): ignore - do nothing; do not send a bounce notice to the owners and perform no action on the list of subscribers. (Statistics are still generated as appropriate.) inform - send a bounce notice to the owners, but leave the bouncing user on the list. remove - send a bounce notice to the owners, and remove the user from the list. reason - specify a reason that a particular action was taken. There are several modes for the remove action. By default, the list owners are sent a notice of the bounce (as with the inform action) and the bouncing user is sent one final, unique test message and if it bounces then the user is removed. The remove-consult action will, after the test message has bounced, send a consultation token to the list owners instead of immediately removing the user. If this token is accepted, then the user is removed. The remove-noprobe action will immediately remove the user, without sending the probing test message to verify that the user is indeed bouncing. This action will also cause the bouncehandler-unsubscribe shell hook to be run. See "help shell_hook" for more details. The remove-noprobe-consult action is also valid; it causes the owners to be consulted but no probing test message to be sent to the bouncing user. Finally, "quiet" mode (i.e., remove-consult-quiet, remove-noprobe-quiet, remove-noprobe-consult-quiet) will prevent the bounce notice from being sent to the list owners. The owners will still receive a consultation token if "consult" mode is used. If the bouncing user is unsubscribed, the owners will still receive an "inform" notice, subject to the inform configuration setting. The bounce message is sent to the e-mail addresses in the bounce_recipients configuration setting, or to the list owners if that setting is empty. The variables currently recognized are: failure: This is true if the bounce indicates a failure. warning: This is true if the bounce indicates a warning. Warnings do not generate statistics (i.e. they don't count as bounced messages). You generally want to ignore them (and the default is to do so) but you can inform the owner as well. addr: The bouncing address, stripped of comments. fulladdr: The bouncing address, with all comments left in. host: The host portion of the bouncing address. days_since_subscribe: The number of days since the user joined the list. You can use this to perhaps set a lower threeshold for new subscribers, or a higher one for long-time subscribers. digest: If the user is subscribed and receives messages in a digest, this variable will contain the name of the digest. Otherwise, it will contain an empty string. consecutive: The number of consecutive messages bounced. This records the length of the most recent consecutive run of bounced messages. So if messages 1,2,3,5 and 6 bounce, $consecutive is 2. Use this to detect when an address is bouncing a long run of messages. consecutive_days: The length in days of the most recent consecutive run of bounced messages. In the above example, if message 5 bounced at noon on Wednesday and message 6 bounced at noon on Friday, $consecutive_days would be 2. Use this in conjunction with $consecutive on high traffic lists to detect when an address is bouncing every message sent to it and it has been doing so for some period of time. (In high traffic lists, or lists where traffic is bursty, testing $consecutive alone might not give you much useful information.) For example: # Remove users after they have bounced at least 50 consecutive messages # over five days remove $consecutive >= 50 && $consecutive_days >= 5 day: The number of bounces in the last 24 hours. week: The number of bounces in the last 7 days. month: The number of bounces in the last 30 days. You can use $day, $week and $month if you want to set a threshold for the number of bounces in some time period without requiring that they be consecutive. bouncedpct: The percentage of messages which have bounced. This is calculated from the lowest and highest sequence numbers of bounced messages and the count of numbered bounced messages: (highest - lowest +1) / count. diagnostic: The bounce diagnostic. Majordomo tries to extract from each bounce a maningful error message. You can match against it here if you want to do perform special handling. This will contain the string "unknown" if no diagnostic could be extracted. The use of these variables in comparisons is described in the "help configset_access_rules" and "help access_variables" documents. Here's an in-depth example. (Please note that providers like AOL seem to randomly change their bounce formats and error messages, so you should always make sure that matches against $diagnostic are doing what you think they are). # When AOL says a user doesn't exist, drop it immediately remove-noprobe $host =~ /aol.com/ && $diagnostic =~ /user unknown/i # Remove all users bouncing enough messages over three days, but not for # "mailbox full" errors, because we want to be more lenient with them remove, reason="Over 20 consecutive 'mailbox full' bounces" $consecutive > 20 && $consecutive_days > 3 && $diagnostic !~ /mailbox full/i # Now deal with long consecutive runs that the above rule didn't match remove, reason="Over 100 consecutive bounces" $consecutive > 100 && $consecutive_days > 7 # Digests are posted less often than individual messages, so make # the consecutive bounce limits for digest subscribers more # restrictive, except for the "hourly" digest. remove $consecutive > 15 && $digest && $digest != "hourly" # Deal with users bouncing lots of messages but not ever building up a # big consecutive run. Consult the owner once the probe fails. remove-consult $month > 200 # Inform the owner when we start seeing more than just a few bounces inform $day > 5 # Don't bother the owner otherwise ignore ALL Probe Messages A bounce probe usually consists of two parts, the "bounceprobe" file and an attachment containing the error message. To send a probe without the error message attached, use the "notify" action to disable attachments. For example, the following rule would cause a probe without the attachment to be sent for every bounce: remove, notify=(attach=0) ALL Comments It is possible to use comments before, between, and after the individual rules, but not within rules. Comments are lines that begin with a '#'. See Also: help admin_subscribers help configset_access_rules help configset_bounce_max_age help configset_bounce_max_count help configset_bounce_probe_frequency help configset_bounce_probe_pattern help configset_bounce_recipients help configset_inform help shell_hook This is the "configset_bounce_rules" help document for Majordomo 2, version 0.1201103110. For a list of all help documents, send the following command: help topics in the body of a message to email@example.com.
If you need assistance, please contact the bugzilla.org administrators.
|Sign In||Sign Out||Mailing Lists||Unsubscribe or Change Settings||Help|