Re: Double Spacing in Mails from Sendmail
This WebDNA talk-list message is from 2002
It keeps the original formatting.
numero = 42862
interpreted = N
texte = Scott Anderson wrote: > Looks like a [sendmail] bug (but only on the Windows platform)By which you mean you are going to fix it? Soon? I've been complaining about this for literally years. And it didn't always misbehave like this...> > The [sendmail] context opens the email file in 'text' mode, so there is a > translation taking place where linefeed characters
are replaced with > carriage-return linefeed pairs . The header lines work fine because > [sendmail] explicitly inserts only a at the end of each header (which > is then translated to pair by the fprintf() call). But the body is > written out as is. So if the body contains a sequence, this > becomes a sequence during the fwrite() call.OK, that't just plain wrong! Your code (i.e. WebCat) has no business messing with the EOL characters, ever, on platforms that do not need it, like Windows. I realize that WebCat started as a Mac-only package, but come on, that was 7 years ago! Out of the box, with no mucking about by anyone, Windows EOL characters will produce RFC compliant e-mails.The RFC's require CR/LF in the header and do not require any special EOL handling in the body. All compliant MTA's I am aware of will take CR or LF or CR/LF as an EOL character when found in the body. Any special handling you perform should only be directed at the header lines.Here's what you should be doing, and it will work for all platforms out of the box:1) For header lines only, strip whatever EOL character(s) you find and always output CR/LF pairs;2) Do not perform any EOL modifications to body text.> > A work around would be to make sure the text within your [sendmail] contexts > tags contain UNIX style line endings. > I'll test this, but I believe that we tested this ages ago and it did not fix it. I believe you are not understanding text mode correctly under Win*, since that is supposed to treat CR/LF as \n and automatically upgrade CR => \n for you. On output, text mode under Windows will always give you CR/LF, so if you are doing anything different in the fprint(), you are causing the problem yourself. I'll bet dollars to donuts you have a \r in the fprint().John-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
Scott Anderson wrote: > Looks like a [sendmail] bug (but only on the Windows platform)By which you mean you are going to fix it? Soon? I've been complaining about this for literally years. And it didn't always misbehave like this...> > The [sendmail] context opens the email file in 'text' mode, so there is a > translation taking place where linefeed characters are replaced with > carriage-return linefeed pairs . The header lines work fine because > [sendmail] explicitly inserts only a at the end of each header (which > is then translated to pair by the fprintf() call). But the body is > written out as is. So if the body contains a sequence, this > becomes a sequence during the fwrite() call.OK, that't just plain wrong! Your code (i.e. WebCat) has no business messing with the EOL characters, ever, on platforms that do not need it, like Windows. I realize that WebCat started as a Mac-only package, but come on, that was 7 years ago! Out of the box, with no mucking about by anyone, Windows EOL characters will produce RFC compliant e-mails.The RFC's require CR/LF in the header and do not require any special EOL handling in the body. All compliant MTA's I am aware of will take CR or LF or CR/LF as an EOL character when found in the body. Any special handling you perform should only be directed at the header lines.Here's what you should be doing, and it will work for all platforms out of the box:1) For header lines only, strip whatever EOL character(s) you find and always output CR/LF pairs;2) Do not perform any EOL modifications to body text.> > A work around would be to make sure the text within your [sendmail] contexts > tags contain UNIX style line endings. > I'll test this, but I believe that we tested this ages ago and it did not fix it. I believe you are not understanding text mode correctly under Win*, since that is supposed to treat CR/LF as \n and automatically upgrade CR => \n for you. On output, text mode under Windows will always give you CR/LF, so if you are doing anything different in the fprint(), you are causing the problem yourself. I'll bet dollars to donuts you have a \r in the fprint().John-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
John Peacock
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Security Issue (1997)
Date Formats (1997)
How to include weather (2000)
[SearchString] usage (1997)
WebCatalog Features (1997)
Okay, I give up... (1999)
WCS Newbie question (1997)
Help with Shipping Costs (1997)
How To question on setting up downloads (1997)
Shopping Cart variation... (1997)
Displaying backgrounds (1999)
Accented chars and emailer (1998)
RE: ShowNext Command (1997)
RAM variables (1997)
Same DB Same Time (2004)
Separate SSL Server (1997)
re:check boxes (1997)
RE: New WebCatalog Version !!! (1997)
Code validation (was: problem using...) (2004)
Wanted: More Math Functions (or, Can You Solve This?) (1997)