View Issue Details

IDProjectCategoryView StatusLast Update
0001916mantisbtemailpublic2002-05-26 12:40
Reportergstarrett Assigned Toprescience  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformIIS4 / PHP 4.1.2OSNT 4 SP6a 
Product Version0.17.1 
Summary0001916: 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>
451 See <a href="http://pobox.com/~djb/docs/smtplf.html">http://pobox.com/~djb/docs/smtplf.html</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
< $mail->Body = "n".$t_message;

      $mail->Body    = make_lf_crlf( "n".$t_message );

557c557
< $result = mail( $t_recipient, $t_subject, $t_message, $t_headers );

      $result = mail( make_lf_crlf( $t_recipient ), make_lf_crlf( $t_subject ), make_lf_crlf( $t_message ), make_lf_crlf( $t_headers ) );

566a567,571
}

--------------------

clean up LF to CRLF

function make_lf_crlf( $p_my_string ) {
return str_replace( "rrn", "rn", str_replace( "n", "rn", $p_my_string ));

TagsNo tags attached.

Activities

gstarrett

gstarrett

2002-05-02 12:42

reporter   ~0002423

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.

gstarrett

gstarrett

2002-05-02 22:53

reporter   ~0002427

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"...

prescience

prescience

2002-05-07 19:38

reporter   ~0002474

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?

prescience

prescience

2002-05-07 19:38

reporter   ~0002475

Last edited: 2002-05-07 20:19

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

gstarrett

gstarrett

2002-05-07 20:23

reporter   ~0002477

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?

prescience

prescience

2002-05-07 20:55

reporter   ~0002479

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.

gstarrett

gstarrett

2002-05-07 21:26

reporter   ~0002485

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.

gstarrett

gstarrett

2002-05-07 21:29

reporter   ~0002487

Also-- g_strip_bare_lf is a bit counter-intuitive to what it would be doing. Maybe g_mail_send_crlf would be better?

gstarrett

gstarrett

2002-05-07 21:46

reporter   ~0002492

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).

prescience

prescience

2002-05-08 19:03

reporter   ~0002521

Converted over to g_mail_send_crlf witha default of ON.

jlatour

jlatour

2002-05-19 16:48

reporter   ~0002601

Is this still an issue?

prescience

prescience

2002-05-19 18:48

reporter   ~0002602

Closing.