View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001916 | mantisbt | public | 2002-05-02 12:36 | 2002-05-26 12:40 | |
Reporter | gstarrett | Assigned To | prescience | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | IIS4 / PHP 4.1.2 | OS | NT 4 SP6a | ||
Product Version | 0.17.1 | ||||
Summary | 0001916: Sending mail with bare LF character (patch included) | ||||
Description | Sneding email to some servers causes a return message to be dropped in your queue directory (on IIS anyway) as follows: <a href="mailto:first@last.name" target="_new">first@last.name</a> The link refers to LF without a CR. Those are found throughout the core_email_api.php file, as well as in the language files (unverified). My patch (included below) corrects these invalid entries. | ||||
Steps To Reproduce | Send a mail from mantis to a mail server that does not accept bare LF's, for example whichever mail server that handles the forwarding of my .name email account. | ||||
Additional Information | Patch core_email_API.php as follows: 533c533
| ||||
Tags | No tags attached. | ||||
Note that this affects ALL mail going to server that don't accept non-compliant bare LF characters. The patch was generated with a baseline of 0.17.1 code. |
|
I noticed there is quite a bit of dicussion on this topic in the PHP mail() bug tracking user-submitted notes. Apparently weather you need to use \n or \r\n is dependent on the platform you are on and somewhat on the mailer you are using. It's always a "challenge"... |
|
Just to be clear. I assume your patch is the way things should be for the general case? Or should I make this a global option for some users? |
|
I uploaded the patched file to the SF demo bugtracker and it seems to work fine on the SF server sending to mine (sendmail). edited on: 05-07 20:19 |
|
It should probably be a global option--perhaps have that routine check for the global option and return the straight string if it is deactivated. Some of the discussion I saw indicated that some transfer agents will expect only \n and blindly replace \n with \r\n, causing \r\r\n to happen, where others check. I'm sorry I can't be more specific, I don't have much first hand knowledge of a variety of MTA's. Maybe make it a global option that is ON by default because \r\r\n seems (again, from the discussions in the PHP mail() bug tracker) somehow less harmful than bare \n. I suppose if the mail gets there with extra CR's then they will hopefully know to turn it off, right? |
|
Alright. I've added the function and a global called g_strip_bare_lf which is ON by default. We'll see how things shake out. |
|
FYI--I'm getting doubled up line spaces now in the emails the system is sending, looks like it does need to be a global option. I'd forward you a sample message but it looks like \r\n sequences--probably because Outlook (or SOMTHING in the path) converts \r\r\n into \r\n\r\n. |
|
Also-- g_strip_bare_lf is a bit counter-intuitive to what it would be doing. Maybe g_mail_send_crlf would be better? |
|
I did confirm, with a different email client, that I am receiving \r\r\n sequences in those last messages. Outlook express lets you view the actual source, then I copied it over to an editor with HEX view to verify. Looks like your system needs to have that global var set to "off", and I would guess the majority of your users as well since you were ~ 70% Apache / Linux (going off the surveys). |
|
Converted over to g_mail_send_crlf witha default of ON. |
|
Is this still an issue? |
|
Closing. |
|