Auto-detect appropriate line endings

I found a note in the php manual here mentioning some platform specific issues. LF is not RFC-2822 compliant, but certain "poor quality Unix mail transfer agents" only accept LF.
One way I could suggest--to fix this is to simply make a checkbox option for "CRLF" or "LF" in the settings area.

Cheers!
Larry

I vote to respect RFC.

Theoretically mails could be sent through many different servers, and it is reasonable to expect them to behave differently. So, it wouldn't be very wise to set options so it will work for a Drupal administrator, and he would be perfectly happy with that - but a majority of other users will not receive anything... And, providing such an option to be selectable, we would give Drupal admins (who are maybe very good in web design and web server administration - or not even that, but less experienced in networking and mail solutions) a chance to easily choose a wrong option not even being aware what the consequences could (or, will) be. Presume everything will work fine for them and they will believe nothing is wrong. Users not receiving anything won't complain siince they will not know something has been sent to them. Too dangerous by my opinion. Or, at least put some very very visible and clearly understandable note about the possible consequences of checking such an option, please!

To support non-standard solutions doesn't sound well to me. Users of such servers should complain and urge administrators to resolve such issues, as they are probably suffering problems already with the other mail.

Sorry, an e-mail usually "travels" through more than just one mail server. At least yours (a sender one) and the destination one are involved (but you can often find traces of even 3 or 4 alltogether in mail header, as some ISPs are throwing it here and there before dispatching it somewhere to wait for a client...). So, the situation could be much different for different users. Or? ;-)

I have 2 qmail servers, probably both patched (I have to admit I don't remember all deatils anymore... got everything through qmailrocks years ago) as I always have to correct all this (but not only in Drupal, also in XRMS etc.) to get mails properly received into Outlook Express.

I agree about a setting not easy to switch by mistake, with a clearly understandable warning, as already stated before.

Hi,

Justed wanted to let know I've experienced the same kind of thing: wrong, different or no styles in the sent e-mails, as well as e-mails being recognized as spam or not received at all.

Posted an issue here:
http://drupal.org/node/120003

Sent out an HTML newsletter and some users reported that they got it in the plain text format. Not sure if it's related to this.

The "some users reported plaintext" was an outlook-specific issue that was closed awhile back.

The LF/CRLF is probably something you'd want to handle with a hook_mail_alter. I'm open to ideas here, but mime mail doesn't always get the last word on how messages are delivered.

Sorry to re-open this topic, but the patch supplied by Allie Micka relates to an earlier version of software, and the current version does not completely fix the problem, neither does the current version satisfactorily address the selection between \r\n and \n

There is already a global constant MAIL_LINE_ENDINGS in the core module (mail.inc) which is set to the appropriate line ending dependent on another global constant $_SERVER['SERVER_SOFTWARE'] which gets its valur from the server being used. There is no need to have check-boxes or other administrator operations as suggested in earlier posts. All you need is in mimemail.inc to replace line 19:
$crlf = variable_get('mimemail_crlf, \n); with
$crlf = MAIL_LINE_ENDINGS;

The body of the message also needs its line endings set. I have not worked out a neat way of doing it, but the following works:
in mimemail.module, after line 156:
if isset(($message['return_path']) && !ini_get('safe_mode'))) { insert
$message['body'] = str_replace("\n", $crlf, $message['body']);

Obviously that needs a bit more work on it but it works

The attached patch has been committed.