Weird EOL handling since 3.3.1 (PHP4 branch) upgrade

Swift Mailer is a fantastic library for sending email with php. Discuss this library or ask any questions about it here.

Moderators: Chris Corbyn, General Moderators

Post Reply
User avatar
joho
Forum Newbie
Posts: 16
Joined: Tue Oct 17, 2006 4:34 am
Location: Stockholm, Sweden

Weird EOL handling since 3.3.1 (PHP4 branch) upgrade

Post 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
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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?
User avatar
joho
Forum Newbie
Posts: 16
Joined: Tue Oct 17, 2006 4:34 am
Location: Stockholm, Sweden

Post 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.
chuckl
Forum Commoner
Posts: 61
Joined: Wed May 23, 2007 7:36 am

Post 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?
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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");
panczel.levente
Forum Newbie
Posts: 2
Joined: Sun Sep 23, 2007 4:43 pm

Post 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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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.
Post Reply