If the GD extension is not available for the PHP installation, then use a
copy of the default client-site logo with the alpha channel removed.

Assume that text in the database is encoded in UTF-8 and assume that it is
HTML text and the entities should be decoded prior to display in the PDF.

Fixes #756

When scanning the file_chunk table for orphaned file chunks that can be
deleted, apparently, MySQL will read (at least part of) the blob data from
the disk. For databases with lots of large attachments, this can take
considerable time. Considering that it is triggered from the autocron and
will run everytime the cron is run, the database will spend considerable
time scanning for rows to be cleaned.

This patch changes the orphan cleanup into two phases. The first will search
just for the pk's of file chunks to be deleted. If any are found, then the
chunks are deleted by the file_id and chunk_id, which is the primary key of
the table.

The SELECT query seems to run at least 20 times faster than the delete
statement, and DELETEing against the primary key of the blob table should
be the fastest possible operation. Somehow, both queries required a full
table scan; however, because the SELECT statement is explictly only
interested in two fields, it is more clear to the query optimizer that the
blob data should not be scanned.

References:
http://stackoverflow.com/q/9511476

Some mail clients and mail brokers do not properly handle quoted-printable
encoding, used in osTicket outgoing emails. Oddly, the end mail clients
render the email with trailing equal signs (=) at the end of every line,
where it was added due to QP encoding.

References:
http://www.osticket.com/forums/forum/osticket-1-7-latest-release/troubleshooting-and-problems-aa/10708-solved-microsoft-exchange-internet-mail-lines-end-with
RFC 2045 section 6.7, http://www.ietf.org/rfc/rfc2045.txt

If the body is declared with inline disposition and no filename, the parser
engine would create an incorrect attachments list.

If it only contains whitespace, it is also invalid

line is used.

id/number.

* Ticket number will be customization in the future
* Ticket thread only link to Ticket should be internal ticket id.

if the References or In-Reply-To header matches in a way that continues a
ticket's thread, include the attachments in the thread if allowed by the
system settings.

In the event that the system is set to do-nothing for POP fetched
emails, and eventually, one of the emails is rejected, ensure that the
message-id is logged so that the message will not be re-fetched, even if it
is undeleted.

Fixes #742

On some configurations of PHP and remote mail servers, Kerberos and NTLM
challenge response authentication could be possibly attempted. This is
essentially futile and potentially fatal for osTicket mail fetching, as the
system is currently designed for username and password authentication only.

This patch disables challenge and response authentication for PHP versions
5.3.2 and newer, which support the fix.

This patch also consistently encodes mailbox names according to the rfc 2060
for IMAP.

Previously, filenames specified in email headers fetched using the PHP imap
extension were not decoded properly. Specifically, if RFC5987 was used to
encode the filenames, no decoding was performed at all.

This patch properly detects the filename attribute, using a decoding scheme
for RFC5987 if the attribute was encoded properly.

References:
http://osticket.com/forums/showthread.php?t=6129

RFC2045, section 5.1 seems to indicate that arbitrary parameters can be
appended to a Content-Type header specification. Some email clients seem to
use the Content-Type header to specify an attachment without giving a
separate Content-Disposition header normally used to signify attachments.

This patch corrects attachment detection for piped emails to detect such
emails. The patch also correctly decodes filenames specified either in the
Content-Disposition or Content-Type headers using RFC5987, where the
filename can be encoded using an arbitrary character set (ie, not us-ascii).

8e72e521 (v1.7.1.2+) introduced a bug where
osTicket version 1.6 would not send a cookie (by calling PHP
session_start()) for the login page. Therefore, after unpacking the 1.7.1
source code, an upgrade would not be possible, because a login would never
be processed correctly.

When comparing the From address of incoming email. If the ticket owner sent
an email back into the system and the email address did not match exactly,
case-wise, the email would not be considered from the ticket owner.

Also converts ROOT_DIR detection to always use forward slashes. And it fixes
the removal of the leading double-backslash on Windows UNC names (fixes #649)

This is safe now, because the title is appropriately encoded in
class.thread.php/ThreadEntry::create()

Fixes #567, #718

if the domain given in HTTP_HOST variable happens to have a port
specification. Technically, the port specification should not be included in
the domain spec given in the cookie.

(And for the record, that makes no sense to me, seeing as a cookie would
otherwise be valid for all servers on any ports at a particular domain).

The previous implementation did not work correctly for symlinked folders.
The new approach uses debug_backtrace() and ROOT_DIR to determine the
difference between ROOT_DIR and the osTicket installation path.

This thing is like a turd that won't flush

and restarts PHP SESSION

Also, allow for the administrator to manually define the ROOT_PATH in the
config file (the very last mile).

If an alert message manages to loop back into the ticketing system, refuse
posting to the ticket thread. Technically, the message should be marked as
an auto-response message; however, auto-response messages should usually be
allowed to be appended to the ticket thread.

This patch will check if the From email header cites an email address that
is a system email address (visible in the Emails section of the Admin
Panel). If it is, the email is completely ignored.

Web browsers don't appreciate a cookie domain without any dots. This patch
detects the originally-requested domain for the request. If the domain does
not contain dots (such as 'localhost' or the name of a local server on your
network defined in your hosts file), no cookie domain is sent.

The greatest symptom of this issue what the illustrious 'Invalid CSRF token'
seen repeatedly on the scp login page. The reason is that the browser was
rejecting the cookie from the server.

Fixes #677, #672, #653

This code was lost when the message-id tracking feature was implemented

Web browsers don't appreciate a cookie domain without any dots. This patch
detects the originally-requested domain for the request. If the domain does
not contain dots (such as 'localhost' or the name of a local server on your
network defined in your hosts file), no cookie domain is sent.

The greatest symptom of this issue what the illustrious 'Invalid CSRF token'
seen repeatedly on the scp login page. The reason is that the browser was
rejecting the cookie from the server.

Fixes #677, #672, #653

If unable to detect the root path, provide a fallback ROOT_PATH setting to
'./'. This is likely to happen if run from the commandline (like for crons)
or if DOCUMENT_ROOT and the folder of main.inc.php seem to have nothing in
common

Fixes #704

Previously, filenames saved in the database had the spaces changed for
underbars; however, other characters (such as commas and non-ascii
characters) presented issues with user agents downloading the attachments.

This patch handles the filename encoding for two special cases -- internet
explorer and safari, and provides the semi-standard RFC5987 method of
encoding the filename for the remaining browsers.

Attachments are no longer forced to be downloaded. It is up to the browser
to decide if the attachment should be shown in the browser or downloaded.

This patch also fixes a slight bug in the caching mechanism for downloads
concerning the last-modified time. The date sent to the browser was not
properly converted to GMT time, although the server claimed that it was.