Include changes from 1.7.2

Conflicts:
	main.inc.php

Change PDF print to show custom logo

Reviewed-By: Peter Rotich <peter@osticket.com>

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.

Crazy performance penalty scanning blob tables

Reviewed-By: Peter Rotich <peter@osticket.com>

Better converting from ticket thread to PDF

Reviewed-By: Peter Rotich <peter@osticket.com>

Die with internal server error on misconfiguration

Reviewed-By: Peter Rotich <peter@osticket.com>

Fix parsing of attachments

Reviewed-By: Peter Rotich <peter@osticket.com>

Use base64 encoding for text version of emails

Reviewed-By: Peter Rotich <peter@osticket.com>

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

Or internal server (database) outage

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.

Record message-id's for rejected emails

Reviewed-By: Peter Rotich <peter@osticket.com>

Limit admin alerts to logged messages.

Reviewed-By: Jared Hancock <jared@osticket.com>

Forbid empty reply separators

Reviewed-By: Peter Rotich <peter@osticket.com>

Expose fail count to shell environment

Reviewed-By: Peter Rotich <peter@osticket.com>

Also, run the tests in the packager. The packager will automatically run the
regression test suite prior to packaging a release. The package will not
build if there is at least one fail from the regression tests.

Allow deployment of setup/

Reviewed-By: Peter Rotich <peter@osticket.com>

Useful for initial installs, where deployment of the `setup/` folder is
required for the initial install. Thereafter, deployment can be run without
the setup option so that the rest of the codebase can be maintained (already
supported)

Disambiguate version string when running off of git

Reviewed-By: Peter Rotich <peter@osticket.com>

Message id tracking revisited

Reviewed-By: Jared Hancock <jared@osticket.com>

Disable Kerberos and NTLM auth for mail fetch

Reviewed-By: Peter Rotich <peter@osticket.com>

Implement RFC5987 for fetched attachments

Reviewed-By: Peter Rotich <peter@osticket.com>

If it only contains whitespace, it is also invalid

If a user is running off of the develop branch, disambiguate what the
version they are running.

line is used.

id/number.

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

Accept attachments from email messages

Reviewed-By: Peter Rotich <peter@osticket.com>

Actually show correct template description

Reviewed-By: Peter Rotich <peter@osticket.com>

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

Detect attachments with Content-Type: ...; name=

Reviewed-With: Jared Hancock <jared@osticket.com>

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).