| Sign In | Sign Out | Mailing Lists | Unsubscribe or Change Settings | Help |
OpenBSD Mailing List Server
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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 majordomo@openbsd.org.
For assistance, please contact the openbsd.org administrators.
| Sign In | Sign Out | Mailing Lists | Unsubscribe or Change Settings | Help |