Make ExternalAuth also respect the ?next=hash argument after logins
(cherry picked from commit 5dfa1847869db1040b685293af14858e3804abd1)
Provide some rationale in comments for the convoluted logic
(cherry picked from commit 49bd564ca4a883a37af17711ba584a98bc1ca1e1)
WebExternalOnly was renamed to WebFallbackToInternalAuth

Although it was caught in 21874f2c back in 2006, that commit was
accidentally reverted in 3027bf06 during a merge.

This commit applies effectively the same diff as 21874f2c.
(cherry picked from commit 71c59d6157d08be514a00b359290d7f7486a0f92)
Intuit the next page when logging in at the RT web root

Forcing the next page to WebURL, or even WebPath, loses the potential
query parameters to index.html.  Perhaps most common is the URL

    /?q=foo

for a quick search.  It was previously lost during the login flow.
Abstract away reading $session{NextPage} into two functions

Setting is already wrapped, but reading was direct.  Following commits
will use FetchNextPage for display.
Anticipate storing more information about the next page in the session
Check the original request for side-effects before prompting for login

Sets the foundation for informing users about to login what will happen
after they do so in order to help prevent phishing.

Note that while this shares some code and config with CSRF, it _isn't_
CSRF since the user is not yet logged in and it requires a user to fill
in valid credentials.  Sharing config allows administrators to whitelist
external sites, such as corporate portals, which deep-link into RT, thus
preventing RT from crying wolf to the end user about legitimate
requests.
Fix a typo, preventing emails from setting internal encryption header

X-RT-Incoming-Encryption, along with a number of other headers, is
removed from all parts of incoming emails because they are used to
annotate GPG-related properties of the message.  Fix a typo, which
allowed the properly-spelled header to pass through under specific
circumstances.
Remove internal signing and encryption hints from incoming mail

RT uses the existance of the X-RT-Sign and X-RT-Encrypt headers to
decide if the outgoing mails it sends as a result of the transaction
should be signed and/or encrypted.  It standardly inserts these headers
based on checkboxes visable in the web UI; however, it fails to remove
them from incoming mails, allowing external users to create nearly
arbitrary messages signed by the queue's key.
Restrict users to only signing with queue or their own personal keys

While the UI only presents two options for signing, the underlying form
accepted any key ID or email address, and dutifully signed the mail with
the appropriate secret key.  Restrict the accepted values of SignUsing
to the two values that we displayed.
Don't propose any secret keys to users with no email address

GetKeysForSigning, when called with 'force', returns all keys if no
email address is provided.  This caused users with no email address to
have all secret keys offered to them.  Remove the 'force' to ensure that
empty email address are shown an empty list.
Explicitly restrict private keys to ones offered
Avoid spurious update and warning messages on key update

This avoids an ominous-looking warning about failure to remove the key,
when no key was previously set but no key was newly selected.
Blacklist components from automatic, argument-based CSRF whitelisting

Not all pages which take only an id query parameter are idempotent.  The
ticket bookmark toggle — generally used via ajax — requires only id to
toggle bookmark state.

Start a blacklist, which should remain small, for these components.
Headers in the parsed MIME entities of Templates are modifiable

This allows reformatting of inserted headers by canonicalizing tag case
and, crucially, folding (or refolding) lines.

When the header object is not explicitly marked modifiable — such as
when generated via parsing a raw MIME message — Mail::Header assumes
that header values you set should be inserted as-is.  This means
newlines are not stripped or validated as you're expected to construct
proper continuations yourself.

RT incorrectly assumed newlines in header values would be stripped,
leaving open the possibility of header injection via various
user-controlled inputs.  This commit resolves CVE-2012-4730.

Fixes failing tests by removing the assumptions that:

    1) Case of header names is preserved
    2) Header values are always on a single line
Don't encode folded headers, such as Subject

Now that long Subject headers may be folded during insertion, headers
may contain \r\n, which EncodeToMIME incorrectly then MIME-encodes.
Cherry-pick back 1c1d8a2, which ensures that we do not un-necessarily
MIME-Encode subject headers merely for being folded.
Comment on our invalid pattern for splitting headers

And why we can't fix it now.
Perltidy only before updating the SetHeader method
No need to match on the rest of the header line(s), just the tag

Simpler, less prone to a mistake (like the one in SetHeader to be fixed
next).
Don't require a \r before the \n when forcing header continuations

A bare \n needs to be continued just as much as \r\n.

This doesn't fix the bug of adding an extra space to existing valid
continuations.