|
|
|
GNU Mailman - List Administration Manual |
|
|
|
Digest delivery is a way to bundle many articles together into one
package, which can be delivered once per day (if there were any posted
articles), or whenever the package is bigger than a specified limit.
Some users may prefer this style of delivery for higher traffic lists
since they will receive fewer messages.
Mailman supports two standard digest formats, and if digests are
enabled, users can select which of the two formats they receive. One
is MIME digests, where each message is an attachment inside a
multipart/digest. This format also contains a summary
table of contents, and of course the an optional header and footer,
and it retains most of the headers of the original messages.
The second type is called ``plaintext'' digests because they are
readable in mail readers that don't support MIME. Actually, they
adhere to the RFC 1153 digest standard. The retain some, but not
all of the original messages, but can also include a summary and
headers and footers.
Like non-digest delivery, you can enable or disable digest delivery,
but you cannot disable both types of delivery. You can specify
different headers and footers for digest and non-digest deliveries.
You cannot personalize digest deliveries.
As list administrator, you may want to send an urgent message to all
list members, bypassing the normal digest bundling. To do this, send
the message with a header, where the value of the
header is the list administrator's password. Non-digest members will
receive the message like normal, but digest members will receive the
message immediately5.
Here are the variables which control digest delivery:
- digestable
- The option controls whether members can receive digest deliveries
or not. If not, they will be forced to receive immediate
deliveries. You can't disable digests if non-digests are already
disabled.
- digest_is_default
- Controls which style of delivery is the default for new members.
You can choose Regular (non-digest) or Digest
delivery.
- mime_is_default_digest
- If a member is allowed to choose digests, this variable controls
which is the default digest style they will receive. Plain
digests are RFC 1153 format as described above.
- digest_size_threshold
- Normally, digest members get at least one message per day, if
there have been any messages posted to the list. However, for
high volume lists, you may want to send out digests when the size
has reached a certain threshold, otherwise, the one digest they
receive could be huge. This variable controls the size threshold
by specifying the maximum digest size in kilobytes. Note that
this threshold isn't exact. Set this variable to zero to specify
that there is no size threshold, in which case no more than one
digest will be sent out per day.
- digest_send_periodic
- This variable actually controls whether or not a digest is sent
daily when the size threshold has not yet been met. If set to
No, then digests will only be sent when they are bigger
than
digest_size_threshold
.
- digest_header
- This text box lets you enter information that will be included in
the header of every digest message sent through the list. The
same information can go in this header as can go in the
msg_header
, except for the personalization variables.
- digest_footer
- Just like with the header, you can add a footer to every message.
The same rules apply to digest footers as apply to digest headers.
- digest_volume_frequency
- Each digest is numbered with a volume and an issue. This variable
controls how often a new digest volume is sent. When the digest
volume number is incremented, the issue number is reset to 1.
- _new_volume
- This is an action variable, which forces an increment of the
volume number as soon as you submit the form.
- _send_digest_now
- This is another action variable. Select Yes, submit the
form, and the current digest is packaged up and sent to digest
members, regardless of size (well, there has to be at least one
message in the digest).
Footnotes
- ... immediately5
- They'll also receive the message in the
digest.
Release 2.1, documentation updated on May 15, 2012.