Page 1 of 1
End of line characters
Posted: Wed Sep 12, 2007 4:33 pm
by chuckl
In an earlier post mention was made of the fact that 'sendmail -t' expects "\n" end of line characters, while SMTP wants "\r\n". Nativemail is not included in the survey, but early research tends to suggest "\r\n".
However the Op Sys wars mandate that macs like"\r", Windows "\r\n", and Unix/Linux votes for "\n".
This would seem to have all the makings of a nasty turf war, as what has precedence?
Posted: Wed Sep 12, 2007 5:20 pm
by Christopher
Twenty years ago it did. Now programmers just deal with it.
Re: End of line characters
Posted: Wed Sep 12, 2007 5:24 pm
by superdezign
chuckl wrote:This would seem to have all the makings of a nasty turf war, as what has precedence?
Most things that operate cross-platform are programmed to convert according to the platform.
Posted: Thu Sep 13, 2007 3:59 am
by Chris Corbyn
Forget \r ever existed by itself on the macs. Newer macs are just UNIX based with \n line endings if you're using sendmail.
SMTP requires \r\n as per the specification.
The NativeMail connection does the conversion for you so you needn't worry about it. The reason sendmail -t in Swift requires that you deal with the EOL yourself is basically because it's not finished. It was experimental and I don't really want people to start using it in production code because it really will have bugs in it (it's not tested). "sendmail -bs" is where it's at

Posted: Thu Sep 13, 2007 4:20 am
by chuckl
Thanks for the responses. There is a lot of conflicting info out there on the subject which basically all ends up in the circular argument/conundrum I posted.
i.e. When we say SMTP uses crlf, do we mean that is cast in stone, or that it varies from opsys to opsys? When we say that the infamous sendmail -t uses lf only, is that only on Unix/Linux boxen, or if I have a sendmail implementation on a Windows box, will that immediately change to crlf, or a Mac to cr?
In a rephrase, is it correct to use the PHP_EOL constant, or hard code.
On the NativeMail front, it is interesting that changing the eol with fixLE does alter the output in a curious way.
Using "\n" or lf, the mime headers appear like this:
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Setting to "\r\n" reverts to the correct
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
i.e. With only lf, an extra line is injected, and the bolding is lost.