procmailex

package: procmail

title: procmailex(5)

text:
# procmailex(5)

## NAME
procmailex - procmail rcfile examples

## SYNOPSIS
$HOME/.procmailrc examples

## DESCRIPTION
For a description of the rcfile format see procmailrc(5).

The weighted scoring technique is described in detail in the procmailsc(5) man page.

This man page shows several example recipes. For examples of complete rcfiles you can check the NOTES section in procmail(1), or look at the example rcfiles in /usr/share/doc/procmail*/examples/.

## EXAMPLES
Sort out all mail coming from the scuba-dive mailing list into the mailfolder scubafile (uses the locallockfile scubafile.lock).

```
:0:
* ^TOscuba
scubafile
```

```

```

Forward all mail from peter about compilers to william (and keep a copy of it here in petcompil).

```
:0
* ^From.*peter
* ^Subject:.*compilers
{

   :0 c

   ! william@somewhere.edu

   :0

   petcompil
}
```

```

```

An equivalent solution that accomplishes the same:

```
:0 c
* ^From.*peter
* ^Subject:.*compilers
! william@somewhere.edu

   :0 A

   petcompil
```

```

```

An equivalent, but slightly slower solution that accomplishes the same:

```
:0 c
* ^From.*peter
* ^Subject:.*compilers
! william@somewhere.edu
:0
* ^From.*peter
* ^Subject:.*compilers
petcompil
```

```

```

If you are fairly new to procmail and plan to experiment a little bit it often helps to have a safety net of some sort. Inserting the following two recipes above all other recipes will make sure that of all arriving mail always the last 32 messages will be preserved. In order for it to work as intended, you have to create a directory named `backup' in $MAILDIR prior to inserting these two recipes.

```
:0 c
backup
:0 ic
| cd backup && rm -f dummy `ls -t msg.* | sed -e 1,32d`
```

```

```

If your system doesn't generate or generates incorrect leading `From ' lines on every mail, you can fix this by calling up procmail with the -f- option. To fix the same problem by different means, you could have inserted the following two recipes above all other recipes in your rcfile. They will filter the header of any mail through formail which will strip any leading `From ', and automatically regenerates it subsequently.

```
:0 fhw
| formail -I "From " -a "From "
```

```

```

Add the headers of all messages that didn't come from the postmaster to your private header collection (for statistics or mail debugging); and use the lockfile `headc.lock'. In order to make sure the lockfile is not removed until the pipe has finished, you have to specify option `w'; otherwise the lockfile would be removed as soon as the pipe has accepted the mail.

```
:0 hwc:
* !^FROM_MAILER
| uncompress headc.Z; cat >>headc; compress headc
```

```

```

Or, if you would use the more efficient gzip instead of compress:

```
:0 hwc:
* !^FROM_MAILER
| gzip >>headc.gz
```

```

```

Forward all mails shorter than 1000 bytes to my home address (no lockfile needed on this recipe).

```
:0
* < 1000
! myname@home
```

```

```

Split up incoming digests from the surfing mailing list into their individual messages, and store them into surfing, using surfing.lock as the locallockfile.

```
:0:
* ^Subject:.*surfing.*Digest
| formail +1 -ds >>surfing
```

```

```

Store everything coming from the postmaster or mailer-daemon (like bounced mail) into the file postm, using postm.lock as the locallockfile.

```
:0:
* ^FROM_MAILER
postm
```

```

```

A simple autoreply recipe. It makes sure that neither mail from any daemon (like bouncing mail or mail from mailing-lists), nor autoreplies coming from yourself will be autoreplied to. If this precaution would not be taken, disaster could result (`ringing' mail). In order for this recipe to autoreply to all the incoming mail, you should of course insert it before all other recipes in your rcfile. However, it is advisable to put it after any recipes that process the mails from subscribed mailinglists; it generally is not a good idea to generate autoreplies to mailinglists (yes, the !^FROM_DAEMON regexp should already catch those, but if the mailinglist doesn't follow accepted conventions, this might not be enough).

```
:0 h c
* !^FROM_DAEMON
* !^X-Loop: your@own.mail.address
| (formail -r -I"Precedence: junk" \

    -A"X-Loop: your@own.mail.address" ; \

   echo "Mail received.") | $SENDMAIL -t
```

```

```

A more complicated autoreply recipe that implements the functional equivalent of the well known vacation(1) program. This recipe is based on the same principles as the last one (prevent `ringing' mail). In addition to that however, it maintains a vacation database by extracting the name of the sender and inserting it in the vacation.cache file if the name was new (the vacation.cache file is maintained by formail which will make sure that it always contains the most recent names, the size of the file is limited to a maximum of approximately 8192 bytes). If the name was new, an autoreply will be sent.

As you can see, the following recipe has comments between the conditions. This is allowed. Do not put comments on the same line as a condition though.

```
SHELL=/bin/sh    # for other shells, this might need adjustment
:0 Whc: vacation.lock

 # Perform a quick check to see if the mail was addressed to us
* $^To:.*\<$\LOGNAME\>

 # Don't reply to daemons and mailinglists
* !^FROM_DAEMON

 # Mail loops are evil
* !^X-Loop: your@own.mail.address
| formail -rD 8192 vacation.cache

  :0 ehc         # if the name was not in the cache

  | (formail -rI"Precedence: junk" \

       -A"X-Loop: your@own.mail.address" ; \

     echo "I received your mail,"; \

     echo "but I won't be back until Monday."; \

     echo "-- "; cat $HOME/.signature \

    ) | $SENDMAIL -oi -t
```

```

```

Store all messages concerning TeX in separate, unique filenames, in a directory named texmail (this directory has to exist); there is no need to use lockfiles in this case, so we won't.

```
:0
* (^TO|^Subject:.*)TeX[^t]
texmail
```

```

```

The same as above, except now we store the mails in numbered files (MH mail folder).

```
:0
* (^TO|^Subject:.*)TeX[^t]
texmail/.
```

```

```

Or you could file the mail in several directory folders at the same time. The following recipe will deliver the mail to two MH-folders and one directory folder. It is actually only one file with two extra hardlinks.

```
:0
* (^TO|^Subject:.*)TeX[^t]
texmail/. wordprocessing dtp/.
```

```

```

Store all the messages about meetings in a folder that is in a directory that changes every month. E.g. if it were January 1994, the folder would have the name `94-01/meeting' and the locallockfile would be `94-01/meeting.lock'.

```
:0:
* meeting
`date +%y-%m`/meeting
```

```

```

The same as above, but, if the `94-01' directory wouldn't have existed, it is created automatically:

```
MONTHFOLDER=`date +%y-%m`
:0 Wic
* ? test ! -d $MONTHFOLDER
| mkdir $MONTHFOLDER
:0:
* meeting
${MONTHFOLDER}/meeting
```

```

```

The same as above, but now by slightly different means:

```
MONTHFOLDER=`date +%y-%m`
DUMMY=`test -d $MONTHFOLDER || mkdir $MONTHFOLDER`
:0:
* meeting
${MONTHFOLDER}/meeting
```

```

```

If you are subscribed to several mailinglists and people cross-post to some of them, you usually receive several duplicate mails (one from every list). The following simple recipe eliminates duplicate mails. It tells formail to keep an 8KB cache file in which it will store the Message-IDs of the most recent mails you received. Since Message-IDs are guaranteed to be unique for every new mail, they are ideally suited to weed out duplicate mails. Simply put the following recipe at the top of your rcfile, and no duplicate mail will get past it.

```
:0 Wh: msgid.lock
| formail -D 8192 msgid.cache
```

```

```

Beware if you have delivery problems in recipes below this one and procmail tries to requeue the mail, then on the next queue run, this mail will be considered a duplicate and will be thrown away. For those not quite so confident in their own scripting capabilities, you can use the following recipe instead. It puts duplicates in a separate folder instead of throwing them away. It is up to you to periodically empty the folder of course.

```
:0 Whc: msgid.lock
| formail -D 8192 msgid.cache
:0 a:
duplicates
```

```

```

Procmail can deliver to MH folders directly, but, it does not update the unseen sequences the real MH manages. If you want procmail to update those as well, use a recipe like the following which will file everything that contains the word spam in the body of the mail into an MH folder called spamfold. Note the local lockfile, which is needed because MH programs do not lock the sequences file. Asynchronous invocations of MH programs that change the sequences file may therefore corrupt it or silently lose changes. Unfortunately, the lockfile doesn't completely solve the problem as rcvstore could be invoked while `show' or `mark' or some other MH program is running. This problem is expected to be fixed in some future version of MH, but until then, you'll have to balance the risk of lost or corrupt sequences against the benefits of the unseen sequence.

```
:0 :spamfold/$LOCKEXT
* B ?? spam
| rcvstore +spamfold
```

```

```

When delivering to emacs folders (i.e., mailfolders managed by any emacs mail package, e.g., RMAIL or VM) directly, you should use emacs-compatible lockfiles. The emacs mailers are a bit braindamaged in that respect, they get very upset if someone delivers to mailfolders which they already have in their internal buffers. The following recipe assumes that $HOME equals /home/john.

```
MAILDIR=Mail
:0:/usr/local/lib/emacs/lock/!home!john!Mail!mailbox
* ^Subject:.*whatever
mailbox
```

```

```

Alternatively, you can have procmail deliver into its own set of mailboxes, which you then periodically empty and copy over to your emacs files using movemail. Movemail uses mailbox.lock local lockfiles per mailbox. This actually is the preferred mode of operation in conjunction with procmail.

To extract certain headers from a mail and put them into environment variables you can use any of the following constructs:

```
SUBJECT=`formail -xSubject:`    # regular field
FROM=`formail -rt -xTo:`        # special case
:0 h                            # alternate method
KEYWORDS=| formail -xKeywords:
```

```

```

If you are using temporary files in a procmailrc file, and want to make sure that they are removed just before procmail exits, you could use something along the lines of:

```
TEMPORARY=$HOME/tmp/pmail.$$
TRAP="/bin/rm -f $TEMPORARY"
```

```

```

The TRAP keyword can also be used to change the exitcode of procmail. I.e. if you want procmail to return an exitcode of `1' instead of its regular exitcodes, you could use:

```
EXITCODE=""
TRAP="exit 1;"   # The trailing semi-colon is important

                 # since exit is not a standalone program
```

```

```

Or, if the exitcode does not need to depend on the programs run from the TRAP, you can use a mere:

```
EXITCODE=1
```

```

```

The following recipe prints every incoming mail that looks like a postscript file.

```
:0 Bb
* ^^%!
| lpr
```

```

```

The following recipe does the same, but is a bit more selective. It only prints the postscript file if it comes from the print-server. The first condition matches only if it is found in the header. The second condition only matches at the start of the body.

```
:0 b
* ^From[ :].*print-server
* B ?? ^^%!
| lpr
```

```

```

The same as above, but now by slightly different means:

```
:0
* ^From[ :].*print-server
{

  :0 B b

  * ^^%!

  | lpr
}
```

```

```

Likewise:

```
:0 HB b
* ^^(.+$)*From[ :].*print-server
* ^^(.+$)*^%!
| lpr
```

```

```

Suppose you have two accounts, you use both accounts regularly, but they are in very distinct places (i.e., you can only read mail that arrived at either one of the accounts). You would like to forward mail arriving at account one to account two, and the other way around. The first thing that comes to mind is using .forward files at both sites; this won't work of course, since you will be creating a mail loop. This mail loop can be avoided by inserting the following recipe in front of all other recipes in the $HOME/.procmailrc files on both sites. If you make sure that you add the same X-Loop: field at both sites, mail can now safely be forwarded to the other account from either of them.

```
:0 c
* !^X-Loop: yourname@your.main.mail.address
| formail -A "X-Loop: yourname@your.main.mail.address" | \

   $SENDMAIL -oi yourname@the.other.account
```

```

```

If someone sends you a mail with the word `retrieve' in the subject, the following will automatically send back the contents of info_file to the sender. Like in all recipes where we send mail, we watch out for mail loops.

```
:0
* !^From +YOUR_USERNAME
* !^Subject:.*Re:
* !^FROM_DAEMON
* ^Subject:.*retrieve
| (formail -r ; cat info_file) | $SENDMAIL -oi -t
```

```

```

Now follows an example for a very simple fileserver accessible by mail. For more demanding applications, I suggest you take a look at SmartList (available from the same place as the procmail distribution). As listed, this fileserver sends back at most one file per request, it ignores the body of incoming mails, the Subject: line has to look like "Subject: send file the_file_you_want" (the blanks are significant), it does not return files that have names starting with a dot, nor does it allow files to be retrieved that are outside the fileserver directory tree (if you decide to munge this example, make sure you do not inadvertently loosen this last restriction).

```
:0
* ^Subject: send file [0-9a-z]
* !^X-Loop: yourname@your.main.mail.address
* !^Subject:.*Re:
* !^FROM_DAEMON
* !^Subject: send file .*[/.]\.
{

  MAILDIR=$HOME/fileserver # chdir to the fileserver directory

  :0 fhw                   # reverse mailheader and extract name

  * ^Subject: send file \/[^ ]*

  | formail -rA "X-Loop: yourname@your.main.mail.address"

  FILE="$MATCH"            # the requested filename

  :0 ah

  | cat - ./$FILE 2>&1 | $SENDMAIL -oi -t
}
```

```

```

The following example preconverts all plain-text mail arriving in certain encoded MIME formats into a more compact 8-bit format which can be used and displayed more easily by most programs. The mimencode(1) program is part of Nathaniel Borenstein's metamail package.

```
:0
* ^Content-Type: *text/plain
{

  :0 fbw

  * ^Content-Transfer-Encoding: *quoted-printable

  | mimencode -u -q

     :0 Afhw

     | formail -I "Content-Transfer-Encoding: 8bit"

  :0 fbw

  * ^Content-Transfer-Encoding: *base64

  | mimencode -u -b

     :0 Afhw

     | formail -I "Content-Transfer-Encoding: 8bit"
}
```

```

```

The following one is rather exotic, but it only serves to demonstrate a feature. Suppose you have a file in your HOME directory called ".urgent", and the (one) person named in that file is the sender of an incoming mail, you'd like that mail to be stored in $MAILDIR/urgent instead of in any of the normal mailfolders it would have been sorted in. Then this is what you could do (beware, the filelength of $HOME/.urgent should be well below $LINEBUF, increase LINEBUF if necessary):

```
URGMATCH=`cat $HOME/.urgent`
:0:
* $^From.*${URGMATCH}
urgent
```

```

```

An entirely different application for procmail would be to conditionally apply filters to a certain (outgoing) text or mail. A typical example would be a filter through which you pipe all outgoing mail, in order to make sure that it will be MIME encoded only if it needs to be. I.e. in this case you could start procmail in the middle of a pipe like:

```
cat newtext | procmail ./mimeconvert | mail chris@where.ever
```

```

```

The mimeconvert rcfile could contain something like (the =0x80= and =0xff= should be substituted with the real 8-bit characters):

```
DEFAULT=|     # pipe to stdout instead of

              # delivering mail as usual
:0 Bfbw
* [=0x80=-=0xff=]
| mimencode -q

  :0 Afhw

  | formail -I 'MIME-Version: 1.0' \

     -I 'Content-Type: text/plain; charset=ISO-8859-1' \

     -I 'Content-Transfer-Encoding: quoted-printable'
```

```

```

## SEE ALSO
procmail(1), procmailrc(5), procmailsc(5), sh(1), csh(1), mail(1), mailx(1), uucp(1), aliases(5), sendmail(8), egrep(1), grep(1), biff(1), comsat(8), mimencode(1), lockfile(1), formail(1)

## AUTHORS
Stephen R. van den Berg

```
<srb@cuci.nl>
```

```

```

Philip A. Guenther

```
<guenther@sendmail.com>
```

```

```


procmailrc

title: procmailrc(5)

text:
# procmailrc(5)

## NAME
procmailrc - procmail rcfile

## SYNOPSIS
$HOME/.procmailrc

## DESCRIPTION
For a quick start, see NOTES at the end of the procmail(1) man page.

The rcfile can contain a mixture of environment variable assignments (some of which have special meanings to procmail), and recipes. In their most simple appearance, the recipes are simply one line regular expressions that are searched for in the header of the arriving mail. The first recipe that matches is used to determine where the mail has to go (usually a file). If processing falls off the end of the rcfile, procmail will deliver the mail to $DEFAULT.

There are two kinds of recipes: delivering and non-delivering recipes. If a delivering recipe is found to match, procmail considers the mail (you guessed it) delivered and will cease processing the rcfile after having successfully executed the action line of the recipe. If a non-delivering recipe is found to match, processing of the rcfile will continue after the action line of this recipe has been executed.

Delivering recipes are those that cause header and/or body of the mail to be: written into a file, absorbed by a program or forwarded to a mailaddress.

Non-delivering recipes are: those that cause the output of a program or filter to be captured back by procmail or those that start a nesting block.

You can tell procmail to treat a delivering recipe as if it were a non-delivering recipe by specifying the `c' flag on such a recipe. This will make procmail generate a carbon copy of the mail by delivering it to this recipe, yet continue processing the rcfile.

By using any number of recipes you can presort your mail extremely straightforward into several mailfolders. Bear in mind though that the mail can arrive concurrently in these mailfolders (if several procmail programs happen to run at the same time, not unlikely if a lot of mail arrives). To make sure this does not result in a mess, proper use of lockfiles is highly recommended.

The environment variable assignments and recipes can be freely intermixed in the rcfile. If any environment variable has a special meaning to procmail, it will be used appropriately the moment it is parsed (i.e., you can change the current directory whenever you want by specifying a new MAILDIR, switch lockfiles by specifying a new LOCKFILE, change the umask at any time, etc., the possibilities are endless :-).

The assignments and substitutions of these environment variables are handled exactly like in sh(1) (that includes all possible quotes and escapes), with the added bonus that blanks around the '=' sign are ignored and that, if an environment variable appears without a trailing '=', it will be removed from the environment. Any program in backquotes started by procmail will have the entire mail at its stdin.

### Comments
A word beginning with # and all the following characters up to a NEWLINE are ignored. This does not apply to condition lines, which cannot be commented.

### Recipes
A line starting with ':' marks the beginning of a recipe. It has the following format:

```
:0 [flags] [ : [locallockfile] ]
<zero or more conditions (one per line)>
<exactly one action line>
```

```

```

Conditions start with a leading `*', everything after that character is passed on to the internal egrep literally, except for leading and trailing whitespace. These regular expressions are completely compatible to the normal egrep(1) extended regular expressions. See also Extended regular expressions.

Conditions are anded; if there are no conditions the result will be true by default.

Flags can be any of the following:

H

Egrep the header (default).

B

Egrep the body.

D

Tell the internal egrep to distinguish between upper and lower case (contrary to the default which is to ignore case).

A

This recipe will not be executed unless the conditions on the last preceding recipe (on the current block-nesting level) without the `A' or `a' flag matched as well. This allows you to chain actions that depend on a common condition.

a

Has the same meaning as the `A' flag, with the additional condition that the immediately preceding recipe must have been successfully completed before this recipe is executed.

E

This recipe only executes if the immediately preceding recipe was not executed. Execution of this recipe also disables any immediately following recipes with the 'E' flag. This allows you to specify `else if' actions.

e

This recipe only executes if the immediately preceding recipe failed (i.e., the action line was attempted, but resulted in an error).

h

Feed the header to the pipe, file or mail destination (default).

b

Feed the body to the pipe, file or mail destination (default).

f

Consider the pipe as a filter.

c

Generate a carbon copy of this mail. This only makes sense on delivering recipes. The only non-delivering recipe this flag has an effect on is on a nesting block, in order to generate a carbon copy this will clone the running procmail process (lockfiles will not be inherited), whereby the clone will proceed as usual and the parent will jump across the block.

w

Wait for the filter or program to finish and check its exitcode (normally ignored); if the filter is unsuccessful, then the text will not have been filtered.

W

Has the same meaning as the `w' flag, but will suppress any `Program failure' message.

i

Ignore any write errors on this recipe (i.e., usually due to an early closed pipe).

r

Raw mode, do not try to ensure the mail ends with an empty line, write it out as is.

There are some special conditions you can use that are not straight regular expressions. To select them, the condition must start with:

!

Invert the condition.

$

Evaluate the remainder of this condition according to sh(1) substitution rules inside double quotes, skip leading whitespace, then reparse it.

?

Use the exitcode of the specified program.

<

Check if the total length of the mail is shorter than the specified (in decimal) number of bytes.

>

Analogous to '<'.

variablename ??

Match the remainder of this condition against the value of this environment variable (which cannot be a pseudo variable). A special case is if variablename is equal to `B', `H', `HB' or `BH'; this merely overrides the default header/body search area defined by the initial flags on this recipe.

\

To quote any of the above at the start of the line.

### Local lockfile
If you put a second (trailing) ':' on the first recipe line, then procmail will use a locallockfile (for this recipe only). You can optionally specify the locallockfile to use; if you don't however, procmail will use the destination filename (or the filename following the first '>>') and will append $LOCKEXT to it.

### Recipe action line
The action line can start with the following characters:

!

Forwards to all the specified mail addresses.

|

Starts the specified program, possibly in $SHELL if any of the characters $SHELLMETAS are spotted. You can optionally prepend this pipe symbol with variable=, which will cause stdout of the program to be captured in the environment variable (procmail will not terminate processing the rcfile at this point). If you specify just this pipe symbol, without any program, then procmail will pipe the mail to stdout.

{

Followed by at least one space, tab or newline will mark the start of a nesting block. Everything up till the next closing brace will depend on the conditions specified for this recipe. Unlimited nesting is permitted. The closing brace exists merely to delimit the block, it will not cause procmail to terminate in any way. If the end of a block is reached processing will continue as usual after the block. On a nesting block, the flags `H' and `B' only affect the conditions leading up to the block, the flags `h' and `b' have no effect whatsoever.

Anything else will be taken as a mailbox name (either a filename or a directory, absolute or relative to the current directory (see MAILDIR)). If it is a (possibly yet nonexistent) filename, the mail will be appended to it.

If it is a directory, the mail will be delivered to a newly created, guaranteed to be unique file named $MSGPREFIX* in the specified directory. If the mailbox name ends in "/.", then this directory is presumed to be an MH folder; i.e., procmail will use the next number it finds available. If the mailbox name ends in "/", then this directory is presumed to be a maildir folder; i.e., procmail will deliver the message to a file in a subdirectory named "tmp" and rename it to be inside a subdirectory named "new". If the mailbox is specified to be an MH folder or maildir folder, procmail will create the necessary directories if they don't exist, rather than treat the mailbox as a non-existent filename. When procmail is delivering to directories, you can specify multiple directories to deliver to (procmail will do so utilising hardlinks).

### Environment variable defaults
LOGNAME, HOME and SHELL

Your (the recipient's) defaults

PATH

$HOME/bin :/bin :/usr/bin :/usr/local/bin (Except during the processing of an /etc/procmailrc file, when it will be set to `/bin :/usr/bin :/usr/local/bin'.)

SHELLMETAS

& |<>~;?*[

SHELLFLAGS

-c

ORGMAIL

/var/spool/mail/$LOGNAME

(Unless -m has been specified, in which case it is unset)

MAILDIR

$HOME

(Unless the name of the first successfully opened rcfile starts with `./' or if -m has been specified, in which case it defaults to `.')

DEFAULT

$ORGMAIL

MSGPREFIX

msg.

SENDMAIL

/usr/sbin/sendmail

SENDMAILFLAGS

-oi

HOST

The current hostname

COMSAT

no

(If an rcfile is specified on the command line)

PROCMAIL_VERSION

3.22

LOCKEXT

.lock

Other cleared or preset environment variables are IFS, ENV and PWD.

For security reasons, upon startup procmail will wipe out all environment variables that are suspected of modifying the behavior of the runtime linker.

### Environment
Before you get lost in the multitude of environment variables, keep in mind that all of them have reasonable defaults.

MAILDIR

Current directory while procmail is executing (that means that all paths are relative to $MAILDIR).

DEFAULT

Default mailbox file (if not told otherwise, procmail will dump mail in this mailbox). Procmail will automatically use $DEFAULT$LOCKEXT as lockfile prior to writing to this mailbox. You do not need to set this variable, since it already points to the standard system mailbox.

LOGFILE

This file will also contain any error or diagnostic messages from procmail (normally none :-) or any other programs started by procmail. If this file is not specified, any diagnostics or error messages will be mailed back to the sender. See also LOGABSTRACT.

VERBOSE

You can turn on extended diagnostics by setting this variable to `yes' or `on', to turn it off again set it to `no' or `off'.

LOGABSTRACT

Just before procmail exits it logs an abstract of the delivered message in $LOGFILE showing the `From ' and `Subject:' fields of the header, what folder it finally went to and how long (in bytes) the message was. By setting this variable to `no', generation of this abstract is suppressed. If you set it to `all', procmail will log an abstract for every successful delivering recipe it processes.

LOG

Anything assigned to this variable will be appended to $LOGFILE.

ORGMAIL

Usually the system mailbox (ORiGinal MAILbox). If, for some obscure reason (like `filesystem full') the mail could not be delivered, then this mailbox will be the last resort. If procmail fails to save the mail in here (deep, deep trouble :-), then the mail will bounce back to the sender.

LOCKFILE

Global semaphore file. If this file already exists, procmail will wait until it has gone before proceeding, and will create it itself (cleaning it up when ready, of course). If more than one lockfile are specified, then the previous one will be removed before trying to create the new one. The use of a global lockfile is discouraged, whenever possible use locallockfiles (on a per recipe basis) instead.

LOCKEXT

Default extension that is appended to a destination file to determine what local lockfile to use (only if turned on, on a per-recipe basis).

LOCKSLEEP

Number of seconds procmail will sleep before retrying on a lockfile (if it already existed); if not specified, it defaults to 8 seconds.

LOCKTIMEOUT

Number of seconds that have to have passed since a lockfile was last modified/created before procmail decides that this must be an erroneously leftover lockfile that can be removed by force now. If zero, then no timeout will be used and procmail will wait forever until the lockfile is removed; if not specified, it defaults to 1024 seconds. This variable is useful to prevent indefinite hangups of sendmail/procmail. Procmail is immune to clock skew across machines.

TIMEOUT

Number of seconds that have to have passed before procmail decides that some child it started must be hanging. The offending program will receive a TERMINATE signal from procmail, and processing of the rcfile will continue. If zero, then no timeout will be used and procmail will wait forever until the child has terminated; if not specified, it defaults to 960 seconds.

MSGPREFIX

Filename prefix that is used when delivering to a directory (not used when delivering to a maildir or an MH directory).

HOST

If this is not the hostname of the machine, processing of the current rcfile will immediately cease. If other rcfiles were specified on the command line, processing will continue with the next one. If all rcfiles are exhausted, the program will terminate, but will not generate an error (i.e., to the mailer it will seem that the mail has been delivered).

UMASK

The name says it all (if it doesn't, then forget about this one :-). Anything assigned to UMASK is taken as an octal number. If not specified, the umask defaults to 077. If the umask permits o+x, all the mailboxes procmail delivers to directly will receive an o+x mode change. This can be used to check if new mail arrived.

SHELLMETAS

If any of the characters in SHELLMETAS appears in the line specifying a filter or program, the line will be fed to $SHELL instead of being executed directly.

SHELLFLAGS

Any invocation of $SHELL will be like:

"$SHELL" "$SHELLFLAGS" "$*";

SENDMAIL

If you're not using the forwarding facility don't worry about this one. It specifies the program being called to forward any mail.

It gets invoked as: "$SENDMAIL" $SENDMAILFLAGS "$@";

NORESRETRY

Number of retries that are to be made if any `process table full', `file table full', `out of memory' or `out of swap space' error should occur. If this number is negative, then procmail will retry indefinitely; if not specified, it defaults to 4 times. The retries occur with a $SUSPEND second interval. The idea behind this is that if, e.g., the swap space has been exhausted or the process table is full, usually several other programs will either detect this as well and abort or crash 8-), thereby freeing valuable resources for procmail.

SUSPEND

Number of seconds that procmail will pause if it has to wait for something that is currently unavailable (memory, fork, etc.); if not specified, it will default to 16 seconds. See also: LOCKSLEEP.

LINEBUF

Length of the internal line buffers, cannot be set smaller than 128. All lines read from the rcfile should not exceed $LINEBUF characters before and after expansion. If not specified, it defaults to 2048. This limit, of course, does not apply to the mail itself, which can have arbitrary line lengths, or could be a binary file for that matter. See also PROCMAIL_OVERFLOW.

DELIVERED

If set to `yes' procmail will pretend (to the mail agent) the mail has been delivered. If mail cannot be delivered after having met this assignment (set to `yes'), the mail will be lost (i.e., it will not bounce).

TRAP

When procmail terminates of its own accord and not because it received a signal, it will execute the contents of this variable. A copy of the mail can be read from stdin. Any output produced by this command will be appended to $LOGFILE. Possible uses for TRAP are: removal of temporary files, logging customised abstracts, etc. See also EXITCODE and LOGABSTRACT.

EXITCODE

By default, procmail returns an exitcode of zero (success) if it successfully delivered the message or if the HOST variable was misset and there were no more rcfiles on the command line; otherwise it returns failure. Before doing so, procmail examines the value of this variable. If it is set to a positive numeric value, procmail will instead use that value as its exitcode. If this variable is set but empty and TRAP is set, procmail will set the exitcode to whatever the TRAP program returns. If this variable is not set, procmail will set it shortly before calling up the TRAP program.

LASTFOLDER

This variable is assigned to by procmail whenever it is delivering to a folder or program. It always contains the name of the last file (or program) procmail delivered to. If the last delivery was to several directory folders together then $LASTFOLDER will contain the hardlinked filenames as a space separated list.

MATCH

This variable is assigned to by procmail whenever it is told to extract text from a matching regular expression. It will contain all text matching the regular expression past the `\/' token.

SHIFT

Assigning a positive value to this variable has the same effect as the `shift' command in sh(1). This command is most useful to extract extra arguments passed to procmail when acting as a generic mailfilter.

INCLUDERC

Names an rcfile (relative to the current directory) which will be included here as if it were part of the current rcfile. Nesting is permitted and only limited by systems resources (memory and file descriptors). As no checking is done on the permissions or ownership of the rcfile, users of INCLUDERC should make sure that only trusted users have write access to the included rcfile or the directory it is in. Command line assignments to INCLUDERC have no effect.

SWITCHRC

Names an rcfile (relative to the current directory) to which processing will be switched. If the named rcfile doesn't exist or is not a normal file or /dev/null then an error will be logged and processing will continue in the current rcfile. Otherwise, processing of the current rcfile will be aborted and the named rcfile started. Unsetting SWITCHRC aborts processing of the current rcfile as if it had ended at the assignment. As with INCLUDERC, no checking is done on the permissions or ownership of the rcfile and command line assignments have no effect.

PROCMAIL_VERSION

The version number of the running procmail binary.

PROCMAIL_OVERFLOW

This variable will be set to a non-empty value if procmail detects a buffer overflow. See the BUGS section below for other details of operation when overflow occurs.

COMSAT

Comsat(8)/biff(1) notification is on by default, it can be turned off by setting this variable to `no'. Alternatively the biff-service can be customised by setting it to either `service@', `@hostname', or `service@hostname'. When not specified it defaults to biff@localhost.

DROPPRIVS

If set to `yes' procmail will drop all privileges it might have had (suid or sgid). This is only useful if you want to guarantee that the bottom half of the /etc/procmailrc file is executed on behalf of the recipient.

### Extended regular expressions
The following tokens are known to both the procmail internal egrep and the standard egrep(1) (beware that some egrep implementations include other non-standard extensions; in particular, the repetition operator { is not supported by procmail's egrep):

^

Start of a line.

$

End of a line.

.

Any character except a newline.

a*

Any sequence of zero or more a's.

a+

Any sequence of one or more a's.

a?

Either zero or one a.

[^-a-d]

Any character which is not either a dash, a, b, c, d or newline.

de|abc

Either the sequence `de' or `abc'.

(abc)*

Zero or more times the sequence `abc'.

\.

Matches a single dot; use \ to quote any of the magic characters to get rid of their special meaning. See also $\ variable substitution.

These were only samples, of course, any more complex combination is valid as well.

The following token meanings are special procmail extensions:

^ or $

Match a newline (for multiline matches).

^^

Anchor the expression at the very start of the search area, or if encountered at the end of the expression, anchor it at the very end of the search area.

\< or \>

Match the character before or after a word. They are merely a shorthand for `[^a-zA-Z0-9_]', but can also match newlines. Since they match actual characters, they are only suitable to delimit words, not to delimit inter-word space.

\/

Splits the expression in two parts. Everything matching the right part will be assigned to the MATCH environment variable.

## EXAMPLES
Look in the procmailex(5) man page.

## CAVEATS
Continued lines in an action line that specifies a program always have to end in a backslash, even if the underlying shell would not need or want the backslash to indicate continuation. This is due to the two pass parsing process needed (first procmail, then the shell (or not, depending on SHELLMETAS)).

Don't put comments on the regular expression condition lines in a recipe, these lines are fed to the internal egrep literally (except for continuation backslashes at the end of a line).

Leading whitespace on continued regular expression condition lines is usually ignored (so that they can be indented), but not on continued condition lines that are evaluated according to the sh(1) substitution rules inside double quotes.

Watch out for deadlocks when doing unhealthy things like forwarding mail to your own account. Deadlocks can be broken by proper use of LOCKTIMEOUT.

Any default values that procmail has for some environment variables will always override the ones that were already defined. If you really want to override the defaults, you either have to put them in the rcfile or on the command line as arguments.

The /etc/procmailrc file cannot change the PATH setting seen by user rcfiles as the value is reset when procmail finishes the /etc/procmailrc file. While future enhancements are expected in this area, recompiling procmail with the desired value is currently the only correct solution.

Environment variables set inside the shell-interpreted-`|' action part of a recipe will not retain their value after the recipe has finished since they are set in a subshell of procmail. To make sure the value of an environment variable is retained you have to put the assignment to the variable before the leading `|' of a recipe, so that it can capture stdout of the program.

If you specify only a `h' or a `b' flag on a delivering recipe, and the recipe matches, then, unless the `c' flag is present as well, the body respectively the header of the mail will be silently lost.

## SEE ALSO
procmail(1), procmailsc(5), procmailex(5), sh(1), csh(1), mail(1), mailx(1), uucp(1), aliases(5), sendmail(8), egrep(1), regexp(5), grep(1), biff(1), comsat(8), lockfile(1), formail(1)

## BUGS
The only substitutions of environment variables that can be handled by procmail itself are of the type $name, ${name}, ${name:-text}, ${name:+text}, ${name-text}, ${name+text}, $\name, $#, $n, $$, $?, $_, $- and $=; whereby $\name will be substituted by the all-magic-regular-expression-characters-disarmed equivalent of $name, $_ by the name of the current rcfile, $- by $LASTFOLDER and $= will contain the score of the last recipe. Furthermore, the result of $\name substitution will never be split on whitespace. When the -a or -m options are used, $# will expand to the number of arguments so specified and "$@" (the quotes are required) will expand to the specified arguments. However, "$@" will only be expanded when used in the argument list to a program, and then only one such occurrence will be expanded.

Unquoted variable expansions performed by procmail are always split on space, tab, and newline characters; the IFS variable is not used internally.

Procmail does not support the expansion of `~'.

A line buffer of length $LINEBUF is used when processing the rcfile, any expansions that don't fit within this limit will be truncated and PROCMAIL_OVERFLOW will be set. If the overflowing line is a condition or an action line, then it will be considered failed and procmail will continue processing. If it is a variable assignment or recipe start line then procmail will abort the entire rcfile.

If the global lockfile has a relative path, and the current directory is not the same as when the global lockfile was created, then the global lockfile will not be removed if procmail exits at that point (remedy: use absolute paths to specify global lockfiles).

If an rcfile has a relative path and when the rcfile is first opened MAILDIR contains a relative path, and if at one point procmail is instructed to clone itself and the current directory has changed since the rcfile was opened, then procmail will not be able to clone itself (remedy: use an absolute path to reference the rcfile or make sure MAILDIR contains an absolute path as the rcfile is opened).

A locallockfile on the recipe that marks the start of a non-forking nested block does not work as expected.

When capturing stdout from a recipe into an environment variable, exactly one trailing newline will be stripped.

Some non-optimal and non-obvious regexps set MATCH to an incorrect value. The regexp can be made to work by removing one or more unneeded '*', '+', or '?' operator on the left-hand side of the \/ token.

## MISCELLANEOUS
If the regular expression contains `^TO_' it will be substituted by `(^((Original-)?(Resent-)?(To |Cc |Bcc) |(X-Envelope |Apparently(-Resent)?)-To) :(.*[^-a-zA-Z0-9_.])?)', which should catch all destination specifications containing a specific address.

If the regular expression contains `^TO' it will be substituted by `(^((Original-)?(Resent-)?(To |Cc |Bcc) |(X-Envelope |Apparently(-Resent)?)-To) :(.*[^a-zA-Z])?)', which should catch all destination specifications containing a specific word.

If the regular expression contains `^FROM_DAEMON' it will be substituted by `(^(Mailing-List : |Precedence :.*(junk |bulk |list) |To : Multiple recipients of |(((Resent-)?(From |Sender) |X-Envelope-From) : |>?From )([^>]*[^(.%@a-z0-9])?(Post(ma?(st(e?r)? |n) |office) |(send)?Mail(er)? |daemon |m(mdf |ajordomo) |n?uucp |LIST(SERV |proc) |NETSERV |o(wner |ps) |r(e(quest |sponse) |oot) |b(ounce |bs\.smtp) |echo |mirror |s(erv(ices? |er) |mtp(error)? |ystem) |A(dmin(istrator)? |MMGR |utoanswer))(([^).! :a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>] |$)))', which should catch mails coming from most daemons (how's that for a regular expression :-).

If the regular expression contains `^FROM_MAILER' it will be substituted by `(^(((Resent-)?(From |Sender) |X-Envelope-From) : |>?From )([^>]*[^(.%@a-z0-9])?(Post(ma(st(er)? |n) |office) |(send)?Mail(er)? |daemon |mmdf |n?uucp |ops |r(esponse |oot) |(bbs\.)?smtp(error)? |s(erv(ices? |er) |ystem) |A(dmin(istrator)? |MMGR))(([^).! :a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>] |$))' (a stripped down version of `^FROM_DAEMON'), which should catch mails coming from most mailer-daemons.

When assigning boolean values to variables like VERBOSE, DELIVERED or COMSAT, procmail accepts as true every string starting with: a non-zero value, `on', `y', `t' or `e'. False is every string starting with: a zero value, `off', `n', `f' or `d'.

If the action line of a recipe specifies a program, a sole backslash-newline pair in it on an otherwise empty line will be converted into a newline.

The regular expression engine built into procmail does not support named character classes.

## NOTES
Since unquoted leading whitespace is generally ignored in the rcfile you can indent everything to taste.

The leading `|' on the action line to specify a program or filter is stripped before checking for $SHELLMETAS.

Files included with the INCLUDERC directive containing only environment variable assignments can be shared with sh.

The current behavior of assignments on the command line to INCLUDERC and SWITCHRC is not guaranteed, has been changed once already, and may be changed again or removed in future releases.

For really complicated processing you can even consider calling procmail recursively.

In the old days, the `:0' that marks the beginning of a recipe, had to be changed to `:n', whereby `n' denotes the number of conditions that follow.

## AUTHORS
Stephen R. van den Berg

```
<srb@cuci.nl>
```

```

```

Philip A. Guenther

```
<guenther@sendmail.com>
```

```

```


procmailsc

title: procmailsc(5)

text:
# procmailsc(5)

## NAME
procmailsc - procmail weighted scoring technique

## SYNOPSIS
[*] w^x condition

## DESCRIPTION
In addition to the traditional true or false conditions you can specify on a recipe, you can use a weighted scoring technique to decide if a certain recipe matches or not. When weighted scoring is used in a recipe, then the final score for that recipe must be positive for it to match.

A certain condition can contribute to the score if you allocate it a `weight' (w) and an `exponent' (x). You do this by preceding the condition (on the same line) with:

```
w^x
```

```

```

Whereas both w and x are real numbers between -2147483647.0 and 2147483647.0 inclusive.

## Weighted regular expression conditions
The first time the regular expression is found, it will add w to the score. The second time it is found, w*x will be added. The third time it is found, w*x*x will be added. The fourth time w*x*x*x will be added. And so forth.

This can be described by the following concise formula:

```
                     n

     n   k-1        x - 1
w * Sum x    = w * -------

    k=1             x - 1
```

```

```

It represents the total added score for this condition if n matches are found.

Note that the following case distinctions can be made:

x=0

Only the first match will contribute w to the score. Any subsequent matches are ignored.

x=1

Every match will contribute the same w to the score. The score grows linearly with the number of matches found.

0<x<1

Every match will contribute less to the score than the previous one. The score will asymptotically approach a certain value (see the NOTES section below).

1<x

Every match will contribute more to the score than the previous one. The score will grow exponentially.

x<0

Can be utilised to favour odd or even number of matches.

If the regular expression is negated (i.e., matches if it isn't found), then n obviously can either be zero or one.

## Weighted program conditions
If the program returns an exitcode of EXIT_SUCCESS (=0), then the total added score will be w. If it returns any other exitcode (indicating failure), the total added score will be x.

If the exitcode of the program is negated, then, the exitcode will be considered as if it were a virtual number of matches. Calculation of the added score then proceeds as if it had been a normal regular expression with n=`exitcode' matches.

## Weighted length conditions
If the length of the actual mail is M then:

```
* w^x  > L
```

```

```

will generate an additional score of:

```
           x

    /  M  \
w * | --- |

    \  L  /
```

```

```

And:

```
* w^x  < L
```

```

```

will generate an additional score of:

```
           x

    /  L  \
w * | --- |

    \  M  /
```

```

```

In both cases, if L=M, this will add w to the score. In the former case however, larger mails will be favoured, in the latter case, smaller mails will be favoured. Although x can be varied to fine-tune the steepness of the function, typical usage sets x=1.

## MISCELLANEOUS
You can query the final score of all the conditions on a recipe from the environment variable $=. This variable is set every time just after procmail has parsed all conditions on a recipe (even if the recipe is not being executed).

## EXAMPLES
The following recipe will ditch all mails having more than 150 lines in the body. The first condition contains an empty regular expression which, because it always matches, is used to give our score a negative offset. The second condition then matches every line in the mail, and consumes up the previous negative offset we gave (one point per line). In the end, the score will only be positive if the mail contained more than 150 lines.

```
:0 Bh
* -150^0
*    1^1  ^.*$
/dev/null
```

```

```

Suppose you have a priority folder which you always read first. The next recipe picks out the priority mail and files them in this special folder. The first condition is a regular one, i.e., it doesn't contribute to the score, but simply has to be satisfied. The other conditions describe things like: john and claire usually have something important to say, meetings are usually important, replies are favoured a bit, mails about Elvis (this is merely an example :-) are favoured (the more he is mentioned, the more the mail is favoured, but the maximum extra score due to Elvis will be 4000, no matter how often he is mentioned), lots of quoted lines are disliked, smileys are appreciated (the score for those will reach a maximum of 3500), those three people usually don't send interesting mails, the mails should preferably be small (e.g., 2000 bytes long mails will score -100, 4000 bytes long mails do -800). As you see, if some of the uninteresting people send mail, then the mail still has a chance of landing in the priority folder, e.g., if it is about a meeting, or if it contains at least two smileys.

```
:0 HB
*         !^Precedence:.*(junk|bulk)
* 2000^0   ^From:.*(john@home|claire@work)
* 2000^0   ^Subject:.*meeting
*  300^0   ^Subject:.*Re:
* 1000^.75 elvis|presley
* -100^1   ^>
*  350^.9  :-\)
* -500^0   ^From:.*(boss|jane|henry)@work
* -100^3   > 2000
priority_folder
```

```

```

If you are subscribed to a mailinglist, and just would like to read the quality mails, then the following recipes could do the trick. First we make sure that the mail is coming from the mailinglist. Then we check if it is from certain persons of whom we value the opinion, or about a subject we absolutely want to know everything about. If it is, file it. Otherwise, check if the ratio of quoted lines to original lines is at most 1:2. If it exceeds that, ditch the mail. Everything that survived the previous test, is filed.

```
:0
^From mailinglist-request@some.where
{

  :0:

  * ^(From:.*(paula|bill)|Subject:.*skiing)

  mailinglist

  :0 Bh

  *  20^1 ^>

  * -10^1 ^[^>]

  /dev/null

  :0:

  mailinglist
}
```

```

```

For further examples you should look in the procmailex(5) man page.

## CAVEATS
Because this speeds up the search by an order of magnitude, the procmail internal egrep will always search for the leftmost shortest match, unless it is determining what to assign to MATCH, in which case it searches the leftmost longest match. E.g. for the leftmost shortest match, by itself, the regular expression:

.*

will always match a zero length string at the same spot.

.+

will always match one character (except newlines of course).

## SEE ALSO
procmail(1), procmailrc(5), procmailex(5), sh(1), csh(1), egrep(1), grep(1),

## BUGS
If, in a length condition, you specify an x that causes an overflow, procmail is at the mercy of the pow(3) function in your mathematical library.

Floating point numbers in `engineering' format (e.g., 12e5) are not accepted.

## MISCELLANEOUS
As soon as `plus infinity' (2147483647) is reached, any subsequent weighted conditions will simply be skipped.

As soon as `minus infinity' (-2147483647) is reached, the condition will be considered as `no match' and the recipe will terminate early.

## NOTES
If in a regular expression weighted formula 0<x<1, the total added score for this condition will asymptotically approach:

```
   w
-------

 1 - x
```

```

```

In order to reach half the maximum value you need

```
     - ln 2
n = --------

       ln x
```

```

```

matches.

## AUTHORS
Stephen R. van den Berg

```
<srb@cuci.nl>
```

```

```

Philip A. Guenther

```
<guenther@sendmail.com>
```

```

```


sysctl.conf

package: procps

title: sysctl.conf(5)

summary: sysctl preload/configuration file

text:
# sysctl.conf(5)

## NAME
sysctl.conf - sysctl preload/configuration file

## DESCRIPTION
sysctl.conf is a simple file containing sysctl values to be read in and set by sysctl. The syntax is simply as follows:

```
# comment
; comment
token = value
```

Note that blank lines are ignored, and whitespace before and after a token or value is ignored, although a value can contain whitespace within. Lines which begin with a # or ; are considered comments and ignored.

If a line begins with a single -, any attempts to set the value that fail will be ignored.

## NOTES
As the /etc/sysctl.conf file is used to override default kernel parameter values, only a small number of parameters is predefined in the file. Use /sbin/sysctl -a or follow sysctl(8) to list all possible parameters. The description of individual parameters can be found in the kernel documentation.

## EXAMPLE

```
# sysctl.conf sample
#

  kernel.domainname = example.com
; this one has a space which will be written to the sysctl!

  kernel.modprobe = /sbin/mod probe
```

## FILES
/etc/sysctl.d/*.conf

/run/sysctl.d/*.conf

/usr/local/lib/sysctl.d/*.conf

/usr/lib/sysctl.d/*.conf

/lib/sysctl.d/*.conf

/etc/sysctl.conf

The paths where sysctl preload files usually exist. See also sysctl option --system.

## SEE ALSO
sysctl(8)

## AUTHOR
George Staikos

## REPORTING BUGS
Please send bug reports to procps@freelists.org


proftpd.conf

package: proftpd

title: proftpd.conf(5)

summary: ProFTPD server configuration file

text:
# proftpd.conf(5)

## NAME
proftpd.conf - ProFTPD server configuration file

## DESCRIPTION
The proftpd(8) daemon reads its configuration file, typically stored in one of the following locations:

/etc/proftpd.conf

/etc/proftpd/proftpd.conf

/usr/local/etc/proftpd.conf

or passed to proftpd with the -c command-line option.

The proftpd.conf configuration file contains directives , one per line. Lines starting with # and empty lines are comments and are ignored. Directives are case-insensitive, whereas values are case-sensitive. Values may be enclosed in double-quotes (") if they contain spaces.

The possible directives and their descriptions are described online at http://www.proftpd.org/docs/directives/linked/by-name.html

## FILES
/usr/sbin/proftpd

/etc/proftpd.conf

## AUTHORS
ProFTPD is written and maintained by a number of people, full credits can be found on http://www.proftpd.org/credits.html

## SEE ALSO
proftpd(8)

Full documentation on ProFTPD, including configuration and FAQs, is available at http://www.proftpd.org/

For help/support, try the ProFTPD mailing lists, detailed on http://www.proftpd.org/lists.html

Report bugs at http://bugs.proftpd.org/


xferlog

title: xferlog(5)

summary: ProFTPD server logfile

text:
# xferlog(5)

## NAME
xferlog - ProFTPD server logfile

## DESCRIPTION
The xferlog file contains logging information from the FTP server daemon, proftpd(8). This file usually is found in /var/log but can be located anywhere by using a proftpd(8) configuration directive. Each server entry is composed of a single line of the following form, with all fields being separated by spaces.

current-time transfer-time remote-host file-size filename transfer-type special-action-flag direction access-mode username service-name authentication-method authenticated-user-id completion-status

current-time

is the current local time in the form "DDD MMM dd hh:mm:ss YYYY". Where DDD is the day of the week, MMM is the month, dd is the day of the month, hh is the hour, mm is the minutes, ss is the seconds, and YYYY is the year.

transfer-time

is the total time in seconds for the transfer.

remote-host

is the remote host name.

file-size

is the size of the transferred file in bytes.

filename

is the name of the transferred file. If the filename contains any spaces or control characters, each such character is replaced by an underscore ('_') character.

transfer-type

is a single character indicating the type of transfer. Can be one of:

a

for an ascii transfer

b

for a binary transfer

special-action-flag

is one or more single character flags indicating any special action taken. Can be one or more of:

C

file was compressed

U

file was uncompressed

T

file was tar'ed

_

no action was taken

direction

is the direction of the transfer. Can be one of:

o

outgoing

i

incoming

d

deleted

access-mode

is the method by which the user is logged in. Can be one of:

a

(anonymous) is for an anonymous guest user.

r

(real) is for a local authenticated user.

username

is the local username, or if guest, the ID string given.

service-name

is the name of the service being invoked, usually FTP.

authentication-method

is the method of authentication used. Can be one of:

0

none

1

RFC931 Authentication

authenticated-user-id

is the user id returned by the authentication method. A * is used if an authenticated user id is not available.

completion-status

is a single character indicating the status of the transfer. Can be one of:

c

complete transfer

i

incomplete transfer

## FILES
/var/log/xferlog

## AUTHORS
ProFTPD is written and maintained by a number of people, full credits can be found on http://www.proftpd.org/credits.html

## SEE ALSO
proftpd(8)

Full documentation on ProFTPD, including configuration and FAQs, is available at http://www.proftpd.org/

For help/support, try the ProFTPD mailing lists, detailed on http://www.proftpd.org/lists.html

Report bugs at http://bugs.proftpd.org/


acl.cfg

package: proxmox-backup-server

title: acl.cfg(5)

summary: Access Control Configuration

text:
# acl.cfg(5)

## NAME
acl.cfg - Access Control Configuration

## DESCRIPTION
The file /etc/proxmox-backup/acl.cfg is a configuration file for Proxmox Backup Server. It contains the access control configuration for the API.

## FILE FORMAT
This file contains the access control list for the Proxmox Backup Server API.

Each line starts with acl:, followed by 4 additional values separated by colon.

propagate

Propagate permissions down the hierarchy

path

The object path

User/Token

List of users and tokens

Role

List of assigned roles

Here is an example list:

```
acl:1:/:root@pam!test:Admin
acl:1:/datastore/store1:user1@pbs:DatastoreAdmin
```

You can use the proxmox-backup-manager acl command to manipulate this file.

## ROLES
The following roles exist:

Admin

Administrator

Audit

Auditor

NoAccess

Disable Access

DatastoreAdmin

Datastore Administrator

DatastoreReader

Datastore Reader (inspect datastore content and do restores)

DatastoreBackup

Datastore Backup (backup and restore owned backups)

DatastorePowerUser

Datastore PowerUser (backup, restore and prune owned backup)

DatastoreAudit

Datastore Auditor

RemoteAudit

Remote Auditor

RemoteAdmin

Remote Administrator

RemoteSyncOperator

Synchronization Operator

TapeAudit

Tape Auditor

TapeAdmin

Tape Administrator

TapeOperator

Tape Operator

TapeReader

Tape Reader

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


datastore.cfg

title: datastore.cfg(5)

summary: Datastore Configuration

text:
# datastore.cfg(5)

## NAME
datastore.cfg - Datastore Configuration

## DESCRIPTION
The file /etc/proxmox-backup/datastore.cfg is a configuration file for Proxmox Backup Server. It contains the Datastore configuration.

## FILE FORMAT
This file contains a list of datastore configuration sections. Each section starts with the header datastore: <name>, followed by the datastore configuration options.

```
datastore: <name1>

   path <path1>

   <option1> <value1>

   ...
datastore: <name2>

   path <path2>

   ...
```

You can use the proxmox-backup-manager datastore command to manipulate this file.

## OPTIONS
Required properties:

path

<string> Directory name

Optional properties:

comment

<string> Comment.

gc-schedule

<calendar-event> Run garbage collection job at specified schedule.

maintenance-mode

[type=<enum> [,message=<string>]] Maintenance mode, type is either 'offline' or 'read-only', message should be enclosed in " type = read-only|offline|delete

Maintenance type.

message = <string>

Message describing the reason for the maintenance.

notification-mode

legacy-sendmail|notification-system (default=legacy-sendmail) Configure how notifications for this datastore should be sent. legacy- sendmail sends email notifications to the user configured in notify-user via the system's sendmail executable. notification-system emits matchable notification events to the notification system.

notify

[[gc=<enum>] [,prune=<enum>] [,sync=<enum>] [,verify=<enum>]] Datastore notification setting, enum can be one of 'always', 'never', or 'error'. gc = never|always|error

When do we send notifications

prune = never|always|error

When do we send notifications

sync = never|always|error

When do we send notifications

verify = never|always|error

When do we send notifications

notify-user

<string> User ID

prune-schedule

<calendar-event> Run prune job at specified schedule.

tuning

[[chunk-order=<enum>] [,sync-level=<enum>]].INDENT 7.0

Datastore tuning options chunk-order = none|inode (default=inode)

The order to sort chunks by

sync-level = none|file|filesystem (default=filesystem)

The level of syncing that is done when writing into a datastore.

verify-new

<boolean> If enabled, all new backups will be verified right after completion.

keep-daily

<integer> (1 - N) Number of daily backups to keep.

keep-hourly

<integer> (1 - N) Number of hourly backups to keep.

keep-last

<integer> (1 - N) Number of backups to keep.

keep-monthly

<integer> (1 - N) Number of monthly backups to keep.

keep-weekly

<integer> (1 - N) Number of weekly backups to keep.

keep-yearly

<integer> (1 - N) Number of yearly backups to keep.

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


domains.cfg

title: domains.cfg(5)

summary: Realm Configuration

text:
# domains.cfg(5)

## NAME
domains.cfg - Realm Configuration

## DESCRIPTION
The file /etc/proxmox-backup/domains.cfg is a configuration file for Proxmox Backup Server. It contains the realm configuration.

## FILE FORMAT
This file contains the list authentication realms.

Each user configuration section starts with the header <realm-type>: <name>, followed by the realm's configuration options.

For LDAP realms, the LDAP bind password is stored in ldap_passwords.json.

```
openid: master

      client-id pbs

      comment

      issuer-url http://192.168.0.10:8080/realms/master

      username-claim username
ldap: ldap-server

      base-dn OU=People,DC=ldap-server,DC=example,DC=com

      mode ldaps

      server1 192.168.0.10

      sync-attributes email=mail

      sync-defaults-options enable-new=0,remove-vanished=acl;entry

      user-attr uid

      user-classes inetorgperson,posixaccount,person,user
```

You can use the proxmox-backup-manager openid, proxmox-backup-manager ldap and proxmox-backup-manager ad commands to manipulate this file.

## OPTIONS
Section type 'ad': AD realm configuration properties.

Required properties:

server1

<string> AD server address

Optional properties:

base-dn

<string> LDAP Domain

bind-dn

<string> LDAP Domain

capath

<string> CA certificate to use for the server. The path can point to either a file, or a directory. If it points to a file, the PEM-formatted X.509 certificate stored at the path will be added as a trusted certificate. If the path points to a directory, the directory replaces the system's default certificate store at /etc/ssl/certs - Every file in the directory will be loaded as a trusted certificate.

comment

<string> Comment.

filter

<string> Custom LDAP search filter for user sync

mode

ldap|ldap+starttls|ldaps (default=ldap) LDAP connection type

port

<integer> (0 - 65535) AD server Port

server2

<string> Fallback AD server address

sync-attributes

[[email=<string>] [,firstname=<string>] [,lastname=<string>]] Comma-separated list of key=value pairs for specifying which LDAP attributes map to which PBS user field. For example, to map the LDAP attribute mail to PBS's email, write email=mail. email = <string>

Name of the LDAP attribute containing the user's email address

firstname = <string>

Name of the LDAP attribute containing the user's first name

lastname = <string>

Name of the LDAP attribute containing the user's last name

sync-defaults-options

[[enable-new=<1|0>] [,remove-vanished=<string>]].INDENT 7.0

sync defaults options enable-new = <boolean>

Enable new users after sync

remove-vanished = [acl|entry|properties, ...]

A semicolon-separated list of things to remove when they or the user vanishes during user synchronization. The following values are possible: entry removes the user when not returned from the sync; properties removes any properties on existing user that do not appear in the source. acl removes ACLs when the user is not returned from the sync.

user-classes

[<string>, ...] (default=inetorgperson,posixaccount,person,user) Comma-separated list of allowed objectClass values for user synchronization. For instance, if user-classes is set to person,user, then user synchronization will consider all LDAP entities where objectClass: person or objectClass: user.

verify

<boolean> (default=false) Verify server certificate

Section type 'ldap': LDAP configuration properties.

Required properties:

base-dn

<string> LDAP Domain

server1

<string> LDAP server address

user-attr

<string> Username attribute. Used to map a userid to LDAP to an LDAP dn.

Optional properties:

bind-dn

<string> LDAP Domain

capath

<string> CA certificate to use for the server. The path can point to either a file, or a directory. If it points to a file, the PEM-formatted X.509 certificate stored at the path will be added as a trusted certificate. If the path points to a directory, the directory replaces the system's default certificate store at /etc/ssl/certs - Every file in the directory will be loaded as a trusted certificate.

comment

<string> Comment.

filter

<string> Custom LDAP search filter for user sync

mode

ldap|ldap+starttls|ldaps (default=ldap) LDAP connection type

port

<integer> (0 - 65535) Port

server2

<string> Fallback LDAP server address

sync-attributes

[[email=<string>] [,firstname=<string>] [,lastname=<string>]] Comma-separated list of key=value pairs for specifying which LDAP attributes map to which PBS user field. For example, to map the LDAP attribute mail to PBS's email, write email=mail. email = <string>

Name of the LDAP attribute containing the user's email address

firstname = <string>

Name of the LDAP attribute containing the user's first name

lastname = <string>

Name of the LDAP attribute containing the user's last name

sync-defaults-options

[[enable-new=<1|0>] [,remove-vanished=<string>]].INDENT 7.0

sync defaults options enable-new = <boolean>

Enable new users after sync

remove-vanished = [acl|entry|properties, ...]

A semicolon-separated list of things to remove when they or the user vanishes during user synchronization. The following values are possible: entry removes the user when not returned from the sync; properties removes any properties on existing user that do not appear in the source. acl removes ACLs when the user is not returned from the sync.

user-classes

[<string>, ...] (default=inetorgperson,posixaccount,person,user) Comma-separated list of allowed objectClass values for user synchronization. For instance, if user-classes is set to person,user, then user synchronization will consider all LDAP entities where objectClass: person or objectClass: user.

verify

<boolean> (default=false) Verify server certificate

Section type 'openid': OpenID configuration properties.

Required properties:

client-id

<string> OpenID Client ID

issuer-url

<string> OpenID Issuer Url

Optional properties:

acr-values

[<string>, ...] OpenID ACR List

autocreate

<boolean> (default=false) Automatically create users if they do not exist.

client-key

<string> OpenID Client Key

comment

<string> Comment.

prompt

<string> OpenID Prompt

scopes

[<string>, ...] (default=email profile) OpenID Scope List

username-claim

<string> Use the value of this attribute/claim as unique user name. It is up to the identity provider to guarantee the uniqueness. The OpenID specification only guarantees that Subject ('sub') is unique. Also make sure that the user is not allowed to change that attribute by himself!

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


media-pool.cfg

title: media-pool.cfg(5)

summary: Media Pool Configuration

text:
# media-pool.cfg(5)

## NAME
media-pool.cfg - Media Pool Configuration

## DESCRIPTION
The file /etc/proxmox-backup/media-pool.cfg is a configuration file for Proxmox Backup Server. It contains the medila pool configuration for tape backups.

## FILE FORMAT
Each entry starts with the header pool: <name>, followed by the media pool configuration options.

```
pool: company1

      allocation always

      retention overwrite
pool: ...
```

You can use the proxmox-tape pool command to manipulate this file.

## OPTIONS
Optional properties:

allocation

<string> Media set allocation policy ('continue', 'always', or a calendar event).

comment

<string> Comment.

encrypt

<string> Tape encryption key fingerprint (sha256).

retention

<string> Media retention policy ('overwrite', 'keep', or time span).

template

<string> Media set naming template (may contain strftime() time format specifications).

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


notifications-priv.cfg

title: notifications-priv.cfg(5)

summary: Notification target secrets

text:
# notifications-priv.cfg(5)

## NAME
notifications-priv.cfg - Notification target secrets

## DESCRIPTION
The file /etc/proxmox-backup/notifications-priv.cfg is a configuration file for Proxmox Backup Server. It contains the configuration for the notification system configuration.

## FILE FORMAT
This file contains protected credentials for notification targets.

## OPTIONS
Section type 'gotify': Private configuration for Gotify notification endpoints. This config will be saved to a separate configuration file with stricter permissions (root:root 0600)

Required properties:

token

<string> Authentication token

Section type 'smtp': Private configuration for SMTP notification endpoints. This config will be saved to a separate configuration file with stricter permissions (root:root 0600)

Optional properties:

password

<string> The password to use during authentication.

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


notifications.cfg

title: notifications.cfg(5)

text:
# notifications.cfg(5)

## NAME
notifications.cfg - Notification target/matcher configuration

## DESCRIPTION
The file /etc/proxmox-backup/notifications.cfg is a configuration file for Proxmox Backup Server. It contains the configuration for the notification system configuration.

## FILE FORMAT
This file contains configuration for notification targets and notification matchers.

## OPTIONS
Section type 'filter': Config for the old filter system - can be removed at some point.

Section type 'gotify': Config for Gotify notification endpoints

Required properties:

server

<string> Gotify Server URL.

Optional properties:

comment

<string> Comment.

disable

<boolean> Disable this target.

filter

<string> Deprecated.

origin

user-created|builtin|modified-builtin The origin of a notification configuration entry.

Section type 'group': Config for the old target groups - can be removed at some point.

Section type 'matcher': Config for Sendmail notification endpoints

Optional properties:

comment

<string> Comment.

disable

<boolean> Disable this matcher.

invert-match

<boolean> Invert match of the whole filter.

match-calendar

<string> List of matched severity levels. Can be specified more than once.

match-field

<string> List of matched metadata fields. Can be specified more than once.

match-severity

<string> List of matched severity levels. Can be specified more than once.

mode

all|any (default=all) The mode in which the results of matches are combined.

origin

user-created|builtin|modified-builtin The origin of a notification configuration entry.

target

<string> Targets to notify. Can be specified more than once.

Section type 'sendmail': Config for Sendmail notification endpoints

Optional properties:

author

<string> Author of the mail. Defaults to 'Proxmox Backup Server ($hostname)'

comment

<string> Comment.

disable

<boolean> Disable this target.

filter

<string> Deprecated.

from-address

<string> From address for sent E-Mails. If the parameter is not set, the plugin will fall back to the email-from setting from node.cfg (PBS). If that is also not set, the plugin will default to root@$hostname, where $hostname is the hostname of the node.

mailto

<string> Mail address to send a mail to. Can be specified more than once.

mailto-user

<string> Users to send a mail to. The email address of the user will be looked up in users.cfg. Can be specified more than once.

origin

user-created|builtin|modified-builtin The origin of a notification configuration entry.

Section type 'smtp': Config for Sendmail notification endpoints

Required properties:

from-address

<string> From address for the mail. SMTP relays might require that this address is owned by the user in order to avoid spoofing. The From header in the email will be set to $author <$from-address>.

server

<string> Host name or IP of the SMTP relay.

Optional properties:

author

<string> Author of the mail. Defaults to 'Proxmox Backup Server ($hostname)'

comment

<string> Comment.

disable

<boolean> Disable this target.

mailto

<string> Mail address to send a mail to. Can be specified more than once.

mailto-user

<string> Users to send a mail to. The email address of the user will be looked up in users.cfg. Can be specified more than once.

mode

insecure|starttls|tls (default=tls) Connection security

origin

user-created|builtin|modified-builtin The origin of a notification configuration entry.

port

<integer> (0 - 65535) The port to connect to. If not set, the used port defaults to 25 (insecure), 465 (tls) or 587 (starttls), depending on the value of mode

username

<string> Username to use during authentication. If no username is set, no authentication will be performed. The PLAIN and LOGIN authentication methods are supported

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


proxmox-backup.node.cfg

title: proxmox-backup.node.cfg(5)

text:
# proxmox-backup.node.cfg(5)

## NAME
proxmox-backup.node.cfg - Proxmox Backup Server - Node Configuration

## DESCRIPTION
The file /etc/proxmox-backup/node.cfg is a configuration file for Proxmox Backup Server. It contains the general configuration regarding this node.

## OPTIONS
The file contains these options:

acme

The ACME account to use on this node.

acmedomain0

ACME domain.

acmedomain1

ACME domain.

acmedomain2

ACME domain.

acmedomain3

ACME domain.

acmedomain4

ACME domain.

http-proxy

Set proxy for apt and subscription checks.

email-from

Fallback email from which notifications will be sent.

ciphers-tls-1.3

List of TLS ciphers for TLS 1.3 that will be used by the proxy. Colon-separated and in descending priority (https://docs.openssl.org/master/man1/openssl-ciphers/). (Proxy has to be restarted for changes to take effect.)

ciphers-tls-1.2

List of TLS ciphers for TLS <= 1.2 that will be used by the proxy. Colon-separated and in descending priority (https://docs.openssl.org/master/man1/openssl-ciphers/). (Proxy has to be restarted for changes to take effect.)

default-lang

Default language used in the GUI.

description

Node description.

task-log-max-days

Maximum days to keep task logs.

For example:

```
acme: local
acmedomain0: first.domain.com
acmedomain1: second.domain.com
acmedomain2: third.domain.com
acmedomain3: fourth.domain.com
acmedomain4: fifth.domain.com
http-proxy: internal.proxy.com
email-from: proxmox@mail.com
ciphers-tls-1.3: TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_CHACHA20_POLY1305_SHA256
ciphers-tls-1.2: RSA_WITH_AES_128_CCM:DHE_RSA_WITH_AES_128_CCM
default-lang: en
description: Primary PBS instance
task-log-max-days: 30
```

You can use the proxmox-backup-manager node command to manipulate this file.

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


remote.cfg

title: remote.cfg(5)

summary: Remote Server Configuration

text:
# remote.cfg(5)

## NAME
remote.cfg - Remote Server Configuration

## DESCRIPTION
The file /etc/proxmox-backup/remote.cfg is a configuration file for Proxmox Backup Server. It contains information about remote servers, usable for synchronization jobs.

## FILE FORMAT
This file contains information used to access remote servers.

Each entry starts with the header remote: <name>, followed by the remote configuration options.

```
remote: server1

      host server1.local

      auth-id sync@pbs

      ...
remote: ...
```

You can use the proxmox-backup-manager remote command to manipulate this file.

## OPTIONS
Required properties:

password

<string> Password or auth token for remote host (stored as base64 string).

auth-id

<string> Authentication ID

host

<string> DNS name or IP address.

Optional properties:

comment

<string> Comment.

fingerprint

<string> X509 certificate fingerprint (sha256).

port

<integer> The (optional) port

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


sync.cfg

title: sync.cfg(5)

summary: Synchronization Job Configuration

text:
# sync.cfg(5)

## NAME
sync.cfg - Synchronization Job Configuration

## DESCRIPTION
The file /etc/proxmox-backup/sync.cfg is a configuration file for Proxmox Backup Server. It contains the synchronization job configuration.

## FILE FORMAT
Each entry starts with the header sync: <name>, followed by the job configuration options.

```
sync: job1

      store store1

      remote-store store1

      remote lina
sync: ...
```

You can use the proxmox-backup-manager sync-job command to manipulate this file.

## OPTIONS
Required properties:

remote-store

<string> Datastore name.

store

<string> Datastore name.

Optional properties:

comment

<string> Comment.

group-filter

[<exclude:|include:>]<type:<vm|ct|host>|group:GROUP|regex:RE> List of group filters. Can be specified more than once.

max-depth

<integer> (0 - 7) How many levels of namespaces should be operated on (0 == no recursion, empty == automatic full recursion, namespace depths reduce maximum allowed value)

ns

<string> Namespace.

owner

<string> Authentication ID

remote

<string> Remote ID.

remote-ns

<string> Namespace.

remove-vanished

<boolean> (default=false) Delete vanished backups. This remove the local copy if the remote backup was deleted.

schedule

<calendar-event> Run sync job at specified schedule.

transfer-last

<integer> (1 - N) Limit transfer to last N snapshots (per group), skipping others

burst-in

<string> Byte size with optional unit (B, KB (base 10), MB, GB, ..., KiB (base 2), MiB, Gib, ...).

burst-out

<string> Byte size with optional unit (B, KB (base 10), MB, GB, ..., KiB (base 2), MiB, Gib, ...).

rate-in

<string> Byte size with optional unit (B, KB (base 10), MB, GB, ..., KiB (base 2), MiB, Gib, ...).

rate-out

<string> Byte size with optional unit (B, KB (base 10), MB, GB, ..., KiB (base 2), MiB, Gib, ...).

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


tape-job.cfg

title: tape-job.cfg(5)

summary: Tape Job Configuration

text:
# tape-job.cfg(5)

## NAME
tape-job.cfg - Tape Job Configuration

## DESCRIPTION
The file /etc/proxmox-backup/tape-job.cfg is a configuration file for Proxmox Backup Server. It contains the tape job configuration.

## FILE FORMAT
Each entry starts with the header backup: <name>, followed by the job configuration options.

```
backup: job1

      drive hh8

      pool p4

      store store3

      schedule daily
backup: ...
```

You can use the proxmox-tape backup-job command to manipulate this file.

## OPTIONS
Required properties:

drive

<string> Drive Identifier.

pool

<string> Media pool name.

store

<string> Datastore name.

Optional properties:

comment

<string> Comment.

schedule

<calendar-event> Run sync job at specified schedule.

eject-media

<boolean> Eject media upon job completion.

export-media-set

<boolean> Export media set upon job completion.

group-filter

[<exclude:|include:>]<type:<vm|ct|host>|group:GROUP|regex:RE> List of group filters. Can be specified more than once.

latest-only

<boolean> Backup latest snapshots only.

max-depth

<integer> (0 - 7) (default=7) How many levels of namespaces should be operated on (0 == no recursion)

notification-mode

legacy-sendmail|notification-system (default=legacy-sendmail) Configure how notifications for this datastore should be sent. legacy- sendmail sends email notifications to the user configured in notify-user via the system's sendmail executable. notification-system emits matchable notification events to the notification system.

notify-user

<string> User ID

ns

<string> Namespace.

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


tape.cfg

title: tape.cfg(5)

summary: Tape Drive and Changer Configuration

text:
# tape.cfg(5)

## NAME
tape.cfg - Tape Drive and Changer Configuration

## DESCRIPTION
The file /etc/proxmox-backup/tape.cfg is a configuration file for Proxmox Backup Server. It contains the tape drive and changer configuration.

## FILE FORMAT
Each LTO drive configuration section starts with the header lto: <name>, followed by the drive configuration options.

Tape changer configurations start with the header changer: <name>, followed by the changer configuration options.

```
lto: hh8

      changer sl3

      path /dev/tape/by-id/scsi-10WT065325-nst
changer: sl3

      export-slots 14,15,16

      path /dev/tape/by-id/scsi-CJ0JBE0059
```

You can use the proxmox-tape drive and proxmox-tape changer commands to manipulate this file.

NOTE:

The virtual: drive type is experimental and should only be used for debugging.

## OPTIONS
Section type 'changer': SCSI tape changer

Required properties:

path

<string> Path to Linux generic SCSI device (e.g. '/dev/sg4')

Optional properties:

eject-before-unload

<boolean> (default=false) if set to true, tapes are ejected manually before unloading

export-slots

[<integer>, ...] A list of slot numbers, comma separated. Those slots are reserved for Import/ Export, i.e. any media in those slots are considered to be 'offline'.

Section type 'lto': Lto SCSI tape driver

Required properties:

path

<string> The path to a LTO SCSI-generic tape device (i.e. '/dev/sg0')

Optional properties:

changer

<string> Tape Changer Identifier.

changer-drivenum

<integer> (0 - 255) (default=0) Associated changer drive number (requires option changer)

Section type 'virtual': Simulate tape drives (only for test and debug)

Required properties:

path

<string> Path to directory

Optional properties:

max-size

<integer> (0 - N) Virtual tape size

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


user.cfg

title: user.cfg(5)

summary: User Configuration

text:
# user.cfg(5)

## NAME
user.cfg - User Configuration

## DESCRIPTION
The file /etc/proxmox-backup/user.cfg is a configuration file for Proxmox Backup Server. It contains the user configuration.

## FILE FORMAT
This file contains the list of API users and API tokens.

Each user configuration section starts with the header user: <name>, followed by the user configuration options.

API token configuration starts with the header token: <userid!token_name>, followed by the token configuration. The data used to authenticate tokens is stored in a separate file (token.shadow).

```
user: root@pam

      comment Superuser

      email test@example.local

      ...
token: root@pam!token1

      comment API test token

      enable true

      expire 0
user: ...
```

You can use the proxmox-backup-manager user command to manipulate this file.

## OPTIONS
Section type 'token': ApiToken properties.

Optional properties:

comment

<string> Comment.

enable

<boolean> (default=true) Enable the account (default). You can set this to '0' to disable the account.

expire

<integer> (0 - N) (default=0) Account expiration date (seconds since epoch). '0' means no expiration date.

Section type 'user': User properties.

Optional properties:

comment

<string> Comment.

email

<string> E-Mail Address.

enable

<boolean> (default=true) Enable the account (default). You can set this to '0' to disable the account.

expire

<integer> (0 - N) (default=0) Account expiration date (seconds since epoch). '0' means no expiration date.

firstname

<string> First name.

lastname

<string> Last name.

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


verification.cfg

title: verification.cfg(5)

summary: Verification Job Configuration

text:
# verification.cfg(5)

## NAME
verification.cfg - Verification Job Configuration

## DESCRIPTION
The file /etc/proxmox-backup/sync.cfg is a configuration file for Proxmox Backup Server. It contains the verification job configuration.

## FILE FORMAT
Each entry starts with the header verification: <name>, followed by the job configuration options.

```
verification: verify-store2

      ignore-verified true

      outdated-after 7

      schedule daily

      store store2
verification: ...
```

You can use the proxmox-backup-manager verify-job command to manipulate this file.

## OPTIONS
Required properties:

store

<string> Datastore name.

Optional properties:

comment

<string> Comment.

ignore-verified

<boolean> (default=true) Do not verify backups that are already verified if their verification is not outdated.

max-depth

<integer> (0 - 7) (default=7) How many levels of namespaces should be operated on (0 == no recursion)

ns

<string> Namespace.

outdated-after

<integer> (0 - N) Days after that a verification becomes outdated. (0 is deprecated)'

schedule

<calendar-event> Run verify job at specified schedule.

## COPYRIGHT AND DISCLAIMER
Copyright (C) 2019-2023, Proxmox Server Solutions GmbH

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/

## AUTHOR
Proxmox Support Team

## COPYRIGHT
2019-2025, Proxmox Server Solutions GmbH


lei-mail-formats

package: public-inbox

title: lei-mail-formats(5)

text:
# lei-mail-formats(5)

## NAME
lei-mail-formats - description of mail formats supported by lei

## DESCRIPTION
lei-q(1) supports writing to several existing mail formats for interoperability with existing mail user agents (MUA); below is an overview of them to help users choose.

## Maildir
The default output format when given a filesystem path, it supports parallel read-write access. Performance is acceptable for smaller directories, but degrades as mailboxes get larger. Speed and scalability are limited by kernel and filesystem performance due to the use of small files and large number of syscalls.

See also: <https://cr.yp.to/proto/maildir.html> and <https://wiki2.dovecot.org/MailboxFormat/Maildir>

## Mbox family
The mbox family consists of several incompatible formats. Locking for parallel access is supported, but may not be compatible across tools. With compression (e.g. gzip(1)), they require the least amount of space while offering good read-only performance.

Keyword updates ("Status:" and/or "X-Status:" headers) generally require rewriting the entire mbox.

See also: <https://www.loc.gov/preservation/digital/formats/fdd/fdd000383.shtml>, mbox(5)

### mboxo
The traditional BSD format. It quotes "From " to ">From ", but lines already beginning with ">From " do not get quoted, thus automatic reversibility is not guaranteed. MUAs which favor "mboxcl" or "mboxcl2" may convert these automatically to their preferred format.

Truncation is undetectable unless compressed with gzip or similar.

### mboxrd
An evolution of "mboxo", but quotes "From " lines prefixed with any number of ">" characters and is thus fully reversible.

This format is emitted by PublicInbox::WWW(3pm) with gzip. It is supported by git-am(1) since git 2.10.

As with uncompressed "mboxo", uncompressed mboxrd are vulnerable to undetectable truncation.

It gracefully degrades to being treated as "mboxo" by MUAs unaware of the format as excessive ">From " quoting is recognizable to humans.

### mboxcl
"mboxo" with a "Content-Length:" header, "From " lines remain quoted to retain readability with "mboxo" and "mboxrd" MUAs. However, it is easy to corrupt these files when using tools which are not aware of "Content-Length:" and write out updates as "mboxo".

mutt(1) will convert "mboxo" and "mboxrd" to mboxcl upon opening.

See also: <https://www.jwz.org/doc/content-length.html>

### mboxcl2
Like "mboxcl", but without "From " any quoting. It is wholly incompatible with MUAs which only handle "mboxo" and/or "mboxrd". This is format is generated by mutt(1) when writing to a new mbox.

## MH
Not yet supported, locking semantics (or lack thereof) appear to make it unsuitable for parallel access.

## IMAP
Depending on the IMAP server software and configuration, IMAP servers may use any (or combination) of the aforementioned formats or a non-standard database backend.

## COPYRIGHT
Copyright 2021 all contributors <mailto:meta@public-inbox.org>

License: AGPL-3.0+ <http://www.gnu.org/licenses/agpl-3.0.txt>

## SEE ALSO
lei(1), lei-q(1), lei-convert(1), lei-overview(7)