The RFC defines that any kind of boundaries or separators must terminate with a CRLF (\r\n) and not only LF (\n).

The mimemail.inc file uses only LF and therefore the messages are broken on some clients, like MS Outlook for example. Actually messages sent using mimemail doesn't work at all over Outlook (HTML body is ignored and the text version comes truncated).

The proposed patch fix this issue.

Best regards,
Frederico Caldeira Knabben
----
http://www.fckeditor.net
"Support Open Source Software"

Files: 
CommentFileSizeAuthor
#11 mimemail-81707-11.patch1.02 KBsgabe
mimemail.inc_2.patch1.9 KBFredCK

Comments

Attention!

I've reported this error when working on my development pc, a Windows 2003, running Apache and using the IIS SMTP Service. In this case this patch is needed.

Now I've moved the site to a Linux box and had the opposite results... the patch have broken the messages. It seams that even if the RFC talks about CRLF, Linux's SMTP software work with LF only.

So, what would be the final solution for this issue to make it work in both platforms? Maybe retrieve the platform and send the specific line break chars?

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

You are right... the configuration option would be the best so one can precisely control it based on the platform and software used. I vote to go for it.

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.

This is a SMTP server issue. Not a client thing. So, its not the case that some users will receive messages while others don't. If one user receives it, everybody will receive it to, otherwise, no messages to everybody.

The key problem is that important Linux mail systems, like qmail for example, are not RFC compliant, and we can't expect then to be compliant anytime soon. Drupal's code, today, is not RFC compliant only because of this.

Making Drupal RFC compliant means it will not work on the majority of Linux installations. While in a non RFC situation, it will not work on Windows or RFC compliant Linux. This is why making it configurable is so important.

I would not make it that easy to configure, like a admin page. Much probably settings.php is the right place to set it with a specific config variable.

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.

Status:Reviewed & tested by the community» Closed (won't fix)

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.

Status:Closed (won't fix)» Active

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

Title:RFC requires CRLF and not LFAuto-detect appropriate line endings
Priority:Critical» Normal
Status:Active» Fixed
StatusFileSize
new1.02 KB

The attached patch has been committed.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.