ZF-264: Quoted Printable Problems

Description

Problem 1:

First the rfc states lines have a 76 character (encoded form) hard limit in length. This limit while implemented isnt working quite right. Lines regularily reach 80 chars.

This is due to the tack on of the =20 after the split (see second line) the other lines I think are over by one character but I might just be counting wrong.

IE:

man",Times,serif; color: #666; margin-bottom: 5px; line-height: 1.5em; borde= r-bottom: 1px solid #ccc; font-size: 20px; margin-top: 10px; }=0A=09=09h2 {=20= font-size: 14px; color: #666; margin-bottom: 10px; line-height: 1.5em; borde=

Problem 2:

= line endings, aka soft breaks.

Im not sure why, and I dont see in the RFC any explanation but my email clients all have a problem with the following line ending scenario

An encoded entity, followed by a softbreak, immediately followed by another encoded identity

Eg

=09=09US
=0A=09=09=09=09=09Phone #: 1
=0A=09=09=09=09=09=09=09=09= =09

=0A=09=09=09=0A=09=09=09=0A=09=09=09=09= This will always result in an = sign being printed on the line below Phone #:1. My intutition is that if the following line begins with an identity, the soft-break = should be omitted, though I cant find anything in the rfc to back this up.

Comments

Update.

Chanign the line ending from \r\n to \n by itself resolves this error in a functional way. The new resultant output however, appears RFC invalid.

A temporary fix is

Index: library/Zend/Mime.php

--- library/Zend/Mime.php (revision 918) +++ library/Zend/Mime.php (working copy) @@ -39,7 +39,7 @@ const DISPOSITION_ATTACHMENT = 'attachment'; const DISPOSITION_INLINE = 'inline'; const LINELENGTH = 74; - const LINEEND = "\r\n"; + const LINEEND = "\n"; const MULTIPART_ALTERNATIVE = 'multipart/alternative'; const MULTIPART_MIXED = 'multipart/mixed'; const MULTIPART_RELATED = 'multipart/related';

I seem to have similar problems.

GMX mangles mails sent with Zend/Mail. It does convert the softbreaks to real line breaks. Also when using POP3. I suspect their spamfilter but I don't know what to do about it. Having 8-bit encoding would probably fix this. I'm not sure about workarounds.

We use Zend Framework and especially Zend_Mail in our product SiteBuilder - http://www.swsoft.com/en/products/sitebuilder3/ We have responce about this bug from our customers. LINEEND = "\r\n" really doesn't work correct all the time (many reports about using this with qmail installations). But using LINEEND = "\n" solves this problem. We had tested with many intallations of sendmail, postfix and qmail MTAs and LINEEND = "\n" always worked correctly. So I suggest to apply fix into SVN.

Scheduling for release 0.7.0.

It possible to get the spam cleared out of here ;)

And maybe even get the scheduled release bumped up ;)

I saw that this wasn't addressed in the 0.7.0 release.

I realize that \r\n is the RFC but something in how it is implemented in ZF does not make several MTA's happy.

Here are problem mail servers/clients you can use to test.

With \r\n in Zend/Mime.php send a multi-part html/text email using quoted-printable.

Use QPopper on the local machine to retrieve mail to any mail client (i.e. Outlook) - HTML is shown badly broken

Send to a gmail account - html will be broken.

Send to Exchange 5, Lotus Groupware (just about any version) - html broken.

gmail is probably the easiest test for this project to use.

What is the deal with this getting continually pushed back. Do the developers disagree with the proposed fix?

Matthew,

Can you give an update on this issue please?

I've patched the Zend/Mime.php file in revision 4310. Please update from SVN and test. It still passes all unit tests, but I want to be sure that it resolves the problems reported by each of you.

Garth -- the reason for the pushback has been a simple lack of time to address all my areas of responsibility in the framework. I apologize -- it's indeed a trivial fix, but it's been entirely off my radar.

I checked the SVN history and see that all you changed was the LINEEND line - that is what I have always changed - so this change will work with the mailers I outlined above - including gmail.

Thanks!

Resolving per Garth Gillespie

Changing LINEEND does not resolve this bug. Its a tempfix at best. The larger issue here is RFC invalid quoted printable support.

Reopening as this issue is not resolved.

Issue resolved by adding a new function Zend_Mime::encodeQuotedPrintableHeader which enforces RFC

I copied to 1.7 branch at SVN r13886.

Sorry, not in 1.7.4. I think it will be released in next minor or major.

This will be in 1.7.5