Some believe that this hostname could be used by spammers or could
be used by others for nefarious purposes.
If this feature is set, that name will be transformed with a simple
Rot13 transformation.
The result will still have the correct syntax for a Message-ID but the
part of the MessageID that is often a domain name will not be an actual
domain name because the letters will be scrambled.
It is possible (but unlikely?) that some spam detection
software will use that as a reason to reject the mail as spam.
It has also been reported that some spam detection software uses the
fact that there are no dots after the "@" as a reason to reject
messages.
If your PC-Alpine Message-ID is using a name without a dot that is because
that is what Windows thinks is your "Full computer name".
The method used to set this varies from one type of Windows to another but
check under Settings -> Control Panel -> System and
look for Network Identification or Computer Name or something similar.
How to set it is beyond the scope of Alpine.
This feature is displayed as "Scramble the Message-ID When Sending".
- select-without-confirm
- This feature controls an aspect of
Alpine's Save, Export, and Goto commands.
These commands all take text input to specify the name of the folder or
file to be used, but allow you to press ^T for a
list of possible names.
If set, the selected name will be used immediately, without further
opportunity to confirm or edit the name.
This feature is displayed as "Select Ctrl-T Foldername Without Confirming".
- send-without-confirm
- By default, when you send or post a message you will be asked to confirm
with a question that looks something like:
Send message?
If this feature is set, you
will not be prompted to confirm your intent to send
and your message will be sent.
If this feature is set it disables some possibilities and renders some
other features meaningless.
You will not be able to use
Sending Filters,
Verbose sending mode,
Background Sending,
Delivery Status Notifications,
or ^V to turn off the generation of flowed text for this message.
These options are normally available as suboptions in the Send prompt, but
with no Send prompt the options are gone.
A somewhat related feature is
quell-extra-post-prompt.
which may be used to eliminate the extra confirmation
question when posting to a newsgroup.
This feature is displayed as "Send Without Confirming".
- separate-folder-and-directory-display
- This feature affects folder collections wherein a folder
and directory can have the same name. By default, Alpine displays them
only once, denoting that it is both a folder and directory by appending
the folder name with the hierarchy character enclosed
in square brackets.
Enabling this feature will cause Alpine to display such names
separately marking the name representing a directory with a trailing
hierarchy delimiter (typically the slash, "/", character).
The feature also alters the command set slightly. By default, the
right-arrow descends into the directory, while hitting the Return key will
cause the folder by that name to be opened.
With this feature set, the Return key will open the highlighted folder, or
enter the highlighted directory.
- show-cursor
- If set, the system
cursor will move to convenient locations in the displays. For example,
to the beginning of the status field of the highlighted index line, or
to the highlighted word after a successful WhereIs command.
It is intended to draw your attention to the interesting
spot on the screen.
- show-plain-text-internally
- This feature modifies the method Alpine uses to display Text/Plain
MIME attachments from the Attachment Index screen. Normally, the
"View" command searches for any externally defined (usually
via the Mailcap file) viewer,
and displays the selected text within that viewer.
Enabling this feature causes Alpine to ignore any external viewer
settings and always display text with Alpine's internal viewer.
- show-selected-in-boldface
- This feature controls an aspect of Alpine's aggregate operation commands;
in particular, the Select and WhereIs commands.
Select and WhereIs (with
the ^X subcommand) will search the current folder
for messages meeting a
specified criteria, and tag the resulting
messages with an X in the
first column of the applicable lines in the "Folder Index". If this feature
is set, instead of using the X to denote a selected message,
Alpine will attempt to display those index lines in boldface.
Whether this is preferable to the X will depend on personal
taste and the type of terminal being used.
- show-sort
- If this feature is set and there is sufficient space on the screen,
a short indication of the current sort order will be
added in the titlebar (the top line on the screen), before the name
of the folder.
For example, with the default Arrival sort in effect,
the display would have the characters
[A]
added between the title of the screen and the folder name.
The letters are the same as the letters you may type to manually
sort a folder with the SortIndex command ($).
The letters in the table below are the ones that may show
up in the titlebar line.
| A | Arrival |
| S | Subject |
| F | From |
| T | To |
| C | Cc |
| D | Date |
| Z | siZe |
| O | Orderedsubject |
| E | scorE |
| H | tHread |
If the sort order is Reversed, the letter above will be preceded by the letter
"R", for example
[RS]
means that a Reverse Subject sort is in effect.
For the case where the sort is in Reverse Arrival order, the "A" is
left out, and just an "R" is shown.
[R]
This feature is displayed as "Show Sort in Titlebar".
- signature-at-bottom
- If this feature
is set, and a message being Replied to is being included in
the reply, then the
contents of the signature file (if any) will be inserted after the included
message.
This feature does not affect the results of a Forward command.
- single-column-folder-list
- If set, the "Folder List" screen will list one folder per line
instead of several per line.
- slash-collapses-entire-thread
- Normally, the Collapse/Expand Thread command Collapses or Expands the subthread which
starts at the currently highlighted message, if any.
If this feature is set, then the slash command Collapses or Expands the
entire current thread instead of just the subthread.
- smime-dont-do-smime
- UNIX Alpine only.
Setting this feature turns off all of Alpine's S/MIME support.
You might want to set this if you are having trouble due to the S/MIME support.
This feature is displayed as "S/MIME -- Turn off S/MIME".
- smime-encrypt-by-default
- UNIX Alpine only.
This feature only has an effect if your version of Alpine includes
support for S/MIME.
It affects Alpine's behavior when you send a message.
If this option is set, the "Encrypt" option will default to ON when sending messages.
Only the default value is affected.
In any case, you may still toggle the Encrypt option on or off before sending
with the "E Encrypt" command (provided you have a the public digital ID
for the recipient).
This feature is displayed as "S/MIME -- Encrypt by Default".
- smime-remember-passphrase
- UNIX Alpine only.
This feature only has an effect if your version of Alpine includes
support for S/MIME.
If this option is set, you will only have to enter your passphrase for your private key
once during an Alpine session.
This feature is displayed as "S/MIME -- Remember S/MIME Passphrase".
- smime-sign-by-default
- UNIX Alpine only.
This feature only has an effect if your version of Alpine includes
support for S/MIME.
It affects Alpine's behavior when you send a message.
If this option is set, the "Sign" option will default to ON when sending messages.
Only the default value is affected.
In any case, you may still toggle the Signing option on or off before sending
with the "G Sign" command (provided you have a personal digital ID
certificate).
This feature is displayed as "S/MIME -- Sign by Default".
- sort-default-fcc-alpha
- This feature controls an aspect of Alpine's FOLDER LIST screen.
If set, the default FCC folder will be sorted alphabetically with the other
folders instead of appearing right after the INBOX.
This feature is displayed as "Sort Default Fcc Folder Alphabetically".
- sort-default-save-alpha
- This feature controls an aspect of Alpine's FOLDER LIST screen.
If set, the default save folder will be sorted alphabetically with the other
folders instead of appearing right after the INBOX (and default FCC folder).
This feature is displayed as "Sort Default Save Folder Alphabetically".
- spell-check-before-sending
- When this feature is set, every composed message will be spell-checked before
being sent.
- store-window-position-in-config
- Normally, PC-Alpine will store its window size and position in the
Windows Registry.
This is convenient if you want to use the same remote
configuration from more than one PC.
If you use multiple configuration files to start PC-Alpine, you may want
to store the window size and position in the configuration file instead
of in the Registry.
Setting this feature causes that to happen.
- strip-from-sigdashes-on-reply
- This feature doesn't do anything if the feature
enable-sigdashes is turned on.
However, if the enable-sigdashes feature is not turned on,
then turning on this feature enables support for the convention
of not including text beyond the sigdashes line when Replying or Following
up to a message and including the text of that message.
In other words, this is a way to turn on the signature stripping behavior
without also turning on the dashes-adding behavior.
- strip-whitespace-before=send
- Trailing whitespace is not stripped from
a message before sending. Trailing whitespace should have no effect on an
email message, and in flowed text can aid in delimiting paragraphs.
However, the old behavior of stripping trailing whitespace was in place
to better deal with older clients that couldn't handle certain types of
text encodings. This feature restores the old behavior
Trailing whitespace is of aid to flowed-text-formatted messages, which are
generated by default but can be turned off via the
quell-flowed-text feature.
strip-whitespace-before-send also has the effect of turning off sending
of flowed text.
This feature is displayed as "Strip Whitespace Before Sending".
- suppress-asterisks-in-password-prompt
- When you are running Alpine you will sometimes be asked for a password
in a prompt on the third line from the bottom of the screen.
Normally each password character you type will cause an asterisk to echo
on the screen.
There is a very slight security risk in doing it this way because someone
watching over your shoulder might be able to see how many characters there
are in your password.
If you'd like to suppress the echoing of the asterisks set this feature.
- suppress-user-agent-when-sending
- If this feature is set then Alpine will not generate a
User-Agent
header in outgoing messages.
- tab-checks-recent
- In a FOLDER LIST screen, the TAB key usually just changes which
folder is highlighted.
If this feature is set, then the TAB key will cause the number of
recent messages and the total number of messages in the highlighted folder
to be displayed instead.
This feature is displayed as "Tab Checks for Recent Messages".
- tab-uses-unseen-for-next-folder
- This feature affects Alpine's behavior when using the TAB
NextNew Command
to move from one folder to the next.
Alpine's usual behavior is to search for folders
with Recent messages in them.
Recent messages are messages which have arrived since the last time the
folder was opened.
Setting this feature causes Alpine to search for Unseen
messages instead of Recent messages.
Unseen messages remain Unseen until you view them (or flag then as Seen with
the Flag Command).
Setting this feature allows you to locate messages you have not read
instead of only recently received messages.
When this feature is set, the feature
Enable-Fast-Recent-Test
will have no effect, so the checking may be slower.
Another reason why you might want to use this feature is that Alpine sometimes
opens folders implicitly behind the scenes, and this clears the
Recent status of all messages in the folder.
One example where this happens is when Saving or filtering a
message to another folder.
If that message has some keywords
set, then because of some shortcomings
in the IMAP specification, the best way to ensure that those keywords are
still set in the saved copy of the message is to open the folder and
set the keywords explicitly.
Because this clears the Recent status of all messages in that folder the
folder will not be found by the NextNew command unless this feature is set.
- tab-visits-next-new-message-only
- This feature affects Alpine's behavior when using the TAB
key to move from one message to the next.
Alpine's usual behavior is to select the next
Unread message or message flagged as Important.
Setting this feature causes Alpine to skip the
messages flagged as Important,
and select Unread messages exclusively.
Tab behavior when there are no
new messages left to select remains unchanged.
- termdef-takes-precedence
- This feature may affect Alpine's low-level input routines. Termcap (or
terminfo, depending on how your copy of Alpine was compiled and linked)
is the name of the database which describes terminal capabilities. In
particular, it describes the sequences of characters that various keys
will emit.
An example would be the Up Arrow key on the keyboard. Up
Arrow is not a distinct character on most Unix systems. When you press
the Up Arrow key a short sequence of characters are produced. This
sequence is supposed to be described in the termcap database by the
"ku" capability (or by the "kcuu1" capability if you
are using terminfo instead of termcap).
By default, Alpine defines some terminal
escape sequences that are commonly used. For example, the sequence
"ESC O A" is recognized as an Up Arrow key. The sequence
"ESC [ A"
is also recognized as an Up Arrow key. These are chosen because common
terminals like VT100's or ANSI standard terminals produce these
sequences when you press the Up Arrow key.
If your system's termcap
(terminfo) database assigns some other function to the sequence
"ESC O A"
it is usually ignored by Alpine. Also, if your termcap (terminfo)
database assigns a sequence which doesn't begin with an escape
character (ESC) it is usually ignored by Alpine.
This usually works fine
because most terminals emit the escape sequences that Alpine has defined
by default. We have also found that it is usually better to have these
defaults take precedence over the definitions contained in the database
because the defaults are more likely to be correct than the database.
There are some terminals where this breaks down. If you want Alpine to
believe the definitions given in your termcap (terminfo) database in
preference to the defaults the Alpine itself sets up, then you may turn
this feature on. Then, sequences of characters which are defined in
both termcap (terminfo) and in Alpine's set of defaults will be
interpreted the way that termcap (terminfo) says they should be
interpreted. Also, if your terminal capabilities database assigns a
sequence which doesn't begin with escape, it will not be ignored.
- thread-index-shows-important-color
- This option affects only the THREAD INDEX screen.
Whether or not you ever see a THREAD INDEX screen depends on the setting
of the configuration option
threading-index-style
and on the sort order of the index.
If a message within a thread is flagged as Important
and this option is set, then
the entire line in the THREAD INDEX will be colored the color of the
Index-important Symbol, which can be set using the
Setup Kolor screen.
- try-alternative-authentication-driver-first
- This feature affects how Alpine connects to IMAP servers.
It's utility has largely been overtaken by events,
but it may still be useful in some circumstances.
If you only connect to modern IMAP servers that support
"TLS" you can ignore this feature.
Details:
By default, Alpine will attempt to connect to an IMAP server on the
normal IMAP service port (143), and if the server offers "Transport Layer
Security" (TLS) and Alpine has been compiled with encryption capability,
then a secure (encrypted) session will be negotiated.
With this feature enabled, before connecting on the normal IMAP port, Alpine
will first attempt to connect to an alternate IMAP service port (993) used
specifically for encrypted IMAP sessions via the Secure Sockets Layer
(SSL) method.
If the SSL attempt fails, Alpine will then try the default
behavior described in the previous paragraph.
TLS negotiation on the normal port is preferred, and supersedes the use of
SSL on port 993, but older servers may not provide TLS support.
This feature may be convenient when accessing IMAP servers that do not support
TLS, but do support SSL connections on port 993.
However, it is important to understand that with this feature enabled,
Alpine will attempt to make a secure connection if that is possible,
but it will proceed to make an insecure connection if that is the only
option offered by the server, or if the Alpine in question has been built
without encryption capability.
Note that this feature specifies a per-user (or system-wide) default
behavior, but host/folder specification flags may be used to control the
behavior of any specific connection.
This feature interacts with some of
the possible host/folder path specification flags as follows:
The /tls host flag, for example,
{foo.example.com/tls}INBOX
will over-ride this feature for the specified host by bypassing the
SSL connection attempt.
Moreover, with /tls specified,
the connection attempt will fail if the
service on port 143 does not offer TLS support.
The /ssl host flag, for example,
{foo.example.com/ssl}INBOX
will insist on an SSL connection for the specified host,
and will fail if the SSL service on port 993 is not available.
Alpine will not subsequently retry a connection
on port 143 if /ssl is specified.
- unselect-will-not-advance
- Normally, when the Unselect current message command (:) is typed when the
current message is selected, the message will be unselected and the next
message will become the current message.
If this feature is set, the cursor will not advance to the next message.
Instead, the current message will remain the current message after
unselecting.
- use-current-dir
- This feature controls an aspect of several commands. If set, your
"current working directory" will be used instead of your home directory
for all of the following operations:
- Export in the "Folder Index" and "Message Text" screens
- Attachment Save in the "Message Text" and "Attachment Text" screens
- ^R file inclusion in the Composer
- ^J file attachment in the Composer
This feature is displayed as "Use Current Directory".
- use-function-keys
- This feature specifies that Alpine will
respond to function keys instead of
the normal single-letter commands. In this mode, the key menus at the
bottom of each screen will show function key designations instead of the
normal mnemonic key.
- use-regular-startup-rule-for-stayopen-folders
- This feature affects which message is selected as the current message
when you enter a
Stay Open folder.
Normally, the starting position for an incoming folder (which most Stay Open
folders will likely be) is controlled by the
Incoming-Startup-Rule.
However, if a folder is a Stay Open folder, when you re-enter the folder
after the first time the current message will be the same as it was when
you left the folder.
An exception is made if you use the TAB command to get to the folder.
In that case, the message number will be incremented by one from what it
was when you left the folder.
The above special behavior is thought to be useful.
However, it is special and different from what you might at first expect.
If this feature is set, then Stay Open folders will not be treated specially
as far as the startup rule is concerned.
- use-resent-to-in-rules
- This feature is turned off by default because turning it on causes problems
with some deficient IMAP servers.
In Alpine Filters and other types of Rules, if the
Pattern
contains a To header pattern and this feature is turned on,
then a check is made in the message to see
if a Resent-To header is present, and that is used instead of the To header.
If this feature is not turned on, then the regular To header will always
be used.
- use-sender-not-x-sender
- Normally Alpine on Unix adds a header line labeled X-X-Sender,
if the sender is different from the From: line.
The standard specifies that this header
line should be labeled Sender, not X-X-Sender.
Setting this feature causes
Sender to be used instead of X-X-Sender. The standard also states
that the data associated with this header field should not be used as a Reply address.
Unfortunately, certain implementations of mail list management servers will use the
Sender address for such purposes. These implementations often even recognize the
X-Sender fields as being equivalent to the Sender field, and use it
if present. This is why Alpine defaults to X-X-Sender.
Note, PC-Alpine always adds
either an X-X-Sender line if there is an open, remote mailbox, or an
X-Warning: UNAuthenticated User otherwise
This feature is displayed as "Use Sender Instead of X-X-Sender".
- use-subshell-for-suspend
- This feature affects Alpine's behavior when process suspension
is enabled and then activated via the ^Z key.
Alpine suspension allows one to
temporarily interact with the operating system command "shell" without
quitting Alpine,
and then subsequently resume the still-active Alpine session.
When the enable-suspend feature is set and subsequently the
^Z key is pressed,
Alpine will normally suspend itself and return temporary
control to Alpine's parent shell process.
However, if this feature is set, Alpine will instead create an
inferior subshell process.
This is useful when the parent process is not intended to be used
interactively.
Examples include invoking Alpine via the -e
argument
of the Unix xterm program, or via a menu system.
Note that one typically resumes a suspended Alpine by entering the Unix
fg command, but if this feature is set, it will be necessary to enter
the exit command instead.
- use-system-translation
- UNIX Alpine only. Alpine normally uses its own internal software to convert between the multi-byte
representation of characters and the Unicode representation of those
same characters
( see the section on International Character Sets).
It converts from the multi-byte characters your keyboard produces to Unicode,
and from Unicode to the multi-byte characters your display expects.
Alpine also uses its own internal software to decide how much space on
the screen a particular Unicode character will occupy.
Setting this feature tells Alpine to use the system-supplied routines to
perform these tasks instead.
In particular there are three tasks and three system routines that will
be used for these tasks.
To convert from multi-byte to Unicode the routine
mbstowcs
is used.
To convert from Unicode to multi-byte the routine
wcrtomb
is used.
And to find the screen width a particular Unicode character will
occupy the routine used is
wcwidth
This feature has been only lightly tested.
The internal routines should normally be used unless you run into
a problem that you think may be solved by using the system routines.
Note that your environment needs to be set up for these
routines to work correctly.
In particular, the LANG or LC_CTYPE variable in your environment will
need to be set.
- vertical-folder-list
- This feature controls an aspect of Alpine's FOLDER LIST screen. If set,
the folders will be listed alphabetically down the columns rather
than across the columns as is the default.
This feature is displayed as "Use Vertical Folder List".
- warn-if-blank-subject
- This feature affects Alpine's behavior when you send a message being
composed.
If this option is set, Alpine will check to see if the message about to be sent
has a subject or not.
If not, you will be asked if you want to send the message anyway.
- warn-if-blank-to-and-cc-and-newsgroups
- This feature affects Alpine's behavior when you send a message being
composed.
If this option is set, Alpine will check to see if the message about to be sent
has either a To address, a Cc address, or a Newsgroup.
If none of these is set,
you will be asked if you want to send the message anyway.
This feature is closely related to
fcc-only-without-confirm.
Alpine will normally ask if you want to copy a message only to the Fcc.
This feature also applies to cases where there is a Bcc but still no To, Cc,
or Newsgroup.
If the Fcc-Only-Without-Confirm feature is set and you are sending a
message with only an Fcc, then you won't be asked about sending with
a blank To and Cc and Newsgroups header even if this feature is set.
Similarly, if you have already been asked if you want to send to the Fcc
only and you have answered Yes, then you won't be asked again about sending with
blank To, Cc, and Newsgroups headers even if this feature is set.
There are several configuration variables and features which are normally hidden
from the user. That is, they don't appear on any of the configuration
screens. Some of these are suppressed because they are intended to be used
by system administrators, and in fact may only be set in system-wide
configuration files. Others are available to users but are thought to be
of such little value to most users that their presence on the Config
screens would cause more confusion than help.
Others are hidden in the Setup/Config screen because they are normally
configured in one of the other configuration screens. For example, all
of the colors are hidden because the normal way to configure colors is
through Setup/Colors not Setup/Config.
You may set the feature expose-hidden-config
to cause most of these hidden variables and features to show up at the bottom
of the Setup/Config screen.
Hidden Variables Not Settable by Users
These variables are settable only in system-wide configuration files.
Hidden Variables Which are Settable by Users
These variables are not shown to users but are settable by means
of hand editing the personal configuration file. This first group
is usually maintained by Alpine and there will usually
be no reason to edit them by hand.
This group is usually correct but may be changed by system managers or
users in special cases.
System managers are usually interested in setting these in the system-wide
configuration files, though users may set them if they wish.
Hidden Features Which are Settable by Users
These are features (as opposed to variables) which users or system
administrators may set. Some of them only make sense for administrators.
To turn these on manually, the configuration file should be edited and the
feature added to the feature-list variable.
You may set the feature expose-hidden-config
to cause these hidden features to show up in the Setup/Config screen.
They will be at the bottom of the screen.
Variables and features that are no longer used by the current Alpine version.
When an obsolete variable is encountered, its value is applied to any new
corresponding setting.
The replaced values include:
- character-set
- Replaced by three separate variables:
display-character-set,
keyboard-character-set, and
posting-character-set.
- compose-mime
- elm-style-save
- Replaced by saved-msg-name-rule
- feature-level
- Replaced by feature-list.
- header-in-reply
- Replaced by include-header-in-reply in the
feature-list.
- old-style-reply
- Replaced by signature-at-bottom in the
feature-list.
- use-old-unix-format-write
- No replacement.
- patterns
- Replaced by four separate patterns variables:
patterns-roles,
patterns-filters,
patterns-scores, and
patterns-indexcolors.
Since then, patterns-filters has also become obsolete and is replaced
by patterns-filters2; patterns-scores is replaced by
patterns-scores2.
- save-by-sender
- Replaced by saved-msg-name-rule.
- show-all-characters
- No replacement, it always works this way now.
Tokens for Index and Replying
This set of special tokens may be used in the
index-format option,
in the reply-leadin option,
in signature files,
in template files used in
roles,
and in the folder name that is the target of a Filter Rule.
Some of them aren't available in all situations.
The tokens are used as they appear below for the Index-Format
option, but they must be surrounded by underscores for the
Reply-Leadin option, in signature and template files,
and in the target of Filter Rules.
Tokens Available for all Cases (except Filter Rules)
- SUBJECT
-
This token represents the Subject the sender gave the message.
Alternatives for use in the index screen are
SUBJKEY, SUBJKEYINIT, SUBJECTTEXT, SUBJKEYTEXT, and SUBJKEYINITTEXT.
You may color the subject text in the MESSAGE INDEX screen differently by using the
Index Subject Color
and the
Index Opening Color.
options available from
the Setup Kolor screen.
- FROM
-
This token represents the personal name (or email address if the name
is unavailable) of the person specified in the message's "From:"
header field.
You may color the from text in the MESSAGE INDEX screen differently by using the
Index From Color
option available from the Setup Kolor screen.
- ADDRESS
-
This is similar to the "FROM" token, only it is always the
email address, never the personal name.
For example, "mailbox@domain".
- MAILBOX
-
This is the same as the "ADDRESS" except that the
domain part of the address is left off.
For example, "mailbox".
- SENDER
-
This token represents the personal name (or email address) of the person
listed in the message's "Sender:" header field.
- TO
-
This token represents the personal names (or email addresses if the names
are unavailable) of the persons specified in the
message's "To:" header field.
- NEWSANDTO
-
This token represents the newsgroups from the
message's "Newsgroups:" header field and
the personal names (or email addresses if the names
are unavailable) of the persons specified in the
message's "To:" header field.
- TOANDNEWS
-
Same as "NEWSANDTO" except in the opposite order.
- NEWS
-
This token represents the newsgroups from the
message's "Newsgroups:" header field.
- CC
-
This token represents the personal names (or email addresses if the names
are unavailable) of the persons specified in the
message's "Cc:" header field.
- RECIPS
-
This token represents the personal names (or email addresses if the names
are unavailable) of the persons specified in both the
message's "To:" header field and
the message's "Cc:" header field.
- NEWSANDRECIPS
-
This token represents the newsgroups from the
message's "Newsgroups:" header field and
the personal names (or email addresses if the names
are unavailable) of the persons specified in the
message's "To:" and "Cc:" header fields.
- RECIPSANDNEWS
-
Same as "NEWSANDRECIPS" except in the opposite order.
- INIT
-
This token represents the initials from the personal name
of the person specified in the message's "From:"
header field.
If there is no personal name, it is blank.
- DATE
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format MMM DD. For example, "Oct 23".
The feature
convert-dates-to-localtime,
which adjusts for the timezone the message was sent from,
may have an affect on the value of this token as well as the values of
all of the other DATE or TIME tokens.
Some of the DATE and TIME tokens are displayed in a locale-specific
way unless the option
Disable-Index-Locale-Dates is set.
- SMARTDATE
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It is "Today" if the message was sent today,
"Yesterday" for yesterday,
"Wednesday" if it was last Wednesday, and so on. If the
message is from last year and is more than six months old it includes the year, as well.
There is no adjustment made for different time zones, so you'll get
the day the message was sent according to the time zone the sender
was in.
See the SMARTDATE alternatives below, as well.
- SMARTTIME
-
This token represents the most relevant elements of the date on which
the message was sent (according to the "Date" header field),
in a compact form. If the message was sent today, only the time is used
(e.g. "9:22am", "10:07pm"); if it was sent during
the past week, the day of the week and the hour are used
(e.g. "Wed09am", "Thu10pm"); other dates are
given as date, month, and year (e.g. "23Aug00",
"9Apr98").
There is no adjustment made for different time zones, so you'll get
the day/time the message was sent according to the time zone the sender
was in.
- SMARTDATETIME
-
This is a combination of SMARTDATE and SMARTTIME.
It is SMARTDATE unless the SMARTDATE value is "Today", in which
case it is SMARTTIME.
See the SMARTDATETIME alternatives below, as well.
- DATEISO
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format YYYY-MM-DD. For example, "1998-10-23".
- SHORTDATEISO
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format YY-MM-DD. For example, "98-10-23".
- SHORTDATE1
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format MM/DD/YY. For example, "10/23/98".
- SHORTDATE2
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format DD/MM/YY. For example, "23/10/98".
- SHORTDATE3
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format DD.MM.YY. For example, "23.10.98".
- SHORTDATE4
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format YY.MM.DD. For example, "98.10.23".
- LONGDATE
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It has the format MMM DD, YYYY. For example, "Oct 23, 1998".
- SMARTDATE alternatives
-
There are several versions of SMARTDATE which are all the same except
for the way they format dates far in the past.
SMARTDATE formats the date using the information from your locale settings
to format the date string. It may end up formatting dates so that they look
like DATEISO tokens, or SHORTDATE2 tokens, or something else entirely.
The feature
convert-dates-to-localtime
may have an affect on the values of these tokens.
If you want more control you may use one of the following.
- SMARTDATE
- If the option
Disable-Index-Locale-Dates is not set
then this will be locale specific. Control this with the
LC_TIME locale setting on a UNIX system. On Windows
the Regional Options control panel may be used to set the Short date
format. At the programming level, the strftime routine is what Alpine
uses to print the date.
If the Disable-Index-Locale-Dates option is set then this is equivalent
to SMARTDATES1.
- SMARTDATEISO
- DATEISO format. See text above.
- SMARTDATESHORTISO
- SHORTDATEISO format.
- SMARTDATES1
- SHORTDATE1 format.
- SMARTDATES2
- SHORTDATE2 format.
- SMARTDATES3
- SHORTDATE3 format.
- SMARTDATES4
- SHORTDATE4 format.
- SMARTDATETIME alternatives
-
There are several versions of SMARTDATETIME which are all very similar.
The ones which end in 24 use a 24-hour clock for Today's messages instead
of a 12-hour clock.
The other variation is
for the way they format dates far in the past.
SMARTDATETIME and SMARTDATETIME24 format the date using the information from your locale settings
to format the date string. It may end up formatting dates so that they look
like DATEISO tokens, or SHORTDATE2 tokens, or something else entirely.
The feature
convert-dates-to-localtime
may have an affect on the values of these tokens.
The possible choices are:
- SMARTDATETIME
- Locale specific. Control this with the
LC_TIME locale setting on a UNIX system. On Windows
the Regional Options control panel may be used to set the Short date
format. At the programming level, the strftime routine is what Alpine
uses to print the date.
- SMARTDATETIME
- If the option
Disable-Index-Locale-Dates is not set
then this will be locale specific. Control this with the
LC_TIME locale setting on a UNIX system. On Windows
the Regional Options control panel may be used to set the Short date
format. At the programming level, the strftime routine is what Alpine
uses to print the date.
If the Disable-Index-Locale-Dates option is set then this is equivalent
to SMARTDATETIMES1.
- SMARTDATETIME24
- Use TIME24 for Today
- SMARTDATETIMEISO
- DATEISO format. See text above.
- SMARTDATETIMEISO24
- Use TIME24 for Today
- SMARTDATETIMESHORTISO
- SHORTDATEISO format.
- SMARTDATETIMESHORTISO24
- Use TIME24 for Today
- SMARTDATETIMES1
- SHORTDATE1 format.
- SMARTDATETIMES124
- Use TIME24 for Today
- SMARTDATETIMES2
- SHORTDATE2 format.
- SMARTDATETIMES224
- Use TIME24 for Today
- SMARTDATETIMES3
- SHORTDATE3 format.
- SMARTDATETIMES324
- Use TIME24 for Today
- SMARTDATETIMES4
- SHORTDATE4 format.
- SMARTDATETIMES424
- Use TIME24 for Today
- DAYDATE
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It looks like "Sat, 23 Oct 1998".
This token is never converted in any locale-specific way.
- PREFDATE
-
This token represents the date on which the message was sent, according
to the "Date" header field.
It is your operating system's idea of the preferred date representation for the current locale.
Internally it uses the %x version of the date from the strftime routine.
- PREFTIME
-
This token represents the time at which the message was sent, according
to the "Date" header field.
It is the preferred time representation for the current locale.
Internally it uses the %X version of the time from the strftime routine.
- PREFDATETIME
-
This token represents the date and time at which the message was sent, according
to the "Date" header field.
It is the preferred date and time representation for the current locale.
Internally it uses the %c version of the time from the strftime routine.
- DAY
-
This token represents the day of the month on which the message was sent,
according to the "Date" header field.
For example, "23" or "9".
- DAY2DIGIT
-
This token represents the day of the month on which the message was sent,
according to the "Date" header field.
For example, "23" or "09".
It is always 2 digits.
- DAYORDINAL
-
This token represents the ordinal number which is the day of
the month on which the message was sent,
according to the "Date" header field.
For example, "23rd" or "9th".
- DAYOFWEEK
-
This token represents the day of the week on which the message was sent,
according to the "Date" header field.
For example, "Sunday" or "Wednesday".
- DAYOFWEEKABBREV
-
This token represents the day of the week on which the message was sent,
according to the "Date" header field.
For example, "Sun" or "Wed".
- MONTHABBREV
-
This token represents the month the message was sent, according
to the "Date" header field.
For example, "Oct".
- MONTHLONG
-
This token represents the month in which the message was sent, according
to the "Date" header field.
For example, "October".
- MONTH
-
This token represents the month in which the message was sent, according
to the "Date" header field.
For example, "10" or "9".
- MONTH2DIGIT
-
This token represents the month in which the message was sent, according
to the "Date" header field.
For example, "10" or "09".
It is always 2 digits.
- YEAR
-
This token represents the year the message was sent, according
to the "Date" header field.
For example, "1998" or "2001".
- YEAR2DIGIT
-
This token represents the year the message was sent, according
to the "Date" header field.
For example, "98" or "01".
It is always 2 digits.
- TIME24
-
This token represents the time at which the message was sent, according
to the "Date" header field.
There is no adjustment made for different time zones, so you'll get
the time the message was sent according to the time zone the sender
was in.
It has the format HH:MM. For example, "17:28".
- TIME12
-
This token represents the time at which the message was sent, according
to the "Date" header field.
This time is for a 12 hour clock.
It has the format HH:MMpm.
For example, "5:28pm" or "11:13am".
- TIMEZONE
-
This token represents the numeric timezone from
the "Date" header field.
It has the format [+-]HHMM. For example, "-0800".
Tokens Available Only for Index-Format
- MSGNO
-
This token represents the message's current position in the folder which,
of course, may change as the folder is sorted or new mail arrives.
- STATUS
-
This token represents a three character wide field displaying various
aspects of the message's state.
The first character is either blank,
a '*' for message marked Important, or a '+' indicating a message
addressed directly to you (as opposed to your having received it via a
mailing list, for example).
When the feature
mark-for-cc
is set, if the first character would have been
blank then it will instead be a '-' if the message is cc'd to you.
The second character is typically blank,
though the arrow cursor may occupy it if either the
assume-slow-link
or the
force-arrow-cursor feature
is set (or you actually are on a slow link).
The third character is either D (Deleted),
A (Answered),
N (New), or blank.
If you are using a threaded view of the index and this message is at the
top of a collapsed portion of a thread,
then this token refers to all of the messages in the collapsed portion of
the thread instead of just the top message.
The first character will be a '*' if any of the messages in the thread
are marked Important, else a '+' if any of the messages are addressed
to you, else a '-' if any of the messages are cc'd to you.
The third character will be a 'D' if all of the messages
in the collapsed thread are marked deleted,
an 'A' if all of the messages
in the collapsed thread are marked answered,
it will be an 'N' if any of
the messages are undeleted and unseen, and it will be blank otherwise.
- FULLSTATUS
-
This token represents a less abbreviated alternative
to the "STATUS" token.
It is six characters wide.
The first character is '+', '-', or blank, the
second blank, the third either '*' or blank, the fourth
N or blank,
the fifth A
or blank, and the sixth character is
either D or
blank.
If you are using a threaded view of the index and this message is at the
top of a collapsed portion of a thread,
then this token refers to all of the messages in the collapsed portion of
the thread instead of just the top message.
The first character is '+', '-', or blank depending on whether any
of the messages in the collapsed thread are addressed to you or cc'd to you.
The third character will be '*' if any of the messages are marked
Important.
The fourth character will be 'N' if all of the messages in the thread
are New, else 'n' if some of the messages in the thread are New, else blank.
The fifth character will be 'A' or 'a' or blank, and the sixth character
will be 'D' or 'd' or blank.
- IMAPSTATUS
-
This token represents an even less abbreviated alternative to the
"STATUS" token.
It differs from "FULLSTATUS" in only the fourth character which is
an 'N' if the message is new to this folder since the last time
it was opened and it has not been viewed, an 'R' (Recent) if the message
is new to the folder and has been viewed, a 'U' (Unseen) if the message is not
new to the folder since it was last opened but has not been
viewed, or a blank if the message has been in the folder since it was
last opened and has been viewed.
If you are using a threaded view of the index and this message is at the
top of a collapsed portion of a thread,
then the fourth character will be
'N' if all of the messages in the thread are unseen and recent;
else 'n' if some of the messages in the thread are unseen and recent;
else 'U' if all of the messages in the thread are unseen and not recent;
else 'u' if some of the messages in the thread are unseen and not recent;
else 'R' if all of the messages in the thread are seen and recent;
else 'r' if some of the messages in the thread are seen and recent;
else blank.
- SHORTIMAPSTATUS
-
This is the same as the last four of the six characters of IMAPSTATUS,
so the '+' To Me information will be missing.
- SIZE
-
This token represents the total size, in bytes, of the message.
If a "K" (Kilobyte)
follows the number, the size is approximately 1,000
times that many bytes (rounded to the nearest 1,000).
If an "M" (Megabyte) follows the number, the size is approximately
1,000,000 times that many bytes.
Commas are not used in this field.
This field is seven characters wide, including the enclosing parentheses.
Sizes are rounded when "K" or "M" is present.
The progression of sizes used looks like:
0 1 ... 9999 10K ... 999K 1.0M ... 99.9M 100M ... 2000M
- SIZECOMMA
-
This token represents the total size, in bytes, of the message.
If a "K" (Kilobyte)
follows the number, the size is approximately 1,000
times that many bytes (rounded to the nearest 1,000).
If an "M" (Megabyte) follows the number, the size is approximately
1,000,000 times that many bytes.
Commas are used if the number shown is 1,000 or greater.
The SIZECOMMA field is one character wider than the SIZE field.
Sizes are rounded when "K" or "M" is present.
The progression of sizes used looks like:
0 1 ... 99,999 100K ... 9,999K 10.0M ... 999.9M 1,000M ... 2,000M
- KSIZE
-
This token represents the total size of the message, expressed in
kilobytes or megabytes, as most appropriate.
These are 1,024 byte kilobytes and 1,024 x 1,024 byte megabytes.
The progression of sizes used looks like:
0K 1K ... 1023K 1.0M ... 99.9M 100M ... 2047M
- SIZENARROW
-
This token represents the total size, in bytes, of the message.
If a "K" (Kilobyte)
follows the number, the size is approximately 1,000
times that many bytes.
If an "M" (Megabyte) follows the number, the size is approximately
1,000,000 times that many bytes.
If a "G" (Gigabyte) follows the number, the size is approximately
1,000,000,000 times that many bytes.
This field uses only five characters of screen width, including the enclosing
parentheses.
The progression of sizes used looks like:
0 1 ... 999 1K ... 99K .1M ... .9M 1M ... 99M .1G ... .9G 1G 2G
- DESCRIPSIZE
-
This token is intended to represent a more useful description of the
message than just its size, but it isn't very useful at this point.
The plus sign in this view means there are attachments.
Note that including this token in
the "Index-Format" could slow down the
display a little while Alpine collects the necessary information.
- SUBJKEY
-
This token is the same as the SUBJECT token unless keywords are set for
the message.
In that case, a list of keywords enclosed in braces will be prepended to
the subject of the message.
Only those keywords that you have defined in your
Keywords option
in Setup/Config are considered in the list.
In other words, keywords that have been set by some other means, perhaps
by another email program, won't show up unless included in
Keywords.
Having this set in the Index-Format will also cause the keywords to be
prepended to the subject in the MESSAGE TEXT screen.
If you have given a keyword a nickname
(keywords), that nickname is displayed
instead of the actual keyword.
The keyword-surrounding-chars
option may be used to modify this token slightly.
It is also possible to color keywords in the index using the
Setup/Kolor screen.
- SUBJKEYINIT
-
This token is the same as the SUBJKEY token except that instead of
prepending a list of keywords to the subject, a list of first initials
of keywords will be prepended instead.
For example, if a message has the keywords Work and Now
set (or Work and Now are the Alpine nicknames of keywords which are set)
then the SUBJKEY token would cause a result like
{Work Now} actual subject
whereas the SUBJKEYINIT token would give
{WN} actual subject
Only those keywords that you have defined in your
Keywords option
in Setup/Config are considered in the list.
In other words, keywords that have been set by some other means, perhaps
by another email program, won't show up unless included in
Keywords.
The keyword-surrounding-chars
option may be used to modify this token slightly.
It is also possible to color keywords in the index using the
Setup/Kolor screen.
- SUBJECTTEXT
-
Same as SUBJECT but if there is room in the Subject field for more text,
the opening part of the text of the message is displayed after the subject.
The time needed to fetch the text may cause a performance problem
which can, of course, be avoided by using the SUBJECT version of
the Subject instead.
You may color this opening text differently by using the
Index Opening Color option available from
the Setup Kolor screen.
You may adjust the characters that are displayed between the Subject and the
opening text with the option
Opening-Text-Separator-Chars.
- SUBJKEYTEXT
-
Same as SUBJKEY but with the opening message text.
- SUBJKEYINITTEXT
-
Same as SUBJKEYINIT but with the opening message text.
- OPENINGTEXT
-
This is similar to SUBJECTTEXT.
Instead of combining the Subject and the opening text in a single
field in the index screen this token allows you to allocate a
separate column just for the opening text of the message.
The time needed to fetch this text may cause a performance problem.
You may color this opening text differently by using the
Index Opening Color option available from
the Setup Kolor screen.
- OPENINGTEXTNQ
-
This is very similar to OPENINGTEXT.
The NQ stands for No Quotes.
The only difference is that quoted text (lines beginning with >) is deleted.
For some messages this may be confusing.
For example, a message might have a line preceding some quoted
text that reads something like "On May 8th person A said."
That no longer makes sense after the quoted text is deleted and it
will appear that person A said whatever the text after the quote
is, even though that is really person B talking.
- KEY
-
This is a space-delimited list of keywords that are set for the message.
Only those keywords that you have defined in your
Keywords option
in Setup/Config are considered in the list.
In other words, keywords that have been set by some other means, perhaps
by another email program, won't show up unless included in
Keywords.
If you have given a keyword a nickname
that nickname is displayed
instead of the actual keyword.
It is also possible to color keywords in the index using the
Setup/Kolor screen.
This token defaults to an arbitrary width of 5.
You should set it to whatever width suits you using something
like KEY(17) in the Index-Format.
- KEYINIT
-
This is a list of keyword initials that are set for the message.
If you have given a keyword a nickname
the initial of that nickname
is displayed instead of the initial of the actual keyword.
It is also possible to color keyword initials in the index using the
Setup/Kolor screen.
This token defaults to an arbitrary width of 2.
You should set it to whatever width suits you using something
like KEYINIT(3) in the Index-Format.
- PRIORITY
-
The X-Priority header is a non-standard header that is used in a
somewhat standard way by many mail programs.
Alpine expects the value of this header to be a digit with a value
from 1 to 5, with 1 being the highest priority and 5 the lowest priority.
Since this priority is something that the sender sets it is only an indication
of the priority that the sender attaches to the mail and it is therefore almost
totally unreliable for use as a filtering criterion.
This token will display the numeric value of the priority if it is between
1 and 5.
It will be suppressed (blank) if the value is 3, which is normal priority.
It is also possible to set the color of the PRIORITY field.
By default the token is colored the same
as the index line it is part of.
You may set it to be another color with the
Index Priority Colors options available from
the Setup Kolor screen.
- PRIORITYALPHA
-
This is a more verbose interpretation of the X-Priority field.
Once again nothing is displayed unless the value of the field
is 1, 2, 4, or 5.
The values displayed for those values are:
| 1 | Highest |
| 2 | High |
| 4 | Low |
| 5 | Lowest |
You may color this token with the
Index Priority Colors options.
- PRIORITY!
-
This is a one character, non-numeric version of the X-Priority field.
If the value of the X-Priority header is 1 or 2 an exclamation
point is displayed.
If the value is 4 or 5 a "v" (think down arrow) is displayed.
You may color this token with the
Index Priority Colors options.
- ATT
-
This is a one column wide field which represents the number of attachments
a message has. It will be blank if there are no attachments, a single
digit for one to nine attachments, or an asterisk for more than nine.
Note that including this token in
the "Index-Format" could slow down the
display a little while Alpine collects the necessary information.
- FROMORTO
-
This token represents either the personal name (or email address) of
the person listed in the message's "From:" header
field, or, if that address is yours or one of your
alternate addresses,
the first person specified in the
message's "To:" header field
with the prefix "To: " prepended.
If the from address is yours and there is also no "To" address,
Alpine will use the address on the "Cc" line.
If there is no address there, either, Alpine will look for a newsgroup name
from the "Newsgroups" header field and put
that after the "To: " prefix.
- FROMORTONOTNEWS
-
This is almost the same as FROMORTO.
The difference is that newsgroups aren't considered.
When a message is from you, doesn't have a To or Cc, and does have
a Newsgroups header; this token will be your name instead of the name
of the newsgroup (like it would be with FROMORTO).
- TEXT
-
This is a different sort of token.
It allows you to display a label within each index line.
It will be the same fixed text for each line.
It is different from all the other tokens in that there is no space column
displayed after this token.
Instead, it is butted up against the following field.
It also has a different syntax.
The text to display is given following a colon after the
word "TEXT".
For example,
TEXT:abc=
would insert the literal text "abc=" (without the quotes)
into the index display line.
You must quote the text if it includes space characters, like
TEXT:"abc = "
- HEADER
-
This allows you to display the text from a particular header line in the
message.
The syntax for this token is substantially different from all the others
in order that you might be able to display a portion of the text following
a particular header.
The header name you are interested in is given following a colon
after the word "HEADER".
For example,
HEADER:X-Spam
would display the text of the X-Spam header, if any.
Like for other index tokens a width field may (and probably should)
follow this.
HEADER:X-Spam(10)
displays the first ten characters of the X-Spam header.
Unlike other index tokens, the syntax for HEADER is more flexible.
An optional second argument comes after a comma inside the parentheses.
It specifies the "field" number.
By default, the field separator is a space character.
No extra space characters are allowed in the argument list.
HEADER:X-Spam(10,2)
would display the second field, left-justified, in a 10 character
wide field.
The second field would consist of all the text after the first space
up to the next space or the end of the header.
The default field number is zero, which stands for the entire line.
There is also an optional third argument which is a list of field
separators. It defaults to a space character.
The example
HEADER:X-Spam(10,2,:% )
would cause the field separators to be any of colon, percent,
or space (there is a space character between the percent and the
right parenthesis).
The first field runs from the start of the header value up to the first
colon, percent, or space; the second goes from there to the next; and so on.
In order to use a comma character as a field separator you must escape
it by preceding it with a backslash (\).
The same is true of the backslash character itself.
There is one further optional argument.
It is an R or an L to specify right or left adjustment of the text
within the field.
The default is to left justify, however if you are displaying numbers
you might prefer to right justify.
Here's an example of a SpamAssassin header.
The exact look of the header will vary, but if your incoming mail
contains headers that look like the following
X-Spam-Status: Yes, hits=10.6 tagged_above=-999.0 required=7.0 tests=BAYE...
you might want to display the hits value.
The first field starts with the Y in Yes.
To get what you're interested in you might use "=" and
space as the field separators and display the third field, like
HEADER:X-Spam-Status(4,3,= )
or maybe you would break at the dot instead
HEADER:X-Spam-Status(2,2,=.,R)
Another example we've seen has headers that look like
X-Spam: Gauge=IIIIIII, Probability=7%, Report=...
Because there are two equals and a comma before the 7% and a comma
after it, the token
HEADER:X-Spam-Status(3,4,=\,,R)
should display the probability (for example 7% or 83%) right justified
in a 3-wide field.
- ARROW
-
This gives an alternative way to display the current message in the
MESSAGE INDEX screen.
Usually the current message is indicated by the line being shown in
reverse video.
Instead, if the ARROW token is included in your Index-Format,
the current line will include an "arrow" that
looks like
->
in the ARROW token's field.
For all of the non-current messages, the ARROW field will be filled
with blanks.
If you use the fixed-field width feature the length of the "arrow"
may be adjusted.
The arrow will be drawn as width-1 dashes followed by a greater than sign.
For example, if you use ARROW(3) you will get
-->
and ARROW(1) will give you just
>
It is also possible to set the color of the ARROW field.
By default (and for non-current messages) the arrow is colored the same
as the index line it is part of.
You may set it to be another color with the
Index Arrow Color option available from
the Setup Kolor screen.
- SCORE
-
This gives the
score
of each message.
This will be six columns wide to accommodate the widest possible score.
You will probably want to use the Index-Format fixed-field width feature
to limit the width of the field to the widest score that
you use (e.g. SCORE(3) if your scores are always between 0 and 999).
If you have not defined any score rules the scores will all be zero.
If any of your score rules contain AllText or BodyText patterns
then including SCORE in the Index-Format
may slow down the display of the MESSAGE INDEX screen.
Tokens Available for all but Index-Format
- CURNEWS
-
This token represents the current newsgroup if there is one.
For example, "comp.mail.pine".
- MSGID
-
This token represents the message ID of the message.
This token does not work with Filter Rule folder names.
- CURDATE
-
This token represents the current date.
It has the format MMM DD. For example, "Oct 23".
- CURDATEISO
-
This token represents the current date.
It has the format YYYY-MM-DD. For example, "1998-10-23".
- CURDATEISOS
-
This token represents the current date.
It has the format YY-MM-DD. For example, "98-10-23".
- CURPREFDATE
-
This token represents the current date.
It is your operating system's idea of the preferred date representation for the current locale.
Internally it uses the %x version of the date from the strftime routine.
- CURPREFTIME
-
This token represents the current time.
It is the preferred time representation for the current locale.
Internally it uses the %X version of the time from the strftime routine.
- CURPREFDATETIME
-
This token represents the current date and time.
It is the preferred date and time representation for the current locale.
Internally it uses the %c version of the time from the strftime routine.
- CURTIME24
-
This token represents the current time.
It has the format HH:MM. For example, "17:28".
- CURTIME12
-
This token represents the current time.
This time is for a 12 hour clock.
It has the format HH:MMpm.
For example, "5:28pm" or "11:13am".
- CURDAY
-
This token represents the current day of the month.
For example, "23" or "9".
- CURDAY2DIGIT
-
This token represents the current day of the month.
For example, "23" or "09".
It is always 2 digits.
- CURDAYOFWEEK
-
This token represents the current day of the week.
For example, "Sunday" or "Wednesday".
- CURDAYOFWEEKABBREV
-
This token represents the current day of the week.
For example, "Sun" or "Wed".
- CURMONTH
-
This token represents the current month.
For example, "10" or "9".
- CURMONTH2DIGIT
-
This token represents the current month.
For example, "10" or "09".
It is always 2 digits.
- CURMONTHLONG
-
This token represents the current month.
For example, "October".
- CURMONTHABBREV
-
This token represents the current month.
For example, "Oct".
- CURYEAR
-
This token represents the current year.
For example, "1998" or "2001".
- CURYEAR2DIGIT
-
This token represents the current year.
For example, "98" or "01".
It is always 2 digits.
- LASTMONTH
-
This token represents last month.
For example, if this is November (the 11th month),
it is equal to "10" or if this is October (the 10th month),
it is "9".
It is possible that this and the other tokens beginning with LASTMONTH
below could be useful when used with a Filtering Rule that
has the "Beginning of Month" option set.
- LASTMONTH2DIGIT
-
This token represents last month.
For example, if this is November (the 11th month),
it is equal to "10" or if this is October (the 10th month),
it is "09".
It is always 2 digits.
- LASTMONTHLONG
-
This token represents last month.
For example, if this is November the value is "October".
- LASTMONTHABBREV
-
This token represents last month.
For example, if this is November the value is "Oct".
- LASTMONTHYEAR
-
This token represents what the year was a month ago.
For example, if this is October, 1998, it is "1998".
If this is January, 1998, it is "1997".
- LASTMONTHYEAR2DIGIT
-
This token represents what the year was a month ago.
For example, if this is October, 1998, it is "98".
If this is January, 1998, it is "97".
- LASTYEAR
-
This token represents last year.
For example, if this is 1998, it equals "1997".
It is possible that this
could be useful when used with a Filtering Rule that
has the "Beginning of Year" option set.
- LASTYEAR2DIGIT
-
This token represents last year.
For example, if this is 1998, it equals "97".
It is always 2 digits.
- ROLENICK
-
This token represents the nickname of the
role currently being used. If no role is being used,
then no text will be printed for this token.
This token does not work with Filter Rule folder names.
Token Available Only for Reply-Leadin
See the help for the
Reply-Leadin option,
to see why you might want to use this.
Since the Reply-Leadin contains free text this token
must be surrounded by underscores when used.
- NEWLINE
-
This is an end of line marker.
Token Available Only for Templates and Signatures
- CURSORPOS
-
This token is different from the others.
When it is replaced it is replaced with nothing, but it sets a Alpine
internal variable which tells the composer to start with the cursor
positioned at the position where this token was.
If both the template file and the signature file contain
a "CURSORPOS" token, then the position in the template file
is used.
If there is a template file and neither it nor the signature file contains
a "CURSORPOS" token, then the cursor is positioned
after the end of the contents of the
template file when the composer starts up.
Conditional Inclusion of Text for Reply-Leadin, Signatures, and Templates
Conditional text inclusion may be used with
the Reply-Leadin option,
in signature files, and in template files used in
roles.
It may not be used with the
Index-Format option.
There is a limited if-else capability for including text.
The if-else condition is based
on whether or not a given token would result in replacement text you
specify.
The syntax of this conditional inclusion is
_token_(match_this, if_matched [ , if_not_matched ] )
The left parenthesis must follow the underscore immediately, with no
intervening space.
It means the token is expanded and the results of that expansion are
compared against the "match_this" argument.
If there is an exact match, then the "if_matched" text is used
as the replacement text.
Otherwise, the "if_not_matched" text is used.
One of the most useful values for the "match_this" argument is
the empty string, "".
In that case the expansion is compared against the empty string.
Here's an example to make it clearer.
This text could be included in one of your template files:
_NEWS_("", "I'm replying to email","I'm replying to news")
If that is included in a template file which you are using while replying
to a message (because you chose to use the role it was part of),
and that message has a newsgroup header and a newsgroup in that header,
then the text
I'm replying to news
will be included in the message you are about to compose.
On the other hand, if the message you are replying to does not have
a newsgroup, then the text
I'm replying to email
would be included instead.
This would also work in signature files and in
the "Reply-Leadin" option.
If the "match_this", "if_matched",
or "if_not_matched" arguments contain
spaces, parentheses, or commas;
they have to be quoted with double quotation marks (like in the example
above).
If you want to include a literal quote in the text you must escape the
quote by preceding it with a backslash character.
If you want to include a literal backslash character you must escape it
by preceding it with another backslash.
The comma followed by "if_not_matched" is optional.
If there is no "if_not_matched"
present then no text is included if the not_matched case is true.
Here's another example:
_NEWS_("", "", "This msg was seen in group: _NEWS_.")
Here you can see that tokens may appear in the arguments.
The same is true for tokens with the conditional parentheses.
They may appear in arguments,
though you do have to be careful to get the quoting and escaping of
nested double quotes correct.
If this was in the signature file being used and you were replying to a message
sent to comp.mail.pine the resulting text would be:
This msg was seen in group: comp.mail.pine.
If you were replying to a message which wasn't sent to any newsgroup the
resulting text would be a single blank line.
The reason you'd get a blank line is because the end of the line is
outside of the conditional, so is always included.
If you wanted to get rid of that blank line you could do so by moving
the end of line inside the conditional.
In other words, it's ok to have multi-line
"if_matched" or "if_not_matched" arguments.
The text just continues until the next double quotation, even if it's not
on the same line.
Here's one more (contrived) example illustrating a matching argument
which is not the empty string.
_SMARTDATE_("Today", _SMARTDATE_, "On _DATE_") _FROM_ wrote:
If this was the value of your "Reply-Leadin" option and you
were replying to
a message which was sent today, then the value of the "Reply-Leadin"
would be
Today Fred Flintstone wrote:
But if you were replying to a message sent on Oct. 27 (and that wasn't
today) you would get
On Oct 27 Fred Flintstone wrote:
Per Server Directory Configuration
This is only available if Alpine was built with LDAP support.
If that's the case, there will be a Directory option underneath the Setup
command on the Main Menu.
Each server that is defined there has several configuration variables
which control the behavior when using it.
- ldap-server
- This is the name of the host where an LDAP server is running.
To find out whether your organization has its own LDAP server,
contact its computing support staff.
- search-base
- This is the search base to be used on this server.
It functions as a filter
by restricting your searches in the LDAP server database
to the specified contents of the specified fields.
Without it, searches submitted to this directory server may fail.
It might be something like:
O = <Your Organization Name>, C = US
or it might be blank.
(Some LDAP servers actually ignore anything specified here.)
If in doubt what parameters you should specify here,
contact the maintainers of the LDAP server.
- port
- This is the TCP port number to be used with this LDAP server.
If you leave this blank port
389
will be used.
- nickname
- This is a nickname to be used in displays.
If you don't supply a nickname the server name from
"ldap-server" will be used instead.
This option is strictly for your convenience.
- use-implicitly-from-composer
- Set this feature to have lookups done to this server implicitly from
the composer.
If an address doesn't look like a fully-qualified address, it will be looked
up in your address books, and if it doesn't match a nickname there, then it
will be looked up on the LDAP servers which have this feature set.
The lookups will also be done when using the address completion feature
(TAB command) in the composer if any of the serves have this feature set.
Also see the LDAP feature
lookup-addrbook-contents
and the Setup/Config feature
ldap-result-to-addrbook-add.
- lookup-addrbook-contents
- Normally implicit LDAP lookups from the composer are done only for the
strings you type in from the composer screen. In other words, you type in
something in the To or CC field and press return, then the string is looked up.
First that string is looked up in your address books. If a match is found
there, then the results of that match are looked up again. If you place
a string in your address book that you want to have looked up on the LDAP
directory server, you need to turn on this feature. If you set this feature
for a server, you almost always will also want to set the
use-implicitly-from-composer
feature.
An example might serve to best illustrate this feature.
If an LDAP lookup of "William Clinton" normally returns an
entry with an
address of<EMAIL_ADDRESS>then you might put an entry in your address
book that looks like:
Nickname Address
bill "William Clinton"
Now, when you type "bill" into an
address field in the composer Alpine will
find the "bill" entry in your address book.
It will replace "bill" with
"William Clinton".
It will then search for an entry with that nickname
in your address book and not find one. If this feature
is set, Alpine will then attempt to lookup
"William Clinton" on the LDAP server and find the entry with address
<EMAIL_ADDRESS>A better way to accomplish the same thing is probably to use the feature
save-search-criteria-not-result.
- save-search-criteria-not-result
- Normally when you save the results of an LDAP directory lookup to your
address book the results of the lookup are saved.
If this feature is set
and the entry being saved was found on this directory server, then the
search criteria is saved instead of the results of the search.
When this address book entry is used in the future, instead of copying
the results from the address book the directory lookup will be done again.
This could be useful if the copied result might become stale because the data on
the directory server changes (for example, the entry's email address changes).
You probably don't want to set this feature if the server is at all slow or
unreliable.
The way this actually works is that instead of saving the email address
in your address book, Alpine saves enough
information to look up the same directory entry again.
In particular, it saves the server name and the
distinguished name of the entry.
It's possible that the server administrators
might change the format of distinguished names on the server, or that the
entry might be removed from the server. If Alpine notices this, you will be warned
and a backup copy of the email address will be used. You may want to create
a new entry in this case, since you will get the annoying warning every
time you use the old entry. You may do that by Saving the entry to a new
nickname in the same address book. You will be asked whether or not you
want to use the backup email address.
A related feature in the Setup/Config screen is
ldap-result-to-addrbook-add.
- disable-ad-hoc-space-substitution
- Spaces in your input are normally handled specially.
Each space character is replaced
by
* <SPACE>
in the search query (but not by "* <SPACE> *").
The reason this is done is so the input string
Greg Donald
(which is converted to "Greg* Donald") will match
the names "Greg Donald",
"Gregory Donald", "Greg F. Donald", and
"Gregory F Donald"; but it won't match "Greg McDonald".
If the "Search-Rule" you were using was "begins-with",
then it would also match the name "Greg Donaldson".
Turning on this feature will disable this substitution.
- search-type
- This affects the way that LDAP searches are done.
In particular, this tells the server where to look for the string to be matched.
If set to "name" then the string that is being searched for will
be compared with the string in the
"Name" field on the server
(technically, it is the "commonname" field on the server).
"Surname" means we're looking for a
match in the "Surname" field on the
server (actually the "sn" field).
"Givenname" really is "givenname"
and "email" is the electronic mail address (this is actually the field
called "mail" or "electronicmail" on the server).
The other three types are combinations of
the types listed so far. "Name-or-email"
means the string should appear
in either the "name" field OR the "email" field.
Likewise, "surname-or-givenname"
means "surname" OR "givenname"
and "sur-or-given-or-name-or-email" means the obvious thing.
This search type is combined with the
search rule
to form the actual search query.
The usual default value for this
option is "sur-or-given-or-name-or-email".
This type of search may be slow on some servers.
Try "name-or-email", which is often
faster, or just "name" if the performance seems to be a problem.
Some servers have been configured with different attribute names for
these four fields.
In other words, instead of using the attribute name "mail"
for the email address field, the server might be configured to use something
else, for example, "rfc822mail" or "internetemailaddress".
Alpine can be configured to use these different attribute names by using
the four per-server configuration options:
- search-rule
- This affects the way that LDAP searches are done.
If set to "equals" then
only exact matches count.
"Contains" means that the string you type in
is a substring of what you are matching against.
"Begins-with" and "ends-with"
mean that the string starts or ends with the string you type in.
Spaces in your input are normally handled specially, but you can turn that
special handling off with the
disable-ad-hoc-space-substitution
feature.
The usual default value for this option is begins-with.
- email-attribute
- This is the name of the attribute which is searched for when looking for
an email address. The default value for this option is "mail" or
"electronicmail".
If the server you are using uses a different attribute name for the email
address, put that attribute name here.
This will affect the search filter used if your Search-Type is one that
contains a search for "email".
It will also cause the attribute value matching this attribute name to be used
as the email address when you look up an entry from the composer.
- name-attribute
- This is the name of the attribute which is searched for when looking for
the name of the entry. The default value for this option is "cn", which
stands for common name.
If the server you are using uses a different attribute name for the name,
put that attribute name here.
This will affect the search filter used if your Search-Type is one that
contains a search for "name".
- surname-attribute
- This is the name of the attribute which is searched for when looking for
the surname of the entry. The default value for this option is "sn".
If the server you are using uses a different attribute name for the surname,
put that attribute name here.
This will affect the search filter used if your Search-Type is one that
contains a search for "surname".
- givenname-attribute
- This is the name of the attribute which is searched for when looking for
the given name of the entry. The default value for this option is "givenname".
If the server you are using uses a different attribute name for the given name,
put that attribute name here.
This will affect the search filter used if your Search-Type is one that
contains a search for "givenname".
- timelimit
- This places a limit on the number of seconds the LDAP search will continue.
The default is 30 seconds. A value of 0 means no limit. Note that some servers
may place limits of their own on searches.
- sizelimit
- This places a limit on the number of entries returned by the LDAP server.
A value of 0 means no limit. The default is 0. Note that some servers
may place limits of their own on searches.
- custom-search-filter
- This one is for advanced users only! If you define this, then the
search-type
and
search-rule
defined are both ignored.
However, the feature
disable-ad-hoc-space-substitution
is still in effect.
That is, the space substitution will take place even in a custom filter unless
you disable it.

Another option that sometimes causes trouble is the
search-base option.
This variable may be set to the string representation of an LDAP search
filter (see RFC1960). In the places where you want the address string to be
substituted in, put a '%s' in this filter string. Here are some examples:
A "Search-Type" of "name" with "Search-Rule" of "begins-with"
is equivalent to the "custom-search-filter"
(cn=%s*)
When you try to match against the string "string" the program replaces
the "%s" with "string" (without the quotes). You may have multiple "%s"'s and
they will all be replaced with the string. There is a limit of 10 "%s"'s.
A "Search-Type" of "name-or-email" with "Search-Rule"
of "contains" is equivalent to
(|(cn=*%s*)(mail=*%s*))
If your server uses a different attribute name than
Alpine uses by default,
(for example, it uses "rfc822mail" instead of "mail"),
then you may be able to use one or more of the four attribute configuration
options instead of defining a custom filter:
Color Configuration
If the terminal or terminal emulator you are using is capable of using
color (see color-style option),
or if you are using PC-Alpine, then it is possible to
set up Alpine so that various parts of the display will be
shown in colors you configure.
This is done using the Setup Color screen.
The Setup Color screen is divided into five broad sections: Options,
General Colors, Index Colors, Header Colors, and Keyword Colors.
In addition to these five categories you may also color lines in the
MESSAGE INDEX screen by configuring the
Index Line Color.
Each color is defined as a foreground color (the color of the actual text)
and a background color (the color of the area behind the text).
Color Options
- current-indexline-style
-
This option affects the colors used to display the current line in the
MESSAGE INDEX screen.
If you do not have
Index Line Colors
defined, then this option will have no effect in the index.
Those Rules may be defined by going to the Setup/Rules/Indexcolor screen.
If the option
enable-incoming-folders-checking
is turned on and the
Incoming Unseen Color
is set to something other than the default, then
this option also affects the color used to display the current folder
in the Incoming FOLDER LIST screen.
The available options include:
- flip-colors
- This is the default.
If an index line is colored because it matches one of your
Index Color Rules, then its colors will be reversed when it is the currently
highlighted line.
For example, if the line is normally red text on a blue background, then
when it is the current line it will be drawn as blue text on a red background.
The rest of the option values all revert to this flip-colors behavior if
there is no Reverse Color defined.
- reverse
- With this option the Reverse color is always used to highlight the
current line.
- reverse-fg
- The foreground part of the Reverse Color is used to highlight
the current line.
If this would cause the text to be unreadable (because the foreground and
background colors are the same) or if it would cause no change in the
color of the index line, then the colors are flipped instead.
Some people think this works particularly well if you use different
background colors to emphasize "interesting" lines,
but always with the same Normal foreground color,
and you use a different foreground color for the Reverse Color.
- reverse-fg-no-ambiguity
- With the "reverse-fg" rule above, it is possible that
the resulting color will be exactly the same as the regular Reverse
Color.
That can lead to some possible confusion because an
"interesting"
line which is the current line will be displayed exactly the same as a
non-interesting line which is current.
You can't tell whether the line is just a regular current line or if it is
an "interesting" current line by looking at the color.
Setting the option to this value removes that ambiguity.
It is the same as the "reverse-fg" setting unless the resulting
interesting current line would look just like a non-interesting current line.
In that case, the interesting line's colors are simply flipped (like in the
default behavior).
As an alternative way to preserve the line's interestingness in this case,
you may find that using both a different foreground and a different
background color for the interesting line will help.
- reverse-bg
- The background part of the Reverse Color is used to highlight
the current line.
If this would cause the text to be unreadable (because the foreground and
background colors are the same) or if it would cause no change in the
color of the index line, then the colors are flipped instead.
Some people think this works particularly well if you use different
foreground colors to emphasize "interesting" lines,
but always with the same Normal background color,
and you use a different background color for the Reverse Color.
- reverse-bg-no-ambiguity
- As with the "reverse-fg" case, the "reverse-bg"
rule may also result in a color which is exactly the same as the regular
Reverse Color.
Setting the option to this value removes that ambiguity.
It is the same as the "reverse-bg" setting unless the resulting
current line has the same color as the Reverse Color.
In that case, the interesting line's colors are simply flipped (like in the
default behavior).
- titlebar-color-style
-
This option affects the colors used to display the titlebar (the top
line on the screen) when viewing a message.
The available options include:
- default
- The color of the titlebar will be the color you set for the
Title Color.
The Title Color may be set by using the
- indexline
- The color of the titlebar will be the same as the color of the
index line corresponding to the message being viewed.
The rules which determine what color the index line will be may be set
up by going to the Setup/Rules/Indexcolor screen.
If the index line for a message is not colored explicitly by the
Indexcolor rules, then the titlebar will be colored the same as for
the "default" option above (which is not the same color that
the index line itself will have).
- reverse-indexline
- This is similar to the "indexline" option except the
foreground and background colors from the corresponding index line will
be reversed.
For example, if the index line color is red letters on a white background,
then the titlebar will be white letters on a red background.
If the index line for a message is not colored explicitly by the
Indexcolor rules, then the titlebar will be colored the same as for
the "default" option above (which is not the same color that
the index line itself will have).
General Colors
- Normal Color
- This is the color which most of the screen is painted in.
By default this color is black characters on a white background.
- Reverse Color
- The color Alpine uses for reverse video characters.
Actually, the name is misleading. This used to be reverse video and so
the name remains. It is still used to highlight certain parts of the
screen but the color may be set to whatever you'd like.
- Title Color
- The color Alpine uses for the titlebar (the top line on the
screen).
By default, the Title Color is black characters on a yellow background.
The actual titlebar color may be different from the Title Color if
the option
titlebar-color-style
is set to some value other than the default.
It may also be different if the current folder is closed and the
Title Closed Color
is set to something different from the Title Color.
- Title-closed Color
- The color Alpine uses for the titlebar (the top line on the
screen) when the current folder is closed.
By default, the Title Color Closed Color is white characters on a red background.
- Status Color
- The color Alpine uses for messages written to the status
message line near the bottom of the screen.
By default, the Status Color is the same as the Reverse Color.
- KeyLabel Color
- The color Alpine uses for the labels of the commands in the
two-line menu at the bottom of the screen.
The label is the long name, for example, "PrevMsg".
By default, the KeyLabel Color is the same as the Normal Color.
WARNING: Some terminal emulators have the property that the screen will scroll
down one line whenever a character is written to the character cell in the
lower right corner of the screen.
Alpine can usually avoid writing a character in that corner of the screen.
However, if you have defined a KeyLabel Color then Alpine does have to write
a character in that cell in order to color the cell correctly.
If you find that your display sometimes scrolls up a line this could be
the problem.
The most obvious symptom is probably that the titlebar at the top of the
screen scrolls off the screen.
Try setting KeyLabel Color to Default to see if that fixes the problem.
- KeyName Color
- The color Alpine uses for the names of the commands in the
two-line menu at the bottom of the screen.
The KeyName is the shorter name in the menu. For example, the "W"
before the "WhereIs".
By default, the KeyName Color is the same as the Normal Color.
- Selectable-item Color
- The color Alpine uses for displaying selectable items, such
as URLs.
By default, the Selectable-item Color is the same as the Normal Color, except
it is also Bold.
- Meta-message Color
- The color Alpine uses in the MESSAGE TEXT screen for messages to you
that aren't part of the message itself.
By default, the Meta-Message Color is black characters on a yellow background.
- Quote Colors
- The colors Alpine uses for coloring quoted text in the
MESSAGE TEXT screen.
If a line begins with a > character (or space followed by >) it
is considered a quote. That line will be given the Quote1 Color (first
level quote). If there is a second level of quoting then the Quote2 Color
will be used. Alpine considers there to be a second level of quoting if
that first > is followed by another > (or space followed by >).
If there are characters other than whitespace and > signs, then it isn't
considered another level of quoting. Similarly, if there is a third level
of quoting the Quote3 Color will be used. If there are more levels after
that the Quote Colors are reused. If you define all three colors then it
would repeat like Color1, Color2, Color3, Color1, Color2, Color3, ...
If you only define the first two it would be Color1, Color2,
Color1, Color2, ...
If you define only the Quote1 Color, then the entire quote would be
that color regardless of the quoting levels.

- Incoming Unseen Color
- If the option
enable-incoming-folders-checking
is turned on it is possible to highlight the folders that contain
unseen messages by coloring them with this color.
By default, this is the same as the Normal Color and no highlighting is done.
Usually the "current" folder (the folder the cursor is on)
is highlighted using reverse video.
If the current folder is colored because it contains unseen messages then
the color used to show that it is also the current folder is controlled
by the current-indexline-style
feature at the top of the SETUP COLOR screen.
- Signature Color
- The color Alpine uses for coloring the signature in the MESSAGE TEXT
screen. According to USENET conventions, the signature is defined as the
paragraph following the "sigdashes", that is, the special line
consisting of the three characters
"-- " (i.e., dash, dash, and space). Alpine allows for one
empty line right after the sigdashes to be considered as part of the
signature.
By default, the Signature Color is blue characters on a white background.
- Prompt Color
- The color Alpine uses for confirmation prompts and questions
which appear in the status message line near the bottom of the screen.
By default, the Prompt Color is the same as the Reverse Color.
Index Colors
You may add color to the single character symbols which give the status
of each message in the MESSAGE INDEX.
By default the characters "+", "*", "D",
"A", and "N" show up near the left hand side of the
screen, depending on whether the message is addressed to you, and whether
the message is marked Important, is Deleted, is Answered, or is New.
You may set the color of those symbols.
By default, all of these symbols are drawn with the same color as the rest
of the index line they are a part of.
Besides coloring the message status symbols, you may also color the
entire index line.
This is done by using the
Index Line Color configuration screen.
It is also possible to color
(keywords
in the index using the
Setup/Kolor screen (Keyword Colors);
the ARROW cursor;
the Subject using
Index Subject Color;
the From using
Index From Color;
and the
Index Opening text.
- Index-to-me Symbol Color
- The color used for drawing the "+" symbol which signifies a
message is addressed directly to you.
- Index-important Symbol Color
- The color used for drawing the "*" symbol which signifies a
message has been flagged Important.
- Index-deleted Symbol Color
- The color used for drawing the "D" symbol which signifies a
message has been marked Deleted.
- Index-answered Symbol Color
- The color used for drawing the "A" symbol which signifies a
message has been answered.
- Index-new Symbol Color
- The color used for drawing the "N" symbol which signifies a
message is New.
- Index-recent Symbol Color
- The color used for drawing the "R" symbol which signifies a
message is Recent (only visible if the "IMAPSTATUS" or "SHORTIMAPSTATUS" token is
part of the
index-format option).
- Index-unseen Symbol Color
- The color used for drawing the "U" symbol which signifies a
message is Unseen (only visible if the "IMAPSTATUS" or "SHORTIMAPSTATUS" token is
part of the
Index-Format option).
- Index-priority Symbol Colors
- The colors used for drawing the tokens "PRIORITY",
"PRIORITYALPHA", and "PRIORITY!" when these are
configured as part of the
Index-Format option.
You may set the color used to draw these tokens by use of the colors
Index High Priority Symbol Color and Index Low Priority Symbol Color.
This coloring takes place for all but the current index line, and the Priority
Color appears to be in front of any color from an Index Color Rule.
If the priority has a value of 1 or 2 the High Priority color will be
used,
and if the value is 4 or 5 the Low Priority color will be used.
If you don't set these colors the index line will be colored in the same color as
the bulk of the index line.
- Index-arrow Symbol Color
- The color used for drawing the "ARROW" token when it is
configured as part of the
Index-Format option.
- Index-subject Symbol Color
- You may set the color used to draw the Subject part of the index line.
This coloring takes place for all but the current index line, and the Subject
Color appears to be in front of any color from an Index Color Rule.
If you don't set this color it will be colored in the same color as
the bulk of the index line.
- Index-from Symbol Color
- You may set the color used to draw the From part of the index line.
This coloring takes place for all but the current index line, and the From
Color appears to be in front of any color from an Index Color Rule.
If you don't set this color it will be colored in the same color as
the bulk of the index line.
- Index-opening Symbol Color
- It is possible to configure the
Index-Format option
so that it includes the subject followed by the "opening" text of the
message if there is enough space.
This is done by using one of the tokens SUBJECTTEXT, SUBJKEYTEXT, or
SUBJKEYINITTEXT.
The color used for drawing this opening text is given by this option.
The coloring happens for all but the current index line, and this opening
color appears to be in front of any color from an Index Color Rule.
By default the Index Opening Color is gray characters on a white background.
The default colors for these symbols are:
| Index-to-me | black on cyan |
| Index-important | white on bright red |
| Index-deleted | same as Normal Color |
| Index-answered | bright red on yellow |
| Index-new | white on magenta |
| Index-recent | same as Normal Color |
| Index-unseen | same as Normal Color |
Header Colors
You may add color to the header fields in the MESSAGE TEXT screen.
The
- Header-general Color
- may be used to color all of the headers of
the message.
It is also possible to set the colors for specific header fields,
for example for the Subject or From fields, using the
viewer-hdr-colors
option.
For Header Colors,
there is an additional line on the configuration
screen labeled "Pattern to match".
If you leave that blank, then the whole field for that header will
always be colored.
However, if you give a pattern to match, the coloring will only take place
if there is a match for that pattern in the value of the field.
For example, if you are working on a color for the Subject header and
you fill in a pattern of "important", then only Subjects which
contain the word "important" will be colored.
For address fields like From or To, a pattern match will cause only the
addresses which match the pattern to be colored.
If the pattern you enter is a comma-separated list of patterns, then coloring
happens if any of those patterns matches.
Keyword Colors
Sets the colors Alpine uses for Keyword fields in the MESSAGE INDEX screen.
Keywords may be displayed as part of the Subject of a message by using
the "SUBJKEY" or "SUBJKEYINIT" tokens in the
Index-Format option.
Keywords may also be displayed in a column of their own in the MESSAGE INDEX
screen by using the "KEY" or "KEYINIT" tokens.
For example, you might have set up a Keyword
"Work" using the
Keywords
option in the Setup/Config screen.
You could cause that Keyword to show up as a special color
by setting up the Keyword Color using this option, and then including it
in the MESSAGE INDEX screen using one of the tokens listed above in the
Index-Format.
Index Line Colors
You may color whole index lines by using roles.
This isn't configured in the Setup Colors screen, but is configured in
the Setup Rules IndexColor screen.
Index Line Color Configuration
Index Line Color causes lines in the MESSAGE INDEX screen to be colored.
This action is only available if your terminal is capable of displaying
color and color display has been enabled with the
Color-Style option.
(In PC-Alpine, color is always enabled so there is no option to turn on.)
Each rule has a "Pattern",
which is used to decide which of the rules is used; and the color which
is used if the Pattern matches a particular message.
Rule Patterns
In order to determine whether or not a message matches a rule the message is
compared with the rule's Pattern.
These Patterns are the same for use with Roles, Filtering, Index Coloring,
Scoring, Other Rules, and Search Rules, so are described in only one place,
"here".
Index Line Color
This is the color that index lines are colored when there is a matching
Pattern.
This colors the whole index line, except possibly the status letters
which may be colored separately using
the Setup Kolor screen.
Role Configuration
You may play different roles depending on who you are replying to.
For example, if you are replying to a message addressed to help-desk you
may be acting as a Help Desk Worker.
That role may require that you use a different return address and/or
a different signature.
Roles are optional.
If you set up roles they work like this: Each role has a set of
"Uses", which indicate whether or not a role is eligible to be
considered for a particular use; a "Pattern",
which is used to decide which of the eligible roles is used; and a set
of "Actions", which are taken when that role is used.
When you reply to a message, the message you are replying to is compared
with the Patterns of the roles marked as eligible for use when replying.
The comparisons start with the first eligible role and keep going until there
is a match.
If a match is found, the matching role's Actions are taken.
It is also possible to set a default role and to change that role during
your Alpine session.
When you start Alpine no default role will be set.
You may set or change the current default role by using the "D"
command in the role selection screen.
You'll see that screen while composing a message and being asked to select
a role.
An easy way to get to that screen is to use the Role Command to
compose a message.
You may find a default role useful if you normally perform the duties of one
of your roles for a while, then you switch to another role and stay in the
new role for another period of time.
It may be easier than using the Role Command to select the role each time you
compose a message.
Role Uses
There are three types of use to be configured;
one for Replying, one for Forwarding, and one for Composing.
These indicate whether or not you want a role to be considered when you
type the Reply, Forward, or Compose commands.
(The Role command is an alternate form of the Compose command, and it is
not affected by these settings.)
Each of these Use types has three possible values.
The value "Never"
means that the role will never be considered as a candidate for use with
the corresponding command.
For example, if you set a role's Reply Use to Never, then when you Reply to
a message, the role won't even be considered.
(That isn't quite true. If the message you are replying to matches some other
role which requires confirmation,
then there will be a ^T command available which allows you to select a role
from all of your roles, not just the reply-eligible roles.)
The options "With confirmation" and "Without confirmation"
both mean that you do want to consider this role when using the corresponding
command.
For either of these settings the role's Pattern will
be checked to see if it matches the message.
For Reply Use, the message used to compare the Patterns with is the message
being replied to.
For Forward Use, the message used to compare the Pattern with is the message
being forwarded.
For Compose Use, there is no message, so the parts of the Pattern which depend
on a message (everything other than Current Folder Type) are ignored.
In all cases, the Current Folder is checked if defined.
If there is a match then this role will either be used without confirmation
or will be the default when confirmation is asked for, depending on
which of the two options is selected.
If confirmation is requested, you will have a chance to
choose No Role instead of the offered role, or to
change the role to any one of your other roles (with the ^T command).
Role Patterns
In order to determine whether or not a message matches a role the message is
compared with the Role Pattern.
These Patterns are the same for use with Roles, Filtering, Index Coloring,
Scoring, Other Rules, and Search Rules, so are described in only one place,
"here".
Since header patterns, AllText patterns, and BodyText patterns which are unset are ignored,
a role which has all header patterns unset, the AllText pattern unset,
the BodyText pattern unset,
the Score Interval unset, and the Current Folder Type set to
"Any" may be used as a default role.
It should be put last in the list of roles since the matching
starts at the beginning and proceeds until one of the roles is a match.
If no roles at all match, then Alpine will
use its regular methods of defining the role.
If you wanted to, you could define a different "default" role
for Replying, Forwarding, and Composing by setting the
"Use" fields appropriately.
Role Actions
Once a role match is found, the role's Actions are taken.
For each role there are several possible actions that may be defined.
They are actions to set the From address, the Reply-To address,
the Fcc, the Signature file, and the Template file.
Initialize Settings Using Role
This is a power user feature.
You will usually want to leave this field empty.
The value of this field is the nickname of another one of your roles.
The Action values from that other role
are used as the initial values of the Action items for this role.
If you put something in any of the action fields for this role, that will
override whatever was in the corresponding field of the initializer role.
You might use this field if the "Action" part of one of your roles
is something you want to use in more than one role.
Instead of filling in those action values again for each role, you
may give the nickname of the role where the values are filled in.
It's just a shortcut way to define Role Actions.
Here's an example to help explain how this works.
Suppose you have a role with nickname "role1" and role1 has
(among other things)
Set Reply-To = The Pres<EMAIL_ADDRESS>set.
If in "role2" you set "Initialize settings using role" to
"role1", then role2 will inherit the Set Reply-To value
from role1 by default (and any of the other inheritable action values
that are set).
So if role2 had
Set Reply-To = <No Value Set>
defined, the Reply-To used with role2 would be "The Pres<EMAIL_ADDRESS>However, if role2 had
Set Reply-To = VP<EMAIL_ADDRESS>defined, then the Reply-To used with role2 would be "VP<EMAIL_ADDRESS>instead.
If you wish,
you may choose a nickname from your list of roles by using the
"T" command.
If the role you are using to initialize also has a role it initializes from,
then that initialization happens first.
That is, inheritance works as expected with the grandparent and
great-grandparent (and so on) roles having the expected effect.
Set From
This field consists of a single address which will be used as the From
address on the message you are sending.
This should be a fully-qualified address like
Full Name <user@domain>
or just
user@domain
If this is left blank, then the normal From address will be used.
Set Reply-To
The Reply-To address is the address used on the Reply-To line of the message
you are sending.
You don't need a Reply-To address unless it is different from the From address.
This should be a fully-qualified address like
Full Name <user@domain>
or just
user@domain
If this is left blank, then there won't be a Reply-To address unless
you have configured one specially with the
customized-hdrs
configuration option.
Set Other-Hdrs
This field gives you a way to set values for headers besides
"From" and "Reply-To".
If you want to set either of those, use the specific
"Set From" and "Set Reply-To" settings.
This field is similar to the
customized-hdrs option.
Each header you specify here must include the header tag
("To:", "Approved:", etc.)
and may optionally include a value for that header.
In order to see these headers when you compose using this role you
must use the rich header command.
Here's an example which shows how you might set the To address.
Set Other Hdrs = To: Full Name <user@domain>
Headers set in this way are different from headers set with the
customized-hdrs option in that the value you give for a header here
will replace any value that already exists.
For example, if you are Replying to a message there will already be at
least one address in the To header (the address you are Replying to).
However, if you Reply using a role which sets the To header, that role's
To header value will be used instead.
The customized-hdrs headers are defaults.
Limitation: Because commas are used to separate the list of
Other Headers, it is not possible to have the value of a
header contain a comma;
nor is there currently an "escape" mechanism provided
to make this work.
Set Fcc
This field consists of a single folder name which will be used in
the Fcc field of the message you are sending.
You may put anything here that you would normally type into the Fcc
field from the composer.
In addition, an fcc of "" (two double quotation marks) means
no Fcc.
A blank field here means that Alpine will use its normal rules for deciding
the default value of the Fcc field.
For many roles, perhaps most, it may make more sense for you to use the
other Alpine facilities for setting the Fcc.
In particular, if you want the Fcc to depend on who you are sending the
message to then the fcc-name-rule
is probably more useful.
In that case, you would want to leave the Fcc field here blank.
However, if you have a role that depends on who the message you are replying
to was From, or what address that message was sent to;
then it might make sense to set the Fcc for that role here.
Set LiteralSig
This field contains the actual text for your signature, as opposed to
the name of a file containing your signature.
If this is defined it takes precedence over any value set in the
Set Signature field.
This is simply a different way to store the signature.
The signature is stored inside your Alpine configuration file instead of in
a separate signature file.
Tokens work the same way they do with Set Signature.
The two character sequence \n (backslash followed by
the character n) will be used to signify a line-break in your signature.
You don't have to enter the \n, but it will be visible in the
CHANGE THIS ROLE RULE window after you are done editing the signature.
Set Signature
The Signature is the name of a file to be used as the signature file when
this role is being used.
If the filename is followed by a vertical bar (|) then instead
of reading the contents of the file the file is assumed to be a
program which will produce the text to be used on its standard output.
The program can't have any arguments and doesn't receive any input from Alpine,
but the rest of the processing works as if the contents came from a file.
Signature files may be stored remotely on an IMAP server.
In order to do that you just give the file a remote name.
This works just like the regular
signature-file
option which is configured from the Setup/Configuration screen.
A remote signature file name might look like:
{myimaphost.myschool.k12.wa.us}mail/sig3
or, if you have an SSL-capable version of Alpine, you might try
{myimaphost.myschool.k12.wa.us/user=loginname/ssl}mail/sig3
Once you have named the remote signature file you create its
contents by using the "F" "editFile" command when the
cursor is on the "Set Signature"
line of the role editor.
Besides containing regular text, a signature file may also
contain (or a signature program may produce) tokens which are replaced with text
which depends on the message you are replying to or forwarding.
The tokens all look like _word_ (a word surrounded by underscores).
For example, if the token
_DATE_
is included in the text of the signature file, then when you reply to
or forward a message, the token will be replaced with the actual date
the message you are replying to or forwarding was sent.
If you use a role which has a signature file for a plain composition
(that is, not a reply or forward) then there is no original message, so
any tokens which depend on the message will be replaced with nothing.
So if you want a signature file to be useful for new compositions it
shouldn't include any of the tokens which depend on the message being
replied to or forwarded.
The list of available tokens is
here.
Actually, for the adventurous, there is a way to conditionally include text based
on whether or not a token would result in specific replacement text.
For example, you could include some text based on whether or not
the _NEWS_ token would result in any newsgroups if it was used.
It's explained in detail
here.
In the very unlikely event that you want to include a literal token in
a signature file, you must precede it with a backslash character.
For example, to include the literal text _DATE_ you must actually use
\_DATE_.
It is not possible to have a literal backslash followed by an expanded token.
A blank field here means that Alpine will use its normal rules for deciding
which file (if any) to use for the signature file.
Set Template
A Template is the name of a file to be included in the message when this
role is being used.
The template file is a file which is included at the top of the message you
are composing.
If the filename is followed by a vertical bar (|) then instead
of reading the contents of the file the file is assumed to be a
program which will produce the text to be used on its standard output.
The program can't have any arguments and doesn't receive any input from Alpine,
but the rest of the processing works as if the contents came from a file.
Template files may be stored remotely on an IMAP server.
In order to do that you just give the file a remote name.
This works just like the regular
signature-file
option which is configured from the Setup/Configuration screen.
A remote template file name might look like:
{myimaphost.myschool.k12.wa.us}mail/templ3
or, if you have an SSL-capable version of Alpine, you might try
{myimaphost.myschool.k12.wa.us/user=loginname/ssl}mail/templ3
Once you have named the remote template file you create its
contents by using the "F" "editFile" command when the
cursor is on the "Set Template"
line of the role editor.
Besides containing regular text, a template file may also
contain (or a template file program may produce) tokens which are replaced with text
which depends on the message you are replying to or forwarding.
The tokens all look like _word_ (a word surrounded by underscores).
For example, if the token
_DATE_
is included in the text of the template file, then when you reply to
or forward a message, the token will be replaced with the actual date
the message you are replying to or forwarding was sent.
If you use a role which has a template file for a plain composition
(that is, not a reply or forward) then there is no original message, so
any tokens which depend on the message will be replaced with nothing.
So if you want a template file to be useful for new compositions it
shouldn't include any of the tokens which depend on the message being
replied to or forwarded.
The list of available tokens is
here.
Actually, for the adventurous, there is a way to conditionally include text based
on whether or not a token would result in specific replacement text.
For example, you could include some text based on whether or not
the _NEWS_ token would result in any newsgroups if it was used.
It's explained in detail
here.
In the very unlikely event that you want to include a literal token in
a template file, you must precede it with a backslash character.
For example, to include the literal text _DATE_ you must actually use
\_DATE_.
It is not possible to have a literal backslash followed by an expanded token.
A blank field here means that Alpine will not use a template file when
this role is being used.
Use SMTP Server
If this field has a value, then it will be used as the SMTP server
to send mail when this role is being used (unless the SMTP server variable
is set in the system-wide fixed configuration file).
It has the same semantics as the
smtp-server
variable in the Setup/Config screen.
When you postpone the composition this SMTP server list will be saved
with the postponed composition and it cannot be changed later.
Because of that, you may want to make this a list of SMTP servers
with the preferred server at the front of the list and alternate servers
later in the list.
If any of the actions are left unset, then the action depends on what
is present in the "Initialize settings using role" field.
If you've listed the nickname of another one of your roles there, then the
corresponding action from that role will be used here.
If that action is also blank, or if there is no nickname specified,
then Alpine will do whatever it normally does to set these actions.
This depends on other configuration options and features you've set.
Filtering Configuration
The software which actually delivers mail (the stuff that happens
before Alpine is involved) for you is in a better position to do mail filtering
than Alpine itself.
If possible, you may want to look into using that sort of mail filtering to
deliver mail to different folders, delete it, or forward it.
However, if you'd like Alpine to help with this, Alpine's filtering is for you.
Filtering is a way to automatically move certain messages from one folder
to another or to delete messages.
It can also be used to set message status bits (Important, Deleted, New,
Answered).
Alpine doesn't have the ability to forward mail to another address.
Each filtering rule has a "Pattern" and a "Filter Action".
When a folder is opened, when new mail arrives in an open folder, or
when mail is Expunged from a folder; each
message is compared with the Patterns of your filtering rules.
The comparisons start with the first rule and keep going until there
is a match.
If a match is found, the message may be deleted or moved, depending on
the setting of the Filter Action.
If the message is not deleted, it may have its status altered.
For efficiency, each message is usually only checked once.
When new mail arrives, the new messages are checked but not the old.
There are some exceptions to this rule.
The expunge command will cause all messages to be rechecked, as will
editing of the filtering rules.
NOTE:
When setting up a Pattern used to delete messages,
it is recommended that you test the Pattern first with a "Move"
folder specified in
case unintended matches occur. Messages that are deleted will be removed
from the folder and unrecoverable from within Alpine after the
next Expunge command or once the folder being filtered has been closed.
Filter Patterns
In order to determine whether or not a message matches a filter the message is
compared with the Filter's Pattern.
These Patterns are the same for use with Roles, Filtering, Index Coloring,
Scoring, Other Rules, and Search Rules, so are described in only one place,
"here".
Since filtering is a potentially destructive action, if you have a filtering
Pattern with nothing other than Current Folder Type set, that filtering
rule is ignored.
Filter Actions
Once a filter match is found for a particular message, there are some actions
which may be taken.
First, the message may have its status changed.
This is the same message status that you can manipulate manually using the
Flag Command.
There are four elements of message status that you can control.
You can set or clear the Important status, the New status, the Deleted
status, and the Answered status.
Of course, if the filter is going to delete the message,
then there is no point in setting message status.
You may also set or clear user-defined
keywords for a message.
Second, the filter may delete or move the message.
Deleting the message marks it Deleted and removes it from view.
It is effectively gone forever (though it technically is still there until
the next expunge command, which may happen implicitly).
Moving the message moves it from the open folder into the folder
listed on the "Folder List" line of the filter configuration.
If you list more than one folder name (separated by commas) then the message
will be copied to each of those folders.
In any case, if "Delete" or "Move" is set then the
message is removed from the current folder.
If you just want to set the messages status without deleting it from
the folder, then set the filter action to
"Just Set Message Status".
(There is no way to do a Copy instead of a Move, due to the difficulties
involved in keeping track of whether or not a message has
already been copied by a previous Alpine session.)
Move-only-if-not-deleted option
If you have specified a Move to Folder to filter messages into, then this
option has an effect.
If this option is set then messages will only be moved into the specified folder
if they aren't already marked deleted.
This might be useful if you have more than one Alpine session running
simultaneously and you don't want messages to be filtered into a folder
more than once.
This method is not foolproof.
There may be cases where a message gets marked deleted and so it is never
filtered into the folder.
For example, if you deleted it in another Alpine or
another mail program that didn't know about the filtering rule.
This option has no effect if the Filter Action is not set to Move.
Dont-quit-even-if-rule-matches option
If this option is set then this is a non-terminating rule.
Usually, for each message, Alpine searches through the filter rules until
a match is found and then it performs the action associated with that rule.
Rules following the match are not considered.
If this option is set then the search for matches will continue at the next
rule.
If a non-terminating rule matches then the actions associated with
that rule, except for any implied deletion of the message, are performed
before the match for the next rule is checked.
For example, if the non-terminating rule sets the Important status, then that
status will be set when the next rule is considered.
However, if the non-terminating rule Moves the message, the message will
actually be copied instead of copied and deleted so that it is still there
for the next rule.
A moved message is deleted after all the relevant rules have been checked.
The name of the "Move" action is confusing in this case because
a single message can be moved to more than one folder.
It turns the Move into a Copy instead, but it is still followed by a deletion
at the end.
This option may be useful if you want to have a single message filtered to
two different folders because it matches two different Patterns.
For example, suppose you normally filter messages to a particular mailing
list into one folder, and messages addressed directly to you into a second
folder.
If a message is sent to both you and the list (and you can tell that by
looking at the headers of the message) this option may give you a convenient
way to capture a copy to each folder.
(It may also cause you to capture two copies to each folder,
depending on whether your mail system delivers one or two copies of the
message to you and on how the list works.)
Scoring Configuration
Most people will not use scores at all, but if you do use them, here's how
they work in Alpine.
Using this screen, you may define Scoring rules.
The score for a message is calculated by looking at every Score rule defined
and adding up the Score Values for the ones which match the message.
If there are no matches for a message, it has a score of zero.
Message scores may be used a couple of ways in Alpine.
Sorting by Score
One of the methods you may use to sort message indexes is to sort by
score.
The scores of all the messages in a folder will be calculated and then
the index will be ordered by placing the messages in order of ascending or
descending score.
Scores for use in Patterns
The Patterns used for Roles, Index Line Coloring, and Filtering have a
category labeled "Score Interval".
When a message is being compared with a Pattern to check for a match, if
the Score Interval is set only messages which have a score somewhere in
the interval are a match.
Scoring Rule Patterns
In order to determine whether or not a message matches a scoring rule
the message is compared with the rule's Pattern.
These Patterns are the same for use with Roles, Filtering, Index Coloring,
Scoring, Other Rules, and Search Rules, so are described in only one place,
"here".
Actually, Scoring rule Patterns are slightly different from the other types of
Patterns because Scoring rule Patterns don't contain a Score Interval.
In other words, when calculating the score for a message, which is done
by looking at the Scoring rule Patterns, scores aren't used.
Score Value
This is the value that will be added to the score for a message if the
rule's Pattern is a match.
Each individual Score Value is an integer between -100 and 100, and the
values from matching rules are added together to get a message's score.
There is also a way to extract the value from a particular header of each
message. See the help text for Score Value for further information.
Other Rules Configuration
Using this screen, you may define configuration Rules which don't fit
nicely into the other Rules categories.
Other Rule Patterns
Other Rules are a little different from the rest of the Rules because
they depend only on the current folder, and not on a particular message.
In order to determine whether or not a rule's actions should be applied
the current folder is compared with the rule's Pattern, which consists
of only the Current Folder Type.
Current Folder Type works the same for Other Rules as it does for Roles,
Filtering, Index Coloring, and Scoring.
Keep in mind that the only part of the Pattern which applies to Other
Rules is the Current Folder Type when looking at the description of
Patterns given
"here".
Other Rule Actions
Once a pattern match is found, the rule's Actions are taken.
Neither of the following two rule's depends on a message for its match.
That means that all the parts of the Pattern which depend on matching an
attribute of a message are ignored.
So the only part of the Pattern that matters for these Actions is
the Current Folder Type.
Set Sort Order
When you enter a new folder, these rules will be checked to see if you
have set a sort order which is different from your default sort order.
The default is set in the Setup/Config screen with
the Sort-Key option.
If the Sort Order action is set, then the folder will be displayed sorted in
that sort order instead of in the default order.
A possible point of confusion arises when you change the configuration
of the Sort Order for the currently open folder.
The folder will normally be re-sorted when you go back to viewing the
index.
However, if you have manually sorted the folder with the
Sort command, it will not be re-sorted.
Set Index Format
When you enter a new folder, these rules will be checked to see if you
have set an Index Format which is different from your default Index Format,
which is set with the
Index-Format option.
If so, the index will be displayed with this format instead of the default.
Set Startup Rule
When you enter a new folder, these rules will be checked to see if you
have set a startup rule which is different from the default startup rule.
The default for incoming folders is set in the Setup/Config screen with
the "incoming-startup-rule" option.
The default for folders other than INBOX that are not part of your
incoming collection
(see enable-incoming-folders feature)
is to start with the last message in the folder.
If the Startup Rule is set to something other than "default",
then the rule will determine which message will be the current message when
the folder is first opened.
The various startup rule possibilities work the same here as they do in
the incoming collection, except that the folder can be any specific
folder or any folder type.
Search Rules Configuration
One of the commands that becomes available when that feature is turned on
is the "; Select" command, which is used in the MESSAGE INDEX
screen to select a set of messages.
One way of selecting messages is to use a Rule.
All of the messages which match (or don't match if you wish)
a Rule's Pattern will be selected.
Any of your Rules may be used for this purpose.
You might already have Rules set up for filtering, index line color, scores, or roles;
and you may use any of those Rules with the Select command.
However, you might find it more convenient to set up a separate set of Rules
just for this purpose without having to worry about what other effects
they may cause.
That is the purpose of these Select Rules.
Rule Patterns
In order to determine whether or not a message is selected by a rule the
message is
compared with the rule's Pattern.
These Patterns are the same for use with Roles, Filtering, Index Coloring,
Scoring, Other Rules, and Search Rules, so are described in only one place,
"here".
There is no action associated with these Search Rules.
Only their Patterns are used.
Patterns
Patterns are used with Roles, Filtering, Index Coloring,
Scoring, Other Rules, and Search Rules.
Patterns are compared with a message to see if there is a match.
For Filtering, the messages being checked are all the messages in the
folder, one at a time.
For Index Line Coloring, each message that is visible on the screen is
checked for matches with the Index Coloring Patterns.
Roles are used with the Reply, Forward, and Compose commands.
For Reply, the message used to compare the Pattern with is the message
being replied to;
for Forward, the message used to compare the Pattern with is the message
being forwarded;
and for Compose, there is no message, so the parts of the Pattern which depend
on a message (everything other than Current Folder Type and the
Beginning of Month and Year)
are not used.
Only the Current Folder Type matters for Compose (plus the Beginning of
Month or Year, which you wouldn't usually use for a Role).
For Scoring, the message being scored is compared with all of the Score
Patterns, and the Score Values from the ones that match are added together to
get the message's score.
For Other Rules, there is no message. Only the Current Folder Type is checked
for Other Rules.
Each Pattern has several possible parts, all of which are optional.
In order for there to be a match, ALL of the
defined parts of the Pattern must match the message.
If a part is not defined it is considered a match.
For example, if the To pattern is not defined it will be
displayed as
To pattern = <No Value Set>
That is considered a match because it is not defined.
This means that the Pattern with nothing defined is a match if the
Current Folder Type matches, but there is an exception.
Because filtering is a potentially destructive action, filtering Patterns
with nothing other than Current Folder Type defined are ignored.
If you really want a filtering Pattern to match all messages (subject to
Current Folder Type) the best way to do it is to define a Score interval
which includes all possible scores.
This would be the score interval (-INF,INF).
This can be used even if you haven't defined any rules to Set Scores.
There are six predefined header patterns called the To, From, Sender, Cc, News,
and Subject patterns.
Besides those six predefined header patterns, you may add
additional header patterns with header fieldnames of your choosing.
You add an extra header pattern by placing the cursor on one of the
patterns while in the role editor and using the "eXtraHdr" command.
The Recip pattern is a header pattern which stands for Recipient (To OR Cc)
and the Partic pattern is a header pattern which stands for
Participant (From OR To OR Cc).
(Defining the Recip pattern does not have the same effect as defining both
the To and Cc patterns. Recip is To OR Cc, not To AND Cc.)
Similar to the header patterns are the AllText pattern and the BodyText pattern.
Instead of comparing this pattern's text against only the contents of