Thread

Thanks for the response, rt30000. We’ll be here.

I’m a little fuzzy on how this one is breaking.  I sent a plain text and a very simple html email to my gmail via communicate and they both came through as expected.  The html wasn’t parsed in my ellislab mail- but neither is one I sent from gmail, so that’s just an email setting, nothing about your emails per se.

Can you do me a favor?  Create 2 text files I can copy/paste into the communicate field.  One plain text, one html.  Make sure they are breaking for you.  IF you can- test in gmail- make sure they break there too.  Let me know how exactly the specific content from each text file breaks (in gmail if at all possible).

I will note- email clients can be very finicky about how they handle html email- so sometimes it’s not the email server but the html itself.  (I recall having templates tested on various clients that we used when I was freelancing- because slight variations could cause some clients to just hate the html.)

It does sound like stuff is going wrong- I’m just not experiencing it with my test data.  The only thing I changed was to flip word wrap on.  So- let’s get me some test data we know breaks, and I’ll use that sending it to my gmail and my ee email accounts and see if I can replicate.  If you can attach a couple of zips, I’ll test things with that content and see what I can spot.

Plain text emails appear to be working, but I NEED to get html issues resolved to take a site live. I will email you a zip file with an html excerpt and a screencaps of display in Outlook 2007 and iPhone Mail app. Can you send me your email address, Robin? Thanks.

rt30000,

Send it to robin.sowell [at] ellislab.com

Thank you. Email sent to Robin.

Thanks for passing email on, John Henry.  Got the data and testing now.

Hi, just touching base. It’s been a couple weeks, any insights or progress Robin?

I’m sure Robin will see this, but I’ll let her know you posted.

ty

No worries. Thanks for your patience.

Hi Robert,

Do I have your permission to create a standalone test script on your server to do some closer debugging?  I get the feeling that a server along the way is adding either \r or \n to each existing line break.  Robin sent me an HTML email from your site and it both rendered correctly in OS X Mail and the unrendered source is what I would expect.

--B_ALT_4c37778648762
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<h1>This is an example of an html email for testing in Expression Engine Co=
mmunicate Form</h1>
The following is an example link where you can see quotes inside the htm=
l are converted and display odd in Outlook 2007: <a href=3D"http://expressi=
onengine.com/public_beta/">http://expressionengine.com/public_beta/</a>. Al=
so, soft returns or equal signs are displaying in the email as well. I thin=
k it may be an encoding issue in quoted_printable? It's a little above my h=
ead but I have been trying for quite some time to figure it out. I will sen=
d a screencap with this message to show how it displays in Outlook.
Paragraph 1
<h2>Subhead</h2>
<p>Thanks for the help.<br />
<ul><br />
    <li>Line 1</li><br />
    <li>Line 2</li><br />
    <li>Line 3</li><br />
</ul></p>

<p>--B_ALT_4c37778648762--

Yes Derek, that would be fine. Sorry for the delayed response - I must need to re-subscribe to this thread because I haven’t received any notifications on new posts. Thank you.

Thanks rt30000, sorry for the delay - as you can see, we just launched 2.1 and a new site design so I’ve been caught up the past few days.

I put a CI2 installation on your server so I could quickly fiddle with the email configuration and compare what CI is outputting to the server vs. the raw source of what actually got delivered to my inbox.  Your server appears to be one that requires \r\n for both crlf’s and newlines in content, which is common on Windows servers.

Even though the RFC standard is \r\n, by default CI2 (and hence EE) use \n for both, as the vast majority of email servers don’t follow the RFC, or try to muck around with \n’s to standardize them.  In these cases, if the email class sent \r\n, the server would convert it to \r\r\n and really hose things.

At any rate, the fix should be fairly simple:  In your /system/expressionengine/config folder, add a file named ‘email.php’ and add:

$config = array(
    'crlf' => "\r\n",
    'newline' => "\r\n"
);

And ExpressionEngine will use those values when constructing the emails.  I’ve gone ahead and made this change for you in the installation you gave us access to for your convenience, and tested the output and raw source of the received email.  Displayed perfectly in OS X Mail and Gmail.

So, you were on the right track all along, but those 1.x hidden config items might not be observed properly in 2.x, which we’re looking into.  Please let us know if that solves the issues you were having.

Hi Derek,
I understand the work load, lots of good momentum for EE. I have been testing for about 45 mins and unfortunately the same issues persist. Gmail displays correct but Roadrunner denies/bounces the email saying it has invalid headers, Outlook 2007 displays incorrect and the iPhone Mail app displays source code instead of html. I am curious if it’s an encoding/quoted_printable issue versus line breaks. I vaguely recall having a similar issue on a CI site and a user submitted a revised email library file that fixed. I tried looking it up before and comparing, but it was based off an older version of CI than EE is using.

I am not sure if it is the same issues, but here is a CI thread with an email library for an OLD CI site that had the same display issues, and a user-submitted email library file resolved the issue. http://ellislab.com/forums/viewthread/97440/

Well, qp encoding has line breaks, and = at the end of each line indicates that the line is continuing.  In all cases the qp encoding looks correct, and can be examined by the email debugging output in CI.  But if the email server is injecting additional line breaks or carriage returns, it would cause many MUAs to not decode it properly.  The line breaks become part of the content, and if a hard line break is seen mid-word or mid-tag, the HTML content becomes mangled.  GMail and OS X must be more lenient, or ignore extraneous breaks.  In any case, the line breaks and carriage returns also affect the headers, as they must have specific breaks for email servers and MUAs to parse them.  Again, the CI debugging output looks correct on the hand-off, so something is taking place on the server.

Does Roadrunner give you any more details about the rejection?  Do you have access to an SMTP server that you could use for outgoing mail instead of PHP mail from this Windows box?