EXPIRE.CTL(5)EXPIRE.CTL(5)NAMEexpire.ctl - control file for Usenet article expiration
DESCRIPTION
The file <pathetc in inn.conf>/expire.ctl is the default
control file for the expire(8) or expireover(8) program,
which read it at start-up. It serves two purposes: it
defines how long history entries for expired or rejected
articles are retained, and it determines how long articles
not stored in a self-expiring storage method are retained.
If all of the storage methods used by the server are self-
expiring (such as CNFS), only the ``/remember/'' setting
described below is necessary or used.
Blank lines and lines beginning with a number sign (``#'')
are ignored. All other lines should be in one of two for
mats.
The first format specifies how long to keep history
entries for articles that aren't present in the news
spool. These are articles which have either already
expired out of spool or which the server rejected (and
``remembertrash'' was set to true in inn.conf(5)). There
should only be one line in this format, which looks like:
/remember/:days
where days is a floating-point number that specifies the
minimum number of days a history record of a given message
ID is retained, regardless of whether the article has
expired. (History entries are always retained at least
until an article fully expires.)
The reason to retain a record of an old articles is to
handle the case where a peer offers old articles that were
previously accepted and then expired. Without a setting
like this, the server would accept the article again and
readers would see duplicate articles. Articles older than
a certain number of days won't be accepted by the server
at all (see the ``-c'' flag of innd(8)), and this setting
should probably match that time period (14 days by
default) to ensure the server never accepts duplicates.
This setting does not affect article expirations.
Most of the lines in this file will be in the second for
mat, either four or five colon-separated fields as fol
lows:
classnum:keep:default:purge
or
pattern:modflag:keep:default:purge
The former is used for class based expiry which means
``groupbaseexpiry'' in inn.conf(5) is ``false'', and the
latter is used for group based expiry which means ``group
baseexpiry'' in inn.conf is ``true''. Both formats can
not coexist each other.
Where classnum field used for class based expiry is the
number that you specified in storage.conf(5).
The pattern field used for group based expiry is a list of
wildmat(3)-style patterns, separated by commas. This
field specifies the newsgroups to which the line is
applied. Note that the file is interpreted in order and
the last line that matches will be used, so general pat
terns (like a single asterisk to set the defaults) should
appear at the beginning of the file, before more specific
settings.
The modflag field used for group based expiry can be used
to further limit newsgroups to which the line applies, and
should be chosen from the following set:
M Only moderated groups
U Only unmoderated groups
A All groups
X Removes the article from all groups that it appears in
(The X flag is special; normally articles are not com
pletely deleted until they expire out of every group they
were posted to, but if an article is expired by a line
with an X, it is deleted out of all newsgroups it was
posted to immediately.)
The rest of three fields are used to determine how long an
article should be kept. Each field should be either a
number of days (fractions like ``8.5'' are allowed) or the
word ``never.'' The most common use is to specify the
default value for how long an article should be kept. The
first and third fields -- keep and purge -- specify the
boundaries within which an Expires header will be honored.
They are ignored if an article has no Expires header. (In
other words, if an article does not have an Expires
header, only default field is used and the Date header is
be honored to expire. But if an article has an Expires
header, default is not used, and articles are expired no
faster than the time set with keep and kept no longer than
the time specified with purge regardless of Expires head
ers). One should think of the fields as ``lower-bound
default upper-bound.'' Since most articles do not have an
Expires header, the second field tends to be the most
important and most commonly applied one.
The keep field specifies how many days an article should
be kept before it will be removed. No article in the
matching newsgroups or class will be removed if it has
been received for less than keep days, regardless of
Expires header. If this field is the word ``never,'' no
article in the matching newsgroups or class will ever be
expired.
The default field specifies how long to keep an article if
no Expires header is present. If this field is the word
``never'' then articles without explicit expiration dates
will never be expired.
The purge field specifies the upper bound on how long an
article can be kept. No article will be kept longer then
the number of days specified by this field. All articles
will be removed after then have been kept for purge days.
If purge is the word ``never'' then the article will never
be deleted.
If the line for classnum is not defined, keep, default and
purge are assumed to be all ``0''. (See below for default
definition.)
It is often useful to honor the Expires header in arti
cles, especially those in moderated groups. To do this,
set keep to zero, default to whatever value you wish, and
purge to never (or alternately set purge to some large
number, like 365 days for a maximum article life of a
year). To ignore any Expires header, set all three fields
to the same value.
For group based expiry, there must be exactly one line
with a pattern of ``*'' and a modflags of ``A'' -- this
matches all groups and is used to set the expiration
default. And for class base expiry, there can be exactly
one line with a class of ``255'' -- this matches all class
and can be used to set the expiration default. In either
case, it should be the first expiration line.
EXAMPLES
For class based expiry;
## How long to keep expired history
/remember/:5
## class 0 stay for two weeks
0:14:14:14
For group based expiry;
## How long to keep expired history
/remember/:5
## Most things stay for two weeks
*:A:14:14:14
## Believe expiration dates in moderated groups,
## up to six weeks
*:M:1:30:42
## Keep local stuff for a long time
foo.*:A:30:30:30
HISTORY
Written by Rich $alz <rsalz@uunet.uu.net> for InterNet
News. This is revision 1.15.2.1, dated 2000/08/17.
SEE ALSOexpire(8), expireover(8), inn.conf(5), storage.conf(5),
wildmat(3).
EXPIRE.CTL(5)
