Subject encoded twice and line length problem

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
daneel
Forum Newbie
Posts: 19
Joined: Wed Apr 09, 2008 3:39 pm

Subject encoded twice and line length problem

Post by daneel »

Hi, I'm using SwfitMailer and I encountered with this when sending an email with a UTF-8 or ISO-8859 subject: it is encoded twice. This is bad 'cause some spam filters adds points of spam for this... is there any solution ? Am I missing somehting ??

Also, not all lines are limited to 76 characters... it's wired, but in an email with 900 lines, until line 430 it works OK, but after that line it doesn't...

Well, if someone could please help me !!!

:roll:
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: Subject encoded twice and line length problem

Post by Chris Corbyn »

Actually, this is a problem with spamassassin. It's not really encoded twice; it's split across two lines for compliancy that's all. Even thunderbird suffers from SpamAssassin's misinterpretation of "encoded twice".
daneel
Forum Newbie
Posts: 19
Joined: Wed Apr 09, 2008 3:39 pm

Re: Subject encoded twice and line length problem

Post by daneel »

Alright then, but what about line's length ? Does anyone know what's happening ?

"RAW - Quoted-printable line longer than 76 chars"

(thanks chris :wink: )
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: Subject encoded twice and line length problem

Post by Chris Corbyn »

daneel wrote:Alright then, but what about line's length ? Does anyone know what's happening ?

"RAW - Quoted-printable line longer than 76 chars"

(thanks chris :wink: )
That is a bug ;) The logic used in version 3 use doing some preg_match()/preg_replace() yuckiness and to be honest, it doesn't work too well for multibyte character sets. The first goal of v4 was to overcome this and to provide my own QP encoding implementation based on RFC 2045. I've done that and it works flawlessly. It's longer and more complex than other implementations you'll find online; but it follows the RFC to the word.

To get back to your actual problem in version 3 however (since v4 isn't out yet); what character set are you using?

For the headers I can suggest doing this:

Code: Select all

$message->headers->setEncoding("B");
That will force them to use base64 encoding which is a lot easier to do in PHP and works fine in version 3.
Post Reply