Page 1 of 1
Weird EOL handling since 3.3.1 (PHP4 branch) upgrade
Posted: Wed Sep 19, 2007 7:45 am
by joho
Upgrading from 3.1.3 to 3.3.1 (PHP4 branch) I noticed something odd. All of a sudden message text would get clipped, static footers that I inserted into the text would disappear, etc. I made no other changes to the code.
Replacing all copies of \r\n, with foo1
Replacing all copies of \r, with foo2
Replacing all copies of \n, with foo3
And then all of foo? back to a given sequence (\r\n, \r, or \n), I quickly found that the only thing that made the e-mails arrive intact was when I replaced all copies of foo? with \r\n, including the EOL sequence in my static text that I force.
I saw too other threads to this effect:
viewtopic.php?t=73643
viewtopic.php?t=72519
I can't quite figure out why this would be the case.
-joho
Posted: Sat Sep 22, 2007 2:12 am
by Chris Corbyn
I'm not completely clear about the EOL problem, but if I understood you correctly Swift changing the EOL right? Which connection are you using?
Posted: Sun Sep 23, 2007 1:01 pm
by joho
What happened to me is that at the first "incorrect" EOL, Swift would consider it to be the end of the message text and nothing after it was added to the final message being sent.
Posted: Sun Sep 23, 2007 4:17 pm
by chuckl
What sort of message content are we talking about Joho, text/plain, html, etc, what encoding, if any and what mail transport are you using, native, smtp, sendmail?
Posted: Mon Sep 24, 2007 10:10 am
by Chris Corbyn
Swift does this:
Code: Select all
$str = str_replace(array("\r\n", "\r"), "\n");
$str = str_replace("\n", "\r\n");
That should in theory turn all valid line endings into \r\n. Are you able to provide me with a test case to work with by any chance?
Does changing to message encoding have any effect? (not a permanent solution).
Code: Select all
$message->setEncoding("8bit");
//and/or
$part->setEncoding("8bit");
Posted: Mon Sep 24, 2007 10:20 am
by panczel.levente
I'm experiencing the same problem (I think).
I'm using version 3.3.1 for PHP5
While attaching related CSS in quted-printable encoding I've found that the string gets trimmed. I made some tries to isolate the problem, and found that the minimal fragment causing the error can be presented by the following code:
Code: Select all
Swift_Message_Encoder::instance()->QPEncode("\r\nbody\r\n{\r\na")
Which yields:
bo=
dy
{
(in HEX: 62 6F 3D 0D 0A 64 79 0D 0A 7B)
These two errors are present:
1) The '=' character is inserted into the string though line break is not necessary there.
2) The '{' finishes the output; anything following it is stripped away.
The problem is most probably with the line-ending fixation logic [Encoder.php line 212: while(preg_match(...) || preg_match(...))], until that point seems everything fine.
Posted: Mon Sep 24, 2007 10:31 am
by Chris Corbyn
panczel.levente wrote:I'm experiencing the same problem (I think).
I'm using version 3.3.1 for PHP5
While attaching related CSS in quted-printable encoding I've found that the string gets trimmed. I made some tries to isolate the problem, and found that the minimal fragment causing the error can be presented by the following code:
Code: Select all
Swift_Message_Encoder::instance()->QPEncode("\r\nbody\r\n{\r\na")
Which yields:
bo=
dy
{
(in HEX: 62 6F 3D 0D 0A 64 79 0D 0A 7B)
These two errors are present:
1) The '=' character is inserted into the string though line break is not necessary there.
2) The '{' finishes the output; anything following it is stripped away.
The problem is most probably with the line-ending fixation logic [Encoder.php line 212: while(preg_match(...) || preg_match(...))], until that point seems everything fine.
Perfect! I'll create a completely new test case for my QP encoding logic and see where we get. What you're saying looks very promising and meets my suspicions that my QP logic could be improved. The difficulty comes in making it both fast and accurate
~joho, if this is the cause too, switching to a different encoding will work for now.