If the content of the message is of type `message/rfc822`, then support
downloading the body of the message and sending it off to the mail parsing
system, simulating a piped email.

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.

Disable auto-response on a bounce.

Processing fetching in ASC order of the last fetch time
Remove LIMIT of 10 emails per fetch
Flush the buffer and terminate the request cleanly on autocron

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

A mail client may indicate a header parameter (such as Novell Groupwise,
which may add something like

Content-Disposition: inline; modification-time: "Thu ..."

) Previously, the system would not consider the content to be a candidate
for the email body, because it has parameters to the content-disposition
header.

This patch will still consider the part to be a candidate for the body if
the mime types match and no filename is found in the content-disposition
parameters.

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

Handle cases where email headers contain unicode or high-ascii characters
and are not encoded according to RFC-2047. This patch handles a special case
where a detectable unicode character set is used, such as UTF-8. For
high-ascii characters in a character set other than iso-8859-1, the result
of this patch is undefined.

Fixes #826

If a Content-Disposition header exists for an attachments, it isn't required
to have any parameters (like a file name)

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

Provide fallback html2text mechanism if PHP xml extension is not available

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

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.

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

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.

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

This patch affords an administrator the ability to remove the
[#%{ticket.number}] from the email template subject line for the new ticket
autoresponse and the new message autoresponse. Previously, the ticket number
with a prefixed hash in brackets was used to identify which ticket thread an
email was in reference to.

With this patch, the email message-id (which was already kept on file) is
sent in the MIME "References" header. When a user responds to and
autoresponse email, the "References" will include this message-id in the
return email. The ticket thread is then matched up with the email based on
the message-id rather than the subject line.

Ticket numbers are still supported in the subject line, in the event that
non-compliant email clients do not properly include the References header.

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.

Incoming messages with empty body and an inline attachment might not have
parts - depending on encoding used.

* Use "-" tag for emails with empty body/message

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

Some mail clients and servers (like the ones developed in the northwestern
United States) sometimes place encoded and non-encoded data in an email
body declared with "Content-Transfer-Encoding: base64". imap_base64 will
refuse to decode the body if it contains non base64 characters (like a
period, colon, apostrophe, etc). This patch uses base64_decode as a fallback
which will make a best effort to decode the data. In the case of our test
mails, the decoded data will contain garbage where the non-base64-encoded
data was in the original mail, but at least the message is preserved.

Spelling, grammar and readability in upgrader documents
  - Tweaked spelling, grammar and wording to make the text of the upgrader
    pages more readable.
Fixed spelling regression
  - Higly —> Highly
Spelling and readability fixes for /include/class.* files
  - Fixed some spelling mistakes
A couple more spelling/readability fixes.
  - More fixes

Rename $var to $var - for consistency