+=over 4
+
+=item C<$MessageBoxWidth>, C<$MessageBoxHeight>
+
+For message boxes, set the entry box width, height and what type of
+wrapping to use. These options can be overridden by users in their
+preferences.
+
+When the width is set to undef, no column count is specified and the
+message box will take up 100% of the available width. Combining this
+with HARD messagebox wrapping (below) is not recommended, as it will
+lead to inconsistent width in transactions between browsers.
+
+These settings only apply to the non-RichText message box. See below
+for Rich Text settings.
+
+=cut
+
+Set($MessageBoxWidth, undef);
+Set($MessageBoxHeight, 15);
+
+=item C<$MessageBoxWrap>
+
+Wrapping is disabled when using MessageBoxRichText because of a bad
+interaction between IE and wrapping with the Rich Text Editor.
+
+=cut
+
+Set($MessageBoxWrap, "SOFT");
+
+=item C<$MessageBoxRichText>
+
+Should "rich text" editing be enabled? This option lets your users
+send HTML email messages from the web interface.
+
+=cut
+
+Set($MessageBoxRichText, 1);
+
+=item C<$MessageBoxRichTextHeight>
+
+Height of rich text JavaScript enabled editing boxes (in pixels)
+
+=cut
+
+Set($MessageBoxRichTextHeight, 200);
+
+=item C<$MessageBoxIncludeSignature>
+
+Should your users' signatures (from their Preferences page) be
+included in Comments and Replies.
+
+=cut
+
+Set($MessageBoxIncludeSignature, 1);
+
+=item C<$MessageBoxIncludeSignatureOnComment>
+
+Should your users' signatures (from their Preferences page) be
+included in Comments. Setting this to false overrides
+C<$MessageBoxIncludeSignature>.
+
+=cut
+
+Set($MessageBoxIncludeSignatureOnComment, 1);
+
+=back
+
+
+=head2 Transaction display
+
+=over 4
+
+=item C<$OldestTransactionsFirst>
+
+By default, RT shows newest transactions at the bottom of the ticket
+history page, if you want see them at the top set this to 0. This
+option can be overridden by users in their preferences.
+
+=cut
+
+Set($OldestTransactionsFirst, 1);
+
+=item C<$DeferTransactionLoading>
+
+When set, defers loading ticket history until the user clicks a link.
+This should end up serving pages to users quicker, since generating
+all the HTML for transaction history can be slow for long tickets.
+
+=cut
+
+# Set($DeferTransactionLoading, 1);
+
+=item C<$ShowBccHeader>
+
+By default, RT hides from the web UI information about blind copies
+user sent on reply or comment.
+
+=cut
+
+Set($ShowBccHeader, 0);
+
+=item C<$TrustHTMLAttachments>
+
+If C<TrustHTMLAttachments> is not defined, we will display them as
+text. This prevents malicious HTML and JavaScript from being sent in a
+request (although there is probably more to it than that)
+
+=cut
+
+Set($TrustHTMLAttachments, undef);
+
+=item C<$AlwaysDownloadAttachments>
+
+Always download attachments, regardless of content type. If set, this
+overrides C<TrustHTMLAttachments>.
+
+=cut
+
+Set($AlwaysDownloadAttachments, undef);
+
+=item C<$AttachmentUnits>
+
+Controls the units (kilobytes or bytes) that attachment sizes use for
+display. The default is to display kilobytes if the attachment is
+larger than 1024 bytes, bytes otherwise. If you set
+C<$AttachmentUnits> to C<'k'> then attachment sizes will always be
+displayed in kilobytes. If set to C<'b'>, then sizes will be bytes.
+
+=cut
+
+Set($AttachmentUnits, undef);
+
+=item C<$PreferRichText>
+
+If C<$PreferRichText> is set to 1, RT will show HTML/Rich text messages
+in preference to their plain-text alternatives. RT "scrubs" the HTML to
+show only a minimal subset of HTML to avoid possible contamination by
+cross-site-scripting attacks.
+
+=cut
+
+Set($PreferRichText, undef);
+
+=item C<$MaxInlineBody>
+
+C<$MaxInlineBody> is the maximum attachment size that we want to see
+inline when viewing a transaction. RT will inline any text if the
+value is undefined or 0. This option can be overridden by users in
+their preferences.
+
+=cut
+
+Set($MaxInlineBody, 12000);
+
+=item C<$ShowTransactionImages>
+
+By default, RT shows images attached to incoming (and outgoing) ticket
+updates inline. Set this variable to 0 if you'd like to disable that
+behavior.
+
+=cut
+
+Set($ShowTransactionImages, 1);
+
+=item C<$PlainTextPre>
+
+Normally plaintext attachments are displayed as HTML with line breaks
+preserved. This causes space- and tab-based formatting not to be
+displayed correctly. By setting $PlainTextPre messages will be
+displayed using <pre>.
+
+=cut
+
+Set($PlainTextPre, 0);
+
+
+=item C<$PlainTextMono>
+
+Set C<$PlainTextMono> to 1 to use monospaced font and preserve
+formatting; unlike C<$PlainTextPre>, the text will wrap to fit width
+of the browser window; this option overrides C<$PlainTextPre>.
+
+=cut
+
+Set($PlainTextMono, 0);
+
+=item C<$SuppressInlineTextFiles>
+
+If C<$SuppressInlineTextFiles> is set to 1, then uploaded text files
+(text-type attachments with file names) are prevented from being
+displayed in-line when viewing a ticket's history.
+
+=cut
+
+Set($SuppressInlineTextFiles, undef);
+
+
+=item C<@Active_MakeClicky>
+
+MakeClicky detects various formats of data in headers and email
+messages, and extends them with supporting links. By default, RT
+provides two formats:
+
+* 'httpurl': detects http:// and https:// URLs and adds '[Open URL]'
+ link after the URL.
+
+* 'httpurl_overwrite': also detects URLs as 'httpurl' format, but
+ replaces the URL with a link.
+
+See F<share/html/Elements/MakeClicky> for documentation on how to add
+your own styles of link detection.
+
+=cut
+
+Set(@Active_MakeClicky, qw());
+
+=back
+
+
+
+=head1 Application logic
+
+=over 4
+
+=item C<$ParseNewMessageForTicketCcs>
+
+If C<$ParseNewMessageForTicketCcs> is set to 1, RT will attempt to
+divine Ticket 'Cc' watchers from the To and Cc lines of incoming
+messages. Be forewarned that if you have I<any> addresses which forward
+mail to RT automatically and you enable this option without modifying
+C<$RTAddressRegexp> below, you will get yourself into a heap of trouble.
+
+=cut
+
+Set($ParseNewMessageForTicketCcs, undef);
+
+=item C<$UseTransactionBatch>
+
+Set C<$UseTransactionBatch> to 1 to execute transactions in batches,
+such that a resolve and comment (for example) would happen
+simultaneously, instead of as two transactions, unaware of each
+others' existence.
+
+=cut
+
+Set($UseTransactionBatch, 1);
+
+=item C<$StrictLinkACL>
+
+When this feature is enabled a user needs I<ModifyTicket> rights on
+both tickets to link them together; otherwise, I<ModifyTicket> rights
+on either of them is sufficient.
+
+=cut
+
+Set($StrictLinkACL, 1);
+
+=item C<$RedistributeAutoGeneratedMessages>
+
+Should RT redistribute correspondence that it identifies as machine
+generated? A 1 will do so; setting this to 0 will cause no
+such messages to be redistributed. You can also use 'privileged' (the
+default), which will redistribute only to privileged users. This helps
+to protect against malformed bounces and loops caused by auto-created
+requestors with bogus addresses.
+
+=cut
+
+Set($RedistributeAutoGeneratedMessages, "privileged");
+
+=item C<$ApprovalRejectionNotes>
+
+Should rejection notes from approvals be sent to the requestors?
+
+=cut
+
+Set($ApprovalRejectionNotes, 1);
+
+=item C<$ForceApprovalsView>
+
+Should approval tickets only be viewed and modified through the standard
+approval interface? Changing this setting to 1 will redirect any attempt to
+use the normal ticket display and modify page for approval tickets.
+
+For example, with this option set to 1 and an approval ticket #123:
+
+ /Ticket/Display.html?id=123
+
+is redirected to
+
+ /Approval/Display.html?id=123
+
+=back
+
+=cut
+
+Set($ForceApprovalsView, 0);
+
+=head1 Extra security
+
+This is a list of extra security measures to enable that help keep your RT
+safe. If you don't know what these mean, you should almost certainly leave the
+defaults alone.
+
+=over 4
+
+=item C<$DisallowExecuteCode>
+
+If set to a true value, the C<ExecuteCode> right will be removed from
+all users, B<including> the superuser. This is intended for when RT is
+installed into a shared environment where even the superuser should not
+be allowed to run arbitrary Perl code on the server via scrips.
+
+=cut
+
+Set($DisallowExecuteCode, 0);
+
+=item C<$Framebusting>
+
+If set to a false value, framekiller javascript will be disabled and the
+X-Frame-Options: DENY header will be suppressed from all responses.
+This disables RT's clickjacking protection.
+
+=cut
+
+Set($Framebusting, 1);
+
+=item C<$RestrictReferrer>
+
+If set to a false value, the HTTP C<Referer> (sic) header will not be
+checked to ensure that requests come from RT's own domain. As RT allows
+for GET requests to alter state, disabling this opens RT up to
+cross-site request forgery (CSRF) attacks.
+
+=cut
+
+Set($RestrictReferrer, 1);
+
+=item C<$RestrictLoginReferrer>
+
+If set to a false value, RT will allow the user to log in from any link
+or request, merely by passing in C<user> and C<pass> parameters; setting
+it to a true value forces all logins to come from the login box, so the
+user is aware that they are being logged in. The default is off, for
+backwards compatability.
+
+=cut
+
+Set($RestrictLoginReferrer, 0);
+
+=item C<@ReferrerWhitelist>
+
+This is a list of hostname:port combinations that RT will treat as being
+part of RT's domain. This is particularly useful if you access RT as
+multiple hostnames or have an external auth system that needs to
+redirect back to RT once authentication is complete.
+
+ Set(@ReferrerWhitelist, qw(www.example.com:443 www3.example.com:80));
+
+If the "RT has detected a possible cross-site request forgery" error is triggered
+by a host:port sent by your browser that you believe should be valid, you can copy
+the host:port from the error message into this list.
+
+Simple wildcards, similar to SSL certificates, are allowed. For example:
+
+ *.example.com:80 # matches foo.example.com
+ # but not example.com
+ # or foo.bar.example.com
+
+ www*.example.com:80 # matches www3.example.com
+ # and www-test.example.com
+ # and www.example.com
+
+=cut
+
+Set(@ReferrerWhitelist, qw());
+
+=back