This is necessary so we don't add delivered-to addresses to the list of
addressee/collaborators.

Previously, the Delivered-To header was only used if the To header was not
found

If a wrapped mail is sent, copy the Delivered-To header into the nested
message so it will be clear(er) how the mail arrived into the system. Also,
copy the Message-Id into the nested mail if there is none to help against
mails delivered repeatedly.

If an email arrives at the system and the system cannot determine why the
mail arrived (ie. a system email was not found in the To or Cc headers), the
recipients list should be maintained.

This is useful for generating collaborator lists as well as filtering by the
To and Cc (Addressee) headers.

07fec4c4 introduced the ability to receive
and process messages forwarded as a message/rfc822. However, the email
headers that were saved on file in the %email_info_table were the headers of
the outer message.

This patch pulls the headers from the wrapped message to be saved in the
database. This mainly addresses the email References and In-Reply-To headers
for the email responses from the system.

This would in theory allow us to decide at the email level the content type
to accept.

Fixes a few E_NOTICE messages
Drops bounce checking inside autoReply checking

Previously, if a message had a Content-Disposition header, then it could not
be considered as the body of the message.

If the mail received into the system has a content type of 'message/rfc822',
then unwrap the inner message and use it as the parsed email. Effectively,
assume the email was forwarded as an message/rfc822 attachment.

Previously, the mail parsing and fetching system would recurse unbounded
searching for bodies by content-type

Provide facility to set collaborator status on add.

And avoid double encoding email bodies if html thread is not enabled

Previously, the References header emitted by the system for new thread
entry auto-responses and alerts included the message-id for which the email
was a reply in the `References` header. This patch corrects the issue by
placing the reply message-id in the In-Reply-To header, and constructs a
correct References header.

That is, if available, the References header received in the email that was
used to create the thread entry is appended to the message-id the email is
actually in reply to. This is the expected usage of the References header.

This provides better compatibility with mPDF, which doesn't support the CSS
white-space:pre-wrap property

Use a PHP setup which uses the built-in PHP tokenizer to parse and traverse
PHP scripts to determine (possible) access to uninitialized variables

Provide fallback html2text mechanism if PHP xml extension is not available

Including adding support to the TCL uninitialized variable reader to ignore
class-static variable access as well as detect inline functions and their
closure arguments.

Whether HTML ticket thread is enabled or not, consistently handle the
processing of the email bodies

Some email clients (names omitted to protect the innocent) advertise the
encoding as us-ascii when iso-8859-1 was really implied. This patch allows
the two charsets to be interchangable.

Process inline attachments in thread entry and support inline images in
piped emails

Support inline images across the system, with draft support

Migrate to a single attachment table
    That way we don't need a new table for everything we need to attach an
    inline image to (like a signature, for instance)

Add richtext support for internal notes

Implement images on site pages

* Image paste in Redactor
* Make non-local images optional
* Placeholder for non-local images
* Fix local image download hover
* Don't re-attach inline images

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

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

The mainly comes in when a MIME header which might contain a list of email
addresses (like Reply-To) is to be parsed, but is empty. The Mail_RFC822
class would return an empty mailbox @ localhost (where 'localhost' is the
default default_domain for mail address list parsing).

The email filtering feature supports a 'Use Reply-To' feature, but seems to
never have been implemented. This patch officially supports using the
Reply-To email header as the From header for emails matching the filter.

And ensure that the email address is trimmed to help matching against email
registered for previous tickets.

If there characters in the plain text body of the email that appear like
HTML tags, for instance

From: <sip:527772432@172.18.0.2>;tag=952422a9dd1ap1a6o1

The <sip...> part would be removed by the Format::striptags() call in
Format::sanitize().

- Handle decoding large base64 encoded attachments better
- Avoid transcoding from one charset to the same
- Avoid encoding attachments without a declared charset

Convert to desired charset when getting email parts.