Such images are attached to emails by Lotus Notes. Technically, these images
are valid attachments, although historically osTicket would reject them

email.

This is necessary to eliminate possible loop when an email is sent to a
virtual/aliased address. Not all mail servers add delivered-to header!

Duplicate delivered-to handling from mail parse as temp. solution.

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.

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

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

Provide facility to set collaborator status on add.

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.