Email class - incorrect headers?

[eluser]Ahmed Nuaman[/eluser]
I've been having a play with getting the email class to work, but I never seemed to receive the emails. I then had a look at the logs on my server and it looks like the email class is sending emails with incorrect headers and flushed it. Also, I can't seem to turn off wordwraping as this makes the email (as HTML) not render properly. Any ideas?

[eluser]Derek Jones[/eluser]
What's the reduced code from your controller, Ahmed? Are you setting the 'mailtype' properly? HTML emails aren't affected by the word wrapping settings, they are sent as quoted-printable encoded text. You'll have to elaborate on the headers - which headers does your email server consider invalid? CI sends emails that conform to RFC 2045, with one minor emendation because of real-world compatibility issues with CRLFs.

[eluser]Ahmed Nuaman[/eluser]
Sorry about being very brief on the post. I'll need to revert back to my old code in order to send a test email.

Mail property was always set to "html" in "Email.php" as $config["mailtype"] and also as $mail->SetMailType("html") (that might not be the exact spelling but I think you'll understand).

Looking at some text emails I've kept, the difference between CI's class and PHPMailer is that CI still uses 'User-agent' header. This may've been the header that's thrown our server. Then again, I could be very wrong. Unfortunatly (and this is frustrating) all our server says is "incorrect header line found while scanning headers".

I'll look into it.

Also, because our server's Windows, it likes \r\n and not \n. I had to find that out the hard way with the Email class.

PS I'm speaking about two different servers here: the windows is our dedicated web hosting server and the mail server is a Mac OS X Tiger in-house server.

[eluser]Derek Jones[/eluser]
If you look at the comment next to the the $crlf property in the Email class, you'll see why we chose '\n' instead of '\r\n', but you're free to change that if your server requires it. Many email servers in the wild (incorrectly I might add) try to force CRLF consistency by blindly replacing \n with \r\n. So if you use \r\n on these servers, you end up with \r\r\n, which wrecks the email in every MUA. So we use \n only. Your web server should be immaterial to this process, though, unless it is converting line breaks as well when sending mail, which wouldn't entirely surprise me.

For the incorrect headers, you'd probably need to track down support from Apple, as I do not even know what application OS X server uses to fetch mail, and this has never been reported, and the same headers are used in our commercial application ExpressionEngine. What's the full line from the console error log?

[eluser]Ahmed Nuaman[/eluser]
In regards to the CRLF, it was to do with the exchange between CI and the SMTP server rather than the actual email's body.

In regards to the mail server, I'll have a look and see if there's a bug fix. Unfortunately, all the log says is that there's an incorrect header. I do wonder, however, if I was to play with CI's headers and do some testing that way.

[eluser]Derek Jones[/eluser]
Right, but doesn't the console message contain a timestamp and process? e.g.

Code:

1/23/08 Jan 23 - 12:23:17pm     process_name[PID]     incorrect header line found while scanning headers

[eluser]Ahmed Nuaman[/eluser]
Oh right, yes, I thought you meant more. The process is by something called "fetchmail". The time, I'll have to get that to you tomorrow as I'm out of the office now.

[eluser]Derek Jones[/eluser]
Time's not important, the process name was what I'm after, thanks. I thought it might be fetchmail, but wanted to be sure. When I have some time I'll see if there's anything common among the many google results for that error in fetchmail, or a way to access more detailed information about what choked it.

[eluser]Ahmed Nuaman[/eluser]
Thanks man. I look forward to your reply. Sorry if I was a pain.

[eluser]Derek Jones[/eluser]
What version of fetchmail is installed, Ahmed? If you look around with Google, you can find various patches to prevent this error, as it appears to be fairly widespread.