Sign In Sign Out Mailing Lists Unsubscribe or Change Settings Help

Majordomo2 list server

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
configset listname bounce_rules <<TAG
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Default Value : no default
Data Type     : bounce_rules
Category      : bounce
Password Notes: Visible only with password. 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

configset listname bounce_rules <<ENDTAG
$consecutive > 40


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
  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:

  This is true if the bounce indicates a failure.

  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.

  The bouncing address, stripped of comments.

  The bouncing address, with all comments left in.

  The host portion of the bouncing address.

  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.

  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.

  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.

  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
  $consecutive >= 50 && $consecutive_days >= 5

  The number of bounces in the last 24 hours.

  The number of bounces in the last 7 days.

  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.

  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.

  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
  $host =~ / && $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.
  $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.
  $month > 200

  # Inform the owner when we start seeing more than just a few bounces
  $day > 5

  # Don't bother the owner otherwise

                             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)


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.1200410180.

For a list of all help documents, send the following command:
   help topics
in the body of a message to

For assistance, please contact the administrators.
Sign In Sign Out Mailing Lists Unsubscribe or Change Settings Help