Attachment 153652 Details for Bug 198145 – output from "man procmailrc"

output from "man procmailrc"

_ (text/plain), 32.29 KB, created by Poul-Henning Kamp on 2015-03-01 22:02:50 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Poul-Henning Kamp

Created: 2015-03-01 22:02:50 UTC

Size: 32.29 KB

patch

obsolete

>PROCMAILRC(5)             FreeBSD File Formats Manual            PROCMAILRC(5)
>
>
>
>procmailrc - procmail rcfile
>$$HHOOMMEE//..pprrooccmmaaiillrrcc
>For a quick start, see NNOOTTEESS at the end of the pprrooccmmaaiill(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
>$$DDEEFFAAUULLTT.
>
>There are two kinds of recipes: delivering and non-delivering recipes.  If a
>_d_e_l_i_v_e_r_i_n_g _r_e_c_i_p_e is found to match, procmail considers the mail (you guessed
>it) delivered and will _c_e_a_s_e _p_r_o_c_e_s_s_i_n_g the rcfile after having successfully
>executed the action line of the recipe.  If a _n_o_n_-_d_e_l_i_v_e_r_i_n_g _r_e_c_i_p_e is found
>to match, processing of the rcfile will _c_o_n_t_i_n_u_e 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 _d_e_l_i_v_e_r_i_n_g _r_e_c_i_p_e as if it were a non-
>delivering recipe by specifying the `c' flag on such a recipe.  This will make
>procmail generate a _c_a_r_b_o_n _c_o_p_y 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 aassssiiggnnmmeennttss and rreecciippeess 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 MMAAIILLDDIIRR, switch
>lockfiles by specifying a new LLOOCCKKFFIILLEE, change the umask at any time, etc.,
>the possibilities are endless :-).
>
>The assignments and substitutions of these environment variables are handled
>exactly like in sshh(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.
>
>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.
>
>A line starting with ':' marks the beginning of a recipe.  It has the
>following format:
>
>:0 [_f_l_a_g_s] [ : [_l_o_c_a_l_l_o_c_k_f_i_l_e] ]
><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 lliitteerraallllyy, except for leading and trailing
>whitespace.  These regular expressions are ccoommpplleetteellyy compatible to the normal
>eeggrreepp(1) extended regular expressions.  See also EExxtteennddeedd rreegguullaarr eexxpprreessssiioonnss.
>
>Conditions are anded; if there are no conditions the result will be true by
>default.
>
>_F_l_a_g_s can be any of the following:
>HH Egrep the header (default).
>BB Egrep the body.
>DD Tell the internal egrep to distinguish between upper and lower case
>(contrary to the default which is to ignore case).
>AA 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.
>aa Has the same meaning as the `A' flag, with the additional condition that the
>immediately preceding recipe must have been _s_u_c_c_e_s_s_f_u_l_l_y completed before this
>recipe is executed.
>EE 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.
>ee This recipe only executes if the immediately preceding recipe _f_a_i_l_e_d (i.e.,
>the action line was attempted, but resulted in an error).
>hh Feed the header to the pipe, file or mail destination (default).
>bb Feed the body to the pipe, file or mail destination (default).
>ff Consider the pipe as a filter.
>cc Generate a ccaarrbboonn ccooppyy of this mail.  This only makes sense on _d_e_l_i_v_e_r_i_n_g
>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 cclloonnee the running
>procmail process (lockfiles will not be inherited), whereby the clone will
>proceed as usual and the parent will jump across the block.
>ww 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.
>WW Has the same meaning as the `w' flag, but will suppress any `Program
>failure' message.
>ii Ignore any write errors on this recipe (i.e., usually due to an early closed
>pipe).
>rr 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 sshh(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 '<'.
>vvaarriiaabblleennaammee _?_? 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.
>
>If you put a second (trailing) ':' on the first recipe line, then procmail
>will use a _l_o_c_a_l_l_o_c_k_f_i_l_e (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.
>
>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
>_v_a_r_i_a_b_l_e_=, which will cause stdout of the program to be captured in the
>environment _v_a_r_i_a_b_l_e (procmail will nnoott 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 _n_o_t 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).
>LLOOGGNNAAMMEE,, HHOOMMEE aanndd SSHHEELLLL Your (the recipient's) defaults
>PPAATTHH $HOME/bin :/bin :/usr/bin :/usr/local/bin (Except during the processing
>of an /usr/local/etc/procmailrc file, when it will be set to `/bin :/usr/bin
>:/usr/local/bin'.)
>SSHHEELLLLMMEETTAASS & |<>~;?*[
>SSHHEELLLLFFLLAAGGSS -c
>OORRGGMMAAIILL /var/mail/$LOGNAME
>(Unless --mm has been specified, in which case it is unset)
>MMAAIILLDDIIRR $HOME
>(Unless the name of the first successfully opened rcfile starts with `./' or
>if --mm has been specified, in which case it defaults to `.')
>DDEEFFAAUULLTT $ORGMAIL
>MMSSGGPPRREEFFIIXX msg.
>SSEENNDDMMAAIILL /usr/sbin/sendmail
>SSEENNDDMMAAIILLFFLLAAGGSS -oi
>HHOOSSTT The current hostname
>CCOOMMSSAATT no
>(If an rcfile is specified on the command line)
>PPRROOCCMMAAIILL__VVEERRSSIIOONN 3.22
>LLOOCCKKEEXXTT .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.
>
>Before you get lost in the multitude of environment variables, keep in mind
>that all of them have reasonable defaults.
>MMAAIILLDDIIRR Current directory while procmail is executing (that means that all
>paths are relative to $MAILDIR).
>DDEEFFAAUULLTT Default mmaaiillbbooxx 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.
>LLOOGGFFIILLEE 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 LLOOGGAABBSSTTRRAACCTT.
>VVEERRBBOOSSEE You can turn on _e_x_t_e_n_d_e_d _d_i_a_g_n_o_s_t_i_c_s by setting this variable to `yes'
>or `on', to turn it off again set it to `no' or `off'.
>LLOOGGAABBSSTTRRAACCTT 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
>_d_e_l_i_v_e_r_i_n_g _r_e_c_i_p_e it processes.
>LLOOGG Anything assigned to this variable will be appended to $LOGFILE.
>OORRGGMMAAIILL Usually the system mailbox (OORRiGGinal MMAAIILLbox).  If, for some obscure
>reason (like `ffiilleessyysstteemm ffuullll') 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.
>LLOOCCKKFFIILLEE 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 _l_o_c_k_f_i_l_e 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.
>LLOOCCKKEEXXTT Default extension that is appended to a destination file to determine
>what local _l_o_c_k_f_i_l_e to use (only if turned on, on a per-recipe basis).
>LLOOCCKKSSLLEEEEPP Number of seconds procmail will sleep before retrying on a _l_o_c_k_f_i_l_e
>(if it already existed); if not specified, it defaults to 8 seconds.
>LLOOCCKKTTIIMMEEOOUUTT Number of seconds that have to have passed since a _l_o_c_k_f_i_l_e 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 sseennddmmaaiill/procmail.  Procmail is immune to clock
>skew across machines.
>TTIIMMEEOOUUTT 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.
>MMSSGGPPRREEFFIIXX Filename prefix that is used when delivering to a directory (not
>used when delivering to a maildir or an MH directory).
>HHOOSSTT If this is not the _h_o_s_t_n_a_m_e of the machine, processing of the current
>_r_c_f_i_l_e 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).
>UUMMAASSKK The name says it all (if it doesn't, then forget about this one :-).
>Anything assigned to UMASK is taken as an ooccttaall 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.
>SSHHEELLLLMMEETTAASS 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.
>SSHHEELLLLFFLLAAGGSS Any invocation of $SHELL will be like:
>"$SHELL" "$SHELLFLAGS" "$*";
>SSEENNDDMMAAIILL If you're not using the _f_o_r_w_a_r_d_i_n_g facility don't worry about this
>one.  It specifies the program being called to forward any mail.
>It gets invoked as: "$SENDMAIL" $SENDMAILFLAGS "$@";
>NNOORREESSRREETTRRYY Number of retries that are to be made if any `pprroocceessss ttaabbllee ffuullll',
>`ffiillee ttaabbllee ffuullll', `oouutt ooff mmeemmoorryy' or `oouutt ooff sswwaapp ssppaaccee' 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 _s_w_a_p _s_p_a_c_e has been
>exhausted or the _p_r_o_c_e_s_s _t_a_b_l_e is full, usually several other programs will
>either detect this as well and abort or crash 8-), thereby freeing valuable
>_r_e_s_o_u_r_c_e_s for procmail.
>SSUUSSPPEENNDD 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: LLOOCCKKSSLLEEEEPP.
>LLIINNEEBBUUFF Length of the internal line buffers, cannot be set smaller than 128.
>All lines read from the _r_c_f_i_l_e should not exceed $LINEBUF characters before
>and after expansion.  If not specified, it defaults to 2048.  This limit, of
>course, does _n_o_t apply to the mail itself, which can have arbitrary line
>lengths, or could be a binary file for that matter.  See also
>PROCMAIL_OVERFLOW.
>DDEELLIIVVEERREEDD 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).
>TTRRAAPP 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 EEXXIITTCCOODDEE and LLOOGGAABBSSTTRRAACCTT.
>EEXXIITTCCOODDEE By default, procmail returns an exitcode of zero (success) if it
>successfully delivered the message or if the HHOOSSTT 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 TTRRAAPP is set, procmail will
>set the exitcode to whatever the TTRRAAPP program returns.  If this variable is
>not set, procmail will set it shortly before calling up the TTRRAAPP program.
>LLAASSTTFFOOLLDDEERR 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.
>MMAATTCCHH 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.
>SSHHIIFFTT Assigning a positive value to this variable has the same effect as the
>`shift' command in sshh(1).  This command is most useful to extract extra
>arguments passed to procmail when acting as a generic mailfilter.
>IINNCCLLUUDDEERRCC 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
>IINNCCLLUUDDEERRCC should make sure that only trusted users have write access to the
>included rcfile or the directory it is in.  Command line assignments to
>IINNCCLLUUDDEERRCC have no effect.
>SSWWIITTCCHHRRCC 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 SSWWIITTCCHHRRCC aborts
>processing of the current rcfile as if it had ended at the assignment.  As
>with IINNCCLLUUDDEERRCC, no checking is done on the permissions or ownership of the
>rcfile and command line assignments have no effect.
>PPRROOCCMMAAIILL__VVEERRSSIIOONN The version number of the running procmail binary.
>PPRROOCCMMAAIILL__OOVVEERRFFLLOOWW This variable will be set to a non-empty value if procmail
>detects a buffer overflow.  See the BBUUGGSS section below for other details of
>operation when overflow occurs.
>CCOOMMSSAATT CCoommssaatt(8)/bbiiffff(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.
>DDRROOPPPPRRIIVVSS 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 /usr/local/etc/procmailrc file is executed on behalf of the
>recipient.
>The following tokens are known to both the procmail internal egrep and the
>standard eeggrreepp(1) (beware that some egrep implementations include other non-
>standard extensions):
>^^ Start of a line.
>$$ End of a line.
>..  Any character except a newline.
>aa** Any sequence of zero or more a's.
>aa++ Any sequence of one or more a's.
>aa??  Either zero or one a.
>[[^^--aa--dd]] Any character which is nnoott either a dash, a, b, c, d or newline.
>ddee||aabbcc Either the sequence `de' or `abc'.
>((aabbcc))** 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.
>Look in the pprrooccmmaaiilleexx(5) man page.
>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
>SSHHEELLLLMMEETTAASS)).
>
>Don't put comments on the regular expression condition lines in a recipe,
>these lines are fed to the internal egrep _l_i_t_e_r_a_l_l_y (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 nnoott on continued condition lines
>that are evaluated according to the sshh(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 LLOOCCKKTTIIMMEEOOUUTT.
>
>Any default values that procmail has for some environment variables will
>aallwwaayyss override the ones that were already defined.  If you really want to
>override the defaults, you either have to put them in the rrccffiillee or on the
>command line as arguments.
>
>The /usr/local/etc/procmailrc file cannot change the PATH setting seen by user
>rcfiles as the value is reset when procmail finishes the
>/usr/local/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 iinnssiiddee the shell-interpreted-`|' action part of a
>recipe will nnoott 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.
>pprrooccmmaaiill(1), pprrooccmmaaiillsscc(5), pprrooccmmaaiilleexx(5), sshh(1), ccsshh(1), mmaaiill(1), mmaaiillxx(1),
>bbiinnmmaaiill(1), uuuuccpp(1), aalliiaasseess(5), sseennddmmaaiill(8), eeggrreepp(1), rreeggeexxpp(5), ggrreepp(1),
>bbiiffff(1), ccoommssaatt(8), lloocckkffiillee(1), ffoorrmmaaiill(1)
>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
>--aa or --mm 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 _r_c_f_i_l_e, 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 _r_e_l_a_t_i_v_e 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 _a_b_s_o_l_u_t_e
>paths to specify global lockfiles).
>
>If an rcfile has a _r_e_l_a_t_i_v_e path and when the rcfile is first opened MMAAIILLDDIIRR
>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 _a_b_s_o_l_u_t_e 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
>If the regular expression contains `^^TTOO__' it will be substituted by
>`((^^((((OOrriiggiinnaall--))??((RReesseenntt--))??((TToo ||CCcc ||BBcccc)) ||((XX--EEnnvveellooppee
>||AAppppaarreennttllyy((--RReesseenntt))??))--TToo)) ::((..**[[^^--aa--zzAA--ZZ00--99__..]]))??))', which should catch all
>destination specifications containing a specific _a_d_d_r_e_s_s.
>
>If the regular expression contains `^^TTOO' it will be substituted by
>`((^^((((OOrriiggiinnaall--))??((RReesseenntt--))??((TToo ||CCcc ||BBcccc)) ||((XX--EEnnvveellooppee
>||AAppppaarreennttllyy((--RReesseenntt))??))--TToo)) ::((..**[[^^aa--zzAA--ZZ]]))??))', which should catch all
>destination specifications containing a specific _w_o_r_d.
>
>If the regular expression contains `^^FFRROOMM__DDAAEEMMOONN' it will be substituted by
>`((^^((MMaaiilliinngg--LLiisstt :: ||PPrreecceeddeennccee ::..**((jjuunnkk ||bbuullkk ||lliisstt)) ||TToo :: MMuullttiippllee rreecciippiieennttss
>ooff ||((((((RReesseenntt--))??((FFrroomm ||SSeennddeerr)) ||XX--EEnnvveellooppee--FFrroomm)) :: ||>>??FFrroomm ))(([[^^>>]]**[[^^((..%%@@aa--
>zz00--99]]))??((PPoosstt((mmaa??((sstt((ee??rr))?? ||nn)) ||ooffffiiccee)) ||((sseenndd))??MMaaiill((eerr))?? ||ddaaeemmoonn ||mm((mmddff
>||aajjoorrddoommoo)) ||nn??uuuuccpp ||LLIISSTT((SSEERRVV ||pprroocc)) ||NNEETTSSEERRVV ||oo((wwnneerr ||ppss)) ||rr((ee((qquueesstt ||ssppoonnssee))
>||oooott)) ||bb((oouunnccee ||bbss\\..ssmmttpp)) ||eecchhoo ||mmiirrrroorr ||ss((eerrvv((iicceess?? ||eerr)) ||mmttpp((eerrrroorr))?? ||yysstteemm))
>||AA((ddmmiinn((iissttrraattoorr))?? ||MMMMGGRR ||uuttooaannsswweerr))))(((([[^^))..!! ::aa--zz00--99]][[--__aa--zz00--99]]**))??[[%%@@>>\\tt
>]][[^^<<))]]**((\$(..**\$)..**))??))??$$(([[^^>>]] ||$$))))))', which should catch mails coming from most
>daemons (how's that for a regular expression :-).
>
>If the regular expression contains `^^FFRROOMM__MMAAIILLEERR' it will be substituted by
>`((^^((((((RReesseenntt--))??((FFrroomm ||SSeennddeerr)) ||XX--EEnnvveellooppee--FFrroomm)) :: ||>>??FFrroomm ))(([[^^>>]]**[[^^((..%%@@aa--
>zz00--99]]))??((PPoosstt((mmaa((sstt((eerr))?? ||nn)) ||ooffffiiccee)) ||((sseenndd))??MMaaiill((eerr))?? ||ddaaeemmoonn ||mmmmddff ||nn??uuuuccpp
>||ooppss ||rr((eessppoonnssee ||oooott)) ||((bbbbss\\..))??ssmmttpp((eerrrroorr))?? ||ss((eerrvv((iicceess?? ||eerr)) ||yysstteemm))
>||AA((ddmmiinn((iissttrraattoorr))?? ||MMMMGGRR))))(((([[^^))..!! ::aa--zz00--99]][[--__aa--zz00--99]]**))??[[%%@@>>\\tt
>]][[^^<<))]]**((\$(..**\$)..**))??))??$$(([[^^>>]] ||$$))))' (a stripped down version of `^^FFRROOMM__DDAAEEMMOONN'),
>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.
>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 IINNCCLLUUDDEERRCC and
>SSWWIITTCCHHRRCC is not guaranteed, has been changed once already, and may be changed
>again or removed in future releases.
>
>For _r_e_a_l_l_y complicated processing you can even consider calling pprrooccmmaaiill
>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.
>Stephen R. van den Berg
><srb@cuci.nl>
>Philip A. Guenther
><guenther@sendmail.com>
>
>
>
>BuGless                           2001/08/04                     PROCMAILRC(5)

Actions: View

Attachments on bug 198145: 153652