imap_fetchstructure sometimes returns encoding 6 and it is not present in Part::$encodingsMap about imap

[perk11]

Values 7-10 are also returned by imap_fetchstructure for some messages for me.

[mrtimp]

I've started seeing this issue within the past week from emails @didx.net, I'm not seeing them from anywhere else. Presuming the 'encoding' is derived from the Content-Transfer-Encoding header then their emails are seeing them to "quoted -printable" (without quotes). I haven't yet had sufficient time to replay this issue in my development environment and find a solution but when I do I will update this issue.

[mrtimp]

Also, I'm using PHP 5.5.20-2 (CentOS 6) package from the REMI repository. PHP information shows:

IMAP c-Client Version => 2007e
SSL Support => enabled
Kerberos Support => enabled

[mrtimp]

On closer inspection it looks like the remote mail client may be incorrectly building the header. I've noticed in all of the failed emails there is a space between quoted and -printable. May be able to apply a patch to Message/Part.php in the parseStructure method to look for broken encoding types and correct them. Depending on the reuse from the call to loadStructure in Message.php it may be better to apply the adjustments there.

[mrtimp]

I've had some time tonight to investigate further. I must say that i'm conflicted on what the right thing to do here is. Part of me thinks in the real-world you need to work round quirks with broken email messages to ensure that it doesn't impact your ability to work with 'all email messages' and the other part of me thinks that you should reject them if they are invalid.

I'm more than happy to do a PR if the developers feel its something of value.

Either way, here is a diff of my changes to fix my scenario:

Index: src/Ddeboer/Imap/Message.php
===================================================================
--- src/Ddeboer/Imap/Message.php    (revision 2802)
+++ src/Ddeboer/Imap/Message.php    (working copy)
@@ -306,6 +306,23 @@
     protected function loadStructure()
     {
         $structure = \imap_fetchstructure($this->stream, $this->messageNumber, \FT_UID);
+
+       // look for an unknown character type encoding
+       // to provide manual overrides if applicable
+       if ($structure->encoding > 5) {
+           $headers = \imap_fetchheader($this->stream, $this->messageNumber, \FT_UID);
+
+           // match the character type encoding header to apply
+           // any additional manual fixups or overrides
+           if (preg_match('/^Content-Transfer-Encoding: (.*)$/im', $headers, $matches)) {
+               $matches[1] = trim(preg_replace('/\s+/', '', $matches[1]));
+
+               // pattern match other content type encoding that needs
+               // to be manually remapped to another encoding type
+               if ($matches[1] == 'quoted-printable') $structure->encoding = 4;
+           }
+       }
+
         $this->parseStructure($structure);
     }
 }
\ No newline at end of file

[mrtimp]

@perk11 I would be interested to see messages that were returning values 7-10 from imap_fetchstructure if you have any examples.

[perk11]

@mrtimp I'm not sure how to get full message text from debugger, here is structure of one of these messages: http://imgur.com/SAX4O97

[perk11]

So I logged headers for ALL messages from the problem account in Message::loadStructure() and interestingly enough I failed to get encoding values greater than 6 in Message::loadStructure(), I only get them in Part::parseStructure(). I'm not sure how this is even possible, but this is what happens.

[Slamdunk]

Without examples and testable data, we can't do better than throw exception in case of unknown encoding, implemented in #197.

@mrtimp we can implement manual look up for Content-Transfer-Encoding, but only with examples and enviroments variables:

1. What is the message full body?
2. What is the IMAP server and configuration?

As soon as we'll have all this info, we'll adapt the code. Until that time, we'll stick with throwing an exception.

Thank you all for the feedbacks.