There is something wrong with Kayako's quoted printable email decoder - it translates the =20 as a newline... this is incorrect - it is a space! 20 Hex = 32 decimal = space in ASCII table. It does appear to decode the other characters correctly (i.e. =3D becomes '=' which is correct). But it is definitely handling =20 wrong. I came across this while trying to figure out why some of my breakline regexes weren't working as expected and it turns out this was the reason - it was putting in a newline where there is supposed to be a space when decoding the QP. Hopefully some Kayako dev reads this...
Debugging it some more - I am in the function _quotedPrintableDecode in __swift/thirdparty/MIME/mimeDecode.php and it correctly replaces the =20 with a space, hmm... Now I'm thinking the problem is with an encoder somewhere (either Kayako or Outlook), not the decoder. The issue I am looking at is that <DIV><B>To:</B> <A title=foo@gmail.com=20 href=3D"mailto:foo@gmail.com">foo@gmail.com</A> = </DIV> Becomes <DIV><B>To:</B> <A title=foo@gmail.com href="mailto:foo@gmail.com">foo@gmail.com</A> </DIV> And not <DIV><B>To:</B> <A title=foo@gmail.com href="mailto:foo@gmail.com">foo@gmail.com</A> </DIV> As I would have expected. The problem is the encoder outputted =20 instead of =20= (the last = meaning soft line break). I'm going to look at Kayako's QP encoder next.
Grrr - looks like the fault is with Outlook. I did a few tests (sending emails via Kayako, replying via Outlook)... Kayako sent: This is going to be a multiline response...<br /> This is the= second line.<br /> <br /> This is the fourth line.<br />= Looks good. And when replied to via Outlook it turned into: This is going to be a multiline response...<br /> This is the=20 second line.<br /> <br /> This is the fourth line.<br />= *FACEPALM* I'm gonna have to add some code to Kayako to "fix" the Outlook mangling of the QP. Fortunately because newlines are meaningless in HTML (other than being inside a <pre> tag) this should be an easy fix... I hope.
Ok - I added one line of code to __swift/thirdparty/MIME/mimeDecode.php at line 284 (right after the case 'text/html' statement): Code: $body = preg_replace('/\=20\r?\n/', "=20=\n", $body); Basically this switches =20 at the end of a line to a =20= - this has no consequence for HTML rendering (except if it happens to be inside a <pre> tag but I'm not worried about that...) but it definitely will help breakline processing! I'm about to do some real testing with this to see if its all good...
