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?
End of line characters
Moderators: Chris Corbyn, General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Re: End of line characters
Most things that operate cross-platform are programmed to convert according to the platform.chuckl wrote:This would seem to have all the makings of a nasty turf war, as what has precedence?
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
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
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
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.
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.