Last modified: 2011-07-18 02:30:57 UTC
Solution doesnt solve problem - IIS 5.1 smtp: doesn't support /n as end of line valid charakters is \\r\n. see it partially solved: r1=16115&r2=16285">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/UserMailer.php?r1=16115&r2=16285 log from smtp (after this change will show other error): 2006-09-29 01:08:19 127.0.0.1 elf SMTPSVC1 ELF 127.0.0.1 0 MAIL - +FROM:<root@biznet.gotdns.org> 250 47 34 2006-09-29 01:08:19 127.0.0.1 elf SMTPSVC1 ELF 127.0.0.1 0 RCPT - +TO:<wagnerc@wp.pl> 250 26 23 2006-09-29 01:08:19 127.0.0.1 elf SMTPSVC1 ELF 127.0.0.1 0 DATA - <ELFFRaqbC8wSA1XvpFV00000006@elf> 250 116 750 2006-09-29 01:08:19 127.0.0.1 elf SMTPSVC1 ELF 127.0.0.1 0 QUIT - elf 0 52 4 2006-09-29 01:08:19 - OutboundConnectionResponse SMTPSVC1 ELF - 25 - - 220+mx.wp.pl+ESMTP 0 18 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionCommand SMTPSVC1 ELF - 25 EHLO - elf 0 4 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionResponse SMTPSVC1 ELF - 25 - - 250-mx.wp.pl 0 12 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionCommand SMTPSVC1 ELF - 25 MAIL - FROM:<root@biznet.gotdns.org> 0 4 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionResponse SMTPSVC1 ELF - 25 - - 250+ok 0 6 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionCommand SMTPSVC1 ELF - 25 RCPT - TO:<wagnerc@wp.pl> 0 4 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionResponse SMTPSVC1 ELF - 25 - - 250+ok 0 6 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionCommand SMTPSVC1 ELF - 25 DATA - - 0 4 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionResponse SMTPSVC1 ELF - 25 - - 354+go+ahead 0 12 0 2006-09-29 01:08:19 mx.wp.pl OutboundConnectionResponse SMTPSVC1 ELF - 25 - - 551+stray+new+line+detected,+closing+connection 0 47 0 Valid Code should be for Windows SMTP (insteed uniform solution I placed how to replace code - I don't have knowledge of MediaWiki globals) -> see datails on (http://meta.wikimedia.org/wiki/Installing_MediaWiki_on_Windows_XP_-_MediaWiki_1.7.1). Find follow lines wfDebug( "Sending mail via internal mail() function to $dest\n" ); mail( $dest, wfQuotedPrintable( $subject ), $body, $headers); restore_error_handler(); and replace to: wfDebug( "Sending mail via internal mail() function to $dest\n" ); mail( $dest, wfQuotedPrintable( $subject ), str_replace( "\n", "\r\n", $body ), str_replace("\n", "\r\n", $headers )); restore_error_handler(); Usermailer.php -> IIS don't support full RFC recommedation, so next patch is need (remove additional name in e-mail address: Usermailer.php -> Find follow lines (this is already solved 4979): function toString() { if( $this->name != '' ) { $quoted = wfQuotedPrintable( $this->name ); if( strpos( $quoted, '.' ) !== false ) { $quoted = '"' . $quoted . '"'; } return "$quoted <{$this->address}>"; } else { return $this->address; } } End remove condition on use nicknames by commenting out: function toString() { // if( $this->name != '' ) { // $quoted = wfQuotedPrintable( $this->name ); // if( strpos( $quoted, '.' ) !== false ) { // $quoted = '"' . $quoted . '"'; // } // return "$quoted <{$this->address}>"; // } else { return $this->address; // } }
OK, deep breath and...what's the problem, again, and what does this solve?
Problem is easy unix and windows have different end line characters unix like "\n" but windows "\r\n". I think that wfIsWindows() should be checked if it used for windows detection. Here is solution for using windows smtp delivered with IIS 5.1. So the line: mail( $dest, wfQuotedPrintable( $subject ), $body, $headers ); Should be changed (i.e.): if(wfIsWindows()) { mail( $dest, wfQuotedPrintable( $subject ), str_replace( "\n", "\r\n", $body ), str_replace("\n", "\r\n", headers )); } else { mail( $dest, wfQuotedPrintable( $subject ), $body, $headers ); }
Changing summary to something that actually makes sense. I assume this is another one of those "PHP's mail() implementation under Windows is shit" bugs.
I don't think so that it is Windows, because javax.mail works with the same server without any special settings, may be it is problem with php or mail() ... I am not a fan of 'java' but smtp mails works without any change of my lines of code under JBoss server and IIS mail - same server:)
(In reply to comment #2) > Problem is easy unix and windows have different end line characters unix like "\n" but windows "\r\n". > I think that wfIsWindows() should be checked if it used for windows detection. > > Here is solution for using windows smtp delivered with IIS 5.1. > > So the line: > mail( $dest, wfQuotedPrintable( $subject ), $body, $headers ); > > Should be changed (i.e.): > > if(wfIsWindows()) { > mail( $dest, wfQuotedPrintable( $subject ), str_replace( "\n", "\r\n", $body ), str_replace("\n", "\r\n", headers )); > } > else { > mail( $dest, wfQuotedPrintable( $subject ), $body, $headers ); > } actually it needs a regex to make sure you dont get accidentally \r\r\n on windows which may cause windows xp prof to crash -.-
(In reply to comment #4) > I don't think so that it is Windows, because javax.mail works with the same server > without any special settings, may be it is problem with php or mail() ... > > I am not a fan of 'java' but smtp mails works without any change of my lines of code > under JBoss server and IIS mail - same server:) Confirms what I thought. Even Microsoft couldn't get away with that one, could they? No real need for a regular expression, just replace \r\n with \n, and then \n with \r\n; the first pass will make sure it's all scooped up nice. Not so clean, but quick and dirty, just how we like it at MediaWiki HQ. ;)
Cute clues - the sharp one :) - they impress me Now I know that it is worth to send some bugs with "very dirty patch" - good job in the first move and in the second two ... \n -> \r\n -> security probable \r\n -> \n -> \r\n -> fastest solution (K.I.S.S.) I think that is hard is to hack down SMTP with \r\r\r\n (how ugly must be state machine - this just wait for ".\n" then for "\n") but this know only MS (no open source code.
Is this still an issue?
This looks like it was a PHP or other upstream bug, that hasn't been confirmed to still exist since October 2008. Since there are no recent reports of problems, closing as presumably fixed.
