Blat 2.40 does not support sending files without CRs

[rossta7]

If I try to send a text file that has only LFs, either in the message
body, or as a text attachment, I get:

connection::put_data() unexpected error from send(): 10054

If I convert the file to a DOS file, using Cygwin's unix2dos command,
blat works normally.

The SMTP server is qmail 1.0.3.

Feedback anyone?

[Chip]

Post by rossta7
If I try to send a text file that has only LFs, either in the message
connection::put_data() unexpected error from send(): 10054
If I convert the file to a DOS file, using Cygwin's unix2dos command,
blat works normally.
The SMTP server is qmail 1.0.3.
Feedback anyone?

Check with a different server package. I send a 686K file as my message
body without CR through AT&T, and it worked just fine. I then sent it again
as a text attachment, again this worked fine, and used "-superdebug -log
blat.log". Granted, I am on DSL so my uplink speed is faster than dial-up.
For the third attempt, which worked, I sent the blat.log created from the
second attempt along with the original 600K file as a text attachment. The
total size of these two files exceeded 4.3 MB, but Blat was able to send all
messages as expected.

Chip

[Qe'van, Bard of Nor]

Quoting rossta7..

Post by rossta7
If I try to send a text file that has only LFs, either in the message
connection::put_data() unexpected error from send(): 10054
If I convert the file to a DOS file, using Cygwin's unix2dos command,
blat works normally.
The SMTP server is qmail 1.0.3.
Feedback anyone?

Well, imagine that in a DOS/Windows command line utility. ;)
--
Qe'van, Bard of Nor
http://qevan.home.comcast.net/poetry/
http://texasfilk.home.comcast.net/

... 'Danny...why are you looking at me like that?'- MaryD


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12 GIT$/L/MU d s++:+ a+ C++$
U++++$ P++$ L++ E-- W++ N++ o-- K- w$
O- M V PS+ PE Y+ PGP t+ 5+@ X R tv+ b++
DI+ D G e++ h---- r+++ y++++>*
------END GEEK CODE BLOCK------

[ykai]

Post by rossta7
If I try to send a text file that has only LFs, either in the message
connection::put_data() unexpected error from send(): 10054
If I convert the file to a DOS file, using Cygwin's unix2dos command,
blat works normally.
The SMTP server is qmail 1.0.3.
Feedback anyone?

RFC 2822 - Internet Message Format
(http://www.faqs.org/rfcs/rfc2822.html)
states (Ch. 2.1, 2.1.1) that
a) a message consists of "lines", which is 7Bit-ASCII separated by CRLF
b) a line MUST not be longer then 998 characters
and explains
,---
|The 998 character limit is due to limitations in many implementations
|which send, receive, or store Internet Message Format messages that
|simply cannot handle more than 998 characters on a line. Receiving
|implementations would do well to handle an arbitrarily large number
|of characters in a line for robustness sake. However, there are so
|many implementations which (in compliance with the transport
|requirements of [RFC2821]) do not accept messages containing more
|than 1000 character including the CR and LF per line, it is important
|for implementations not to create such messages.
`---
A file like described is for the sake of RFC2822 only one long line
(since single LF don't count as line separators), so falls under this
limit discussion when surpassing a size greater than 998 bytes.

Most mailers may be tolerant "for robustness sake" though.

[Ross Smith]

Post by ykai

Post by rossta7
If I try to send a text file that has only LFs, either in the message
connection::put_data() unexpected error from send(): 10054
If I convert the file to a DOS file, using Cygwin's unix2dos command,
blat works normally.
The SMTP server is qmail 1.0.3.
Feedback anyone?

RFC 2822 - Internet Message Format
(http://www.faqs.org/rfcs/rfc2822.html)
states (Ch. 2.1, 2.1.1) that
a) a message consists of "lines", which is 7Bit-ASCII separated by CRLF
b) a line MUST not be longer then 998 characters
and explains
,---
|The 998 character limit is due to limitations in many implementations
|which send, receive, or store Internet Message Format messages that
|simply cannot handle more than 998 characters on a line. Receiving
|implementations would do well to handle an arbitrarily large number
|of characters in a line for robustness sake. However, there are so
|many implementations which (in compliance with the transport
|requirements of [RFC2821]) do not accept messages containing more
|than 1000 character including the CR and LF per line, it is important
|for implementations not to create such messages.
`---
A file like described is for the sake of RFC2822 only one long line
(since single LF don't count as line separators), so falls under this
limit discussion when surpassing a size greater than 998 bytes.
Most mailers may be tolerant "for robustness sake" though.

So, shouldn't blat add the missing CRs (or LFs) to conform to this RFC, given that qmail and others are not forgiving?

At the very least, if blat fails, it could provide a more helpful message than

connection::put_data() unexpected error from send(): 10054

say:

connection::put_data() unexpected error from send(): 10054
This may be due to missing LFs in the file your_file.txt.

-Ross

[Edward Goulet]

Post by ykai
RFC 2822 - Internet Message Format
(http://www.faqs.org/rfcs/rfc2822.html)
states (Ch. 2.1, 2.1.1) that
a) a message consists of "lines", which is 7Bit-ASCII separated by CRLF
b) a line MUST not be longer then 998 characters
and explains
,---
|The 998 character limit is due to limitations in many implementations
|which send, receive, or store Internet Message Format messages that
|simply cannot handle more than 998 characters on a line. Receiving
|implementations would do well to handle an arbitrarily large number
|of characters in a line for robustness sake. However, there are so
|many implementations which (in compliance with the transport
|requirements of [RFC2821]) do not accept messages containing more
|than 1000 character including the CR and LF per line, it is important
|for implementations not to create such messages.
`---
A file like described is for the sake of RFC2822 only one long line
(since single LF don't count as line separators), so falls under this
limit discussion when surpassing a size greater than 998 bytes.
Most mailers may be tolerant "for robustness sake" though.

So, shouldn't blat add the missing CRs (or LFs) to conform to this RFC,
given that qmail and others are not forgiving?

At the very least, if blat fails, it could provide a more helpful message
than

connection::put_data() unexpected error from send(): 10054

say:

connection::put_data() unexpected error from send(): 10054
This may be due to missing LFs in the file your_file.txt.

-Ross
As Grampa might say, you're putting the cart before the horse ... the RFC is
asking that you not create messages without CRLF breaks, which is what
happens when you feed blat the incorrect type of text file. blat just does
what you tell it to. qmail probably works because it had to, running on so
many *nix boxes that non-RFC2822-conformant files were the norm. "qmail and
others" are the forgiving ones, in this case, not blat. Make sense? (heh heh
be nice to Chip and Tim and better error messages will come)

[Tim Musson]

Hey Edward,

Post by Ross Smith
At the very least, if blat fails, it could provide a more helpful message

EG> (heh heh be nice to Chip and Tim and better error messages will
EG> come)

I would love to see better error reporting, the problem is the size of
the task. It is HUGE (sorry for shouting). I don't think Chip or I
really have time to do much about it in the foreseeable future though.
--
Tim Musson
Flying with The Bat! eMail v2.12.00
The generation of random numbers is too important to be left to
chance.
Blat Manager, current version is 2.4, see www.blat.net

[Chip]

Post by Tim Musson
Hey Edward,

Post by Ross Smith
At the very least, if blat fails, it could provide a more helpful message

EG> (heh heh be nice to Chip and Tim and better error messages will
EG> come)
I would love to see better error reporting, the problem is the size of
the task. It is HUGE (sorry for shouting). I don't think Chip or I
really have time to do much about it in the foreseeable future though.

The issue is really all about compatibility with existing installations of
Blat. If I change the error codes, then this will cause problems with
existing scripts and other programs that rely on Blat. What I can do is
provide a name for each possible error, assign it an old number and a new
number, then if anyone needs the old values for compatibility, they can
recompile the program with the old values. For everyone else, they could
download the latest Blat which would use the new numbers. The task itself
is not difficult, just time consuming.

The only error values I cannot change are the Windows socket errors. Those
messages cannot get much clearer because the values could be returned by
Windows for a *lot* of different reasons.

Let's take the current thread and examine this. The error was
"connection::put_data() unexpected error from send(): 10054". What about
this Windows generated value will tell Blat that QMail did not like the text
without carriage returns (0D)? Nothing. This same value could be returned
for many reasons, none of which directly mean that the message could not be
processed by the server because it lacked carriage returns with the line
feeds.

Here's a question for those running *nix. What do your email clients send
for message format? Run ethereal on your machines to capture and examine
the email traffic. Do you see carriage returns in the message body, or just
line feeds? In other words, do your *nix programs convert from *nix format
to DOS/Windows format, or do they expect to send *nix text to another *nix
machine?

Chip

[Corp Library]

Chip,

Some strawman ideas for enhanced error reporting without breaking
existing applications of Blat:

1. Command line option that activates enhanced error reporting services.

Example:

Blat -ex ...

Without the -ex parm, Blat would use "Blat Classic" error codes. With
the -ex parm, Blat would provide extended error codes.

2. Command line option that places enhanced error info in specified
file. This file could be queried by the application calling Blat.

Example:

Blat -eout:blat.err ...

When the -eout:[file] parm is specified (file defaults to blat.err if
not provided), Blat places additional error diagnositic info in the
specified error out file.

Blat Rocks!

Malcolm

[Tim Musson]

Hey Corp,

On Saturday, February 5, 2005 at 9:27:35 AM you wrote

CL> Without the -ex parm, Blat would use "Blat Classic" error codes.
CL> With the -ex parm, Blat would provide extended error codes.

If we are updating the error reporting in Blat, I think it should be
optional to use the old error codes (default to using the new one.

CL> When the -eout:[file] parm is specified (file defaults to blat.err
CL> if not provided), Blat places additional error diagnositic info in
CL> the specified error out file.

How is this different from the current -log and -debug, etc?
--
Tim Musson
Flying with The Bat! eMail v2.12.00
Earth is full. Go home.
Blat Manager, current version is 2.4, see www.blat.net

[Corp Library]

Dear List,

While we're on the topic of discussing ways to make Blat easier to use
(setup, tutorials, documentation, error reporting), how about this
strawman idea:

-support parm

The -support parm would echo the following to a file called blat.support
(or blat.txt if this file name is not already used for documentation). A
bonus would be an additional option of having the contents of this file
automatically copied to the Windows clipboard as well.

1. Blat version info, operating system info, and (ideally) user status
(guest, poweruser, admin). The user status would help diagnosis problems
where users don't have the appropriate rights to update the registry,
etc.

2. User's command line with sensitive info (account name, passwords,
etc) replaced with X's

3. Registry settings (if not supplied in command line and referenced by
Blat in attempting to send an email) with sensitive info replaced with
X's

4. The tail end (last N lines) of one of Blat's debug mode (superdebug?)
output

After creating the file blat.support, Blat would echo instructions to
STDOUT on how to send the contents of this file to the Yahoo Blat list.
This would include URL to register for Blat list, and instructions on
copying and pasting the contents of Blat.support (blat.txt) to an email
asking for help.

Having all the above info in a single, consistent format would make it
easier (and safer) for this group to support one another and certainly
less frustrating for users requesting help.

Thoughts?

Malcolm

[Tim Musson]

Hey Corp,

On Saturday, February 5, 2005 at 9:38:57 AM you wrote


CL> Dear List,

CL> While we're on the topic of discussing ways to make Blat easier to use
CL> (setup, tutorials, documentation, error reporting), how about this
CL> strawman idea:

CL> -support parm

CL> The -support parm would echo the following to a file called blat.support
CL> (or blat.txt if this file name is not already used for documentation). A
CL> bonus would be an additional option of having the contents of this file
CL> automatically copied to the Windows clipboard as well.

CL> 1. Blat version info, operating system info, and (ideally) user status
CL> (guest, poweruser, admin). The user status would help diagnosis problems
CL> where users don't have the appropriate rights to update the registry,
CL> etc.

CL> 2. User's command line with sensitive info (account name, passwords,
CL> etc) replaced with X's

CL> 3. Registry settings (if not supplied in command line and referenced by
CL> Blat in attempting to send an email) with sensitive info replaced with
CL> X's

CL> 4. The tail end (last N lines) of one of Blat's debug mode (superdebug?)
CL> output

CL> After creating the file blat.support, Blat would echo instructions to
CL> STDOUT on how to send the contents of this file to the Yahoo Blat list.
CL> This would include URL to register for Blat list, and instructions on
CL> copying and pasting the contents of Blat.support (blat.txt) to an email
CL> asking for help.

CL> Having all the above info in a single, consistent format would make it
CL> easier (and safer) for this group to support one another and certainly
CL> less frustrating for users requesting help.

CL> Thoughts?

Interesting idea, but I don't think it belongs built into Blat. Almost
all that could be generated with a batch file...
--
Tim Musson
Flying with The Bat! eMail v2.12.00
What garlic is to salad, insanity is to art.
Blat Manager, current version is 2.4, see www.blat.net

[Ross Smith]

Post by Edward Goulet
As Grampa might say, you're putting the cart before the horse ... the RFC is
asking that you not create messages without CRLF breaks, which is what
happens when you feed blat the incorrect type of text file. blat just does

How is a common user supposed to know the file was "incorrect", if blat doesn't inform them?

Post by Edward Goulet
what you tell it to. qmail probably works because it had to, running on so
many *nix boxes that non-RFC2822-conformant files were the norm. "qmail and
others" are the forgiving ones, in this case, not blat. Make sense? (heh heh
be nice to Chip and Tim and better error messages will come)

[Tim Musson]

Hey Ross,

On Thursday, February 3, 2005 at 9:42:32 PM you wrote

RS> So, shouldn't blat add the missing CRs (or LFs) to conform to
RS> this RFC,

I don't see why it would be Blat's job to make sure the input text is
windows format on a windows machine. Do other eMail clients do this
for you? Blat is a tool to send eMail, not parse text.
--
Tim Musson
Flying with The Bat! eMail v2.12.00
I live in my own little world. But it's OK. They know me here.
Blat Manager, current version is 2.4, see www.blat.net

[Ross Smith]

Post by Tim Musson
Hey Ross,
RS> So, shouldn't blat add the missing CRs (or LFs) to conform to
RS> this RFC,
I don't see why it would be Blat's job to make sure the input text is
windows format on a windows machine.

It seems to me its blat's job to format the email message in whatever way it needs to be formatted to successfully send the email.
It already does uuencode, and mime, so what's the big deal?

I even see \n to \r\n translation already in the source code.

Post by Tim Musson
Do other eMail clients do this for you?

Yes. A simple program, called 'email' does this very nicely. (http://email.cleancode.org)

Post by Tim Musson
Blat is a tool to send eMail, not parse text.

Parse text? I'm not suggesting it do that. All I am suggesting, is that if qmail requires CRs in the input, that blat provide them
(or at least tell the user the reason it failed is the input does not contain them). What do that have to do with parsing text?

I've downloaded the source for blat 2.40 and began to look at providing a patch to do this. Unfortunately, it appears the code makes
the assumption that the input stream will not grow, so the solution is non-trivial.

If I take the time to develop a patch, will you accept it?

-Ross

[L.Willms]

Post by Ross Smith
It seems to me its blat's job to format the email message in whatever

way it needs to be formatted to successfully send the email.

Post by Ross Smith
It already does uuencode, and mime, so what's the big deal?
I even see \n to \r\n translation already in the source code.

I'm against that. I do absolutely not want that BLAT messes with the
files I want to send; there might be LF characters which are meant to be
there.

BLAT is a tool for Windows, and under Windows, all textfiles do use
CF/LF as line end marker.

If somebody takes text files from a Unix system to a Windows system,
without converting the file format, then she or he should not rely on
the mailer to fix that.

Yours,
Lüko Willms
-----------------------------------------------
Frankfurt/Main

[Chip]

Post by ykai

Post by rossta7
If I try to send a text file that has only LFs, either in the message
connection::put_data() unexpected error from send(): 10054
If I convert the file to a DOS file, using Cygwin's unix2dos command,
blat works normally.
The SMTP server is qmail 1.0.3.
Feedback anyone?

RFC 2822 - Internet Message Format
(http://www.faqs.org/rfcs/rfc2822.html)
states (Ch. 2.1, 2.1.1) that
a) a message consists of "lines", which is 7Bit-ASCII separated by CRLF
b) a line MUST not be longer then 998 characters
and explains
,---
|The 998 character limit is due to limitations in many implementations
|which send, receive, or store Internet Message Format messages that
|simply cannot handle more than 998 characters on a line. Receiving
|implementations would do well to handle an arbitrarily large number
|of characters in a line for robustness sake. However, there are so
|many implementations which (in compliance with the transport
|requirements of [RFC2821]) do not accept messages containing more
|than 1000 character including the CR and LF per line, it is important
|for implementations not to create such messages.
`---
A file like described is for the sake of RFC2822 only one long line
(since single LF don't count as line separators), so falls under this
limit discussion when surpassing a size greater than 998 bytes.
Most mailers may be tolerant "for robustness sake" though.

Section 2.1 of that same RFC also states:

At the most basic level, a message is a series of characters. A
message that is conformant with this standard is comprised of
characters with values in the range 1 through 127 and interpreted as
US-ASCII characters [ASCII]. For brevity, this document sometimes
refers to this range of characters as simply "US-ASCII characters".

Note: This standard specifies that messages are made up of characters
in the US-ASCII range of 1 through 127. There are other documents,
specifically the MIME document series [RFC2045, RFC2046, RFC2047,
RFC2048, RFC2049], that extend this standard to allow for values
outside of that range. Discussion of those mechanisms is not within
the scope of this standard.

------

Now, if we take the RFC literally, any byte within the user's message that
is not US-ASCII should force Blat to use MIME encoding. As such, each line
within the outgoing message will have an equal sign or =20 near column 72 to
indicate a continuation of the current line, thus it should remove the
problem with missing carriage returns or of sending Unicode "text" files.

At the present time, Blat handles neither Unicode nor non-Windows "standard"
text files very well without the -base64 command line option. I could
modify Blat to examine the input file and make reasonable guesses whether it
needs to be MIME encoded, or have carriage returns added, or even that the
input is Unicode and therefore set the encoding to UTF-8.

Chip

[ykai]

Post by Edward Goulet
As Grampa might say, you're putting the cart before the horse ... the RFC is
asking that you not create messages without CRLF breaks, which is what
happens when you feed blat the incorrect type of text file. blat just does
what you tell it to.

That is the one view of the dilemma. On the other hand blat is checking for a
lot of things on the input already and adjusts the output accordingly.
The extremal position would be trying to make sure that no input whatever can
generate "faulty" output from blat.
I assume (!?) that that is not the foundation of blat development though.
It would be more a case of "trying to make *resonable effort* to prevent input
driven errorneous output from blat". Which would include ignoring issues fully
aware of them, if they are "unlikely", etc. (Just my impression, so from
someone not involved in actually making changes to blat.)

Post by Edward Goulet
qmail probably works because it had to, running on so
many *nix boxes that non-RFC2822-conformant files were the norm. "qmail and
others" are the forgiving ones, in this case, not blat. Make sense?

Sorry, you lost me there. What is qmail "forgiving" here? My impression was
that "forgiving" would be to process on longer lines length than 998, which
seems not to happen here?!

[Edward Goulet]

Post by ykai

Post by Edward Goulet
qmail probably works because it had to, running on so
many *nix boxes that non-RFC2822-conformant files were the norm. "qmail and
others" are the forgiving ones, in this case, not blat. Make sense?

Sorry, you lost me there. What is qmail "forgiving" here? My impression was
that "forgiving" would be to process on longer lines length than 998, which
seems not to happen here?!

qmail does process correctly with non-RFC2822-conformant input data, it does
the right thing even when presented the bad input data. The norm for Unix
text file is line termination via LF, the norm for DOS text file is line
termination via CR/LF. Just so happens that RFC2822 also is based on line
termination via CR/LF, which explains why (whoever started this thread? 8^D
could workaround blat by unix2dosing the text file....
ok I've beat the horse dead now... ha ha now somebody give blat a Mac text
file with CRs for line termination!

[Tim Musson]

Hey Edward,

On Friday, February 4, 2005 at 11:19:50 AM you wrote

EG> ok I've beat the horse dead now... ha ha now somebody give blat a
EG> Mac text file with CRs for line termination!

LOL
--
Tim Musson
Flying with The Bat! eMail v2.12.00
I can send email, but I can't receive it! What do I do?
Blat Manager, current version is 2.4, see www.blat.net

[Ross Smith]

Post by Edward Goulet
qmail does process correctly with non-RFC2822-conformant input data, it does
the right thing even when presented the bad input data. The norm for Unix
text file is line termination via LF, the norm for DOS text file is line
termination via CR/LF. Just so happens that RFC2822 also is based on line
termination via CR/LF, which explains why (whoever started this thread? 8^D
could workaround blat by unix2dosing the text file....

Well, Cygwin's unix2dos is broken. It only looks at the first part of the file to determine if it needs converting.

Besides, how is a common user supposed to know this, let alone find a non-broken unix2dos?

Post by Edward Goulet
ok I've beat the horse dead now... ha ha now somebody give blat a Mac text
file with CRs for line termination!

[Chip]

<snipped>

Post by Ross Smith
Well, Cygwin's unix2dos is broken. It only looks at the first part of the
file to determine if it needs converting.

I have a copy of unix2dos and dos2unix from the 80s, not part of Cygwin, and
these are both working just fine.

Post by Ross Smith
Besides, how is a common user supposed to know this, let alone find a non-broken unix2dos?

A common user will have carriage returns with their line feeds, so this is
not an issue. The complaint is from an uncommon user, someone dabbling with
*nix on Windows.

Chip

[Ross Smith]

Post by Chip
I have a copy of unix2dos and dos2unix from the 80s, not part of Cygwin, and
these are both working just fine.

Well, Cygwin's versions were broken. They just fixed it a few days ago: http://cygwin.com/ml/cygwin-announce/2005-02/msg00002.html.

Post by Chip
A common user will have carriage returns with their line feeds, so this is
not an issue. The complaint is from an uncommon user, someone dabbling with
*nix on Windows.

I mean common, as in non-technical. A common user can receive files from a variety of sources, including from other people who may
use Cygwin, Interix, MKS, Linux, BSD, etc.

They don't know and don't care that the file is missing CRs. In fact, they most likely wouldn't know how to determine it.

I just don't understand why you want to put the onus on the user to provide the CRs to blat. Is it that the code is just too
difficult to modify?

-Ross

Post by Chip
Chip

[Chip]

Post by Ross Smith

Post by Chip
I have a copy of unix2dos and dos2unix from the 80s, not part of Cygwin, and
these are both working just fine.

http://cygwin.com/ml/cygwin-announce/2005-02/msg00002.html.

Post by Chip
A common user will have carriage returns with their line feeds, so this is
not an issue. The complaint is from an uncommon user, someone dabbling with
*nix on Windows.

I mean common, as in non-technical. A common user can receive files from
a variety of sources, including from other people who may
use Cygwin, Interix, MKS, Linux, BSD, etc.
They don't know and don't care that the file is missing CRs. In fact, they
most likely wouldn't know how to determine it.
I just don't understand why you want to put the onus on the user to
provide the CRs to blat. Is it that the code is just too
difficult to modify?
-Ross

The change for Blat is trivial. What is going on here is a rationalization
and justification of the proposed change, not an attack on anyone's ideas.
If I make this change, will it cause problems for anyone? Are there any
downsides to this proposed change? So far, we have heard of only one direct
case where this would help someone, we have not heard of any cases where
folks intentionally send messages without carriage returns.

For own testing, I sent a large file to myself without carriage returns, and
AT&T accepted the message just fine. When I read that same message back
using OE, it appeared on my screen as if it contained carriage returns.
Maybe it did, maybe it did not. I can try the same test again and capture
the incoming traffic with ethereal to see if AT&T modifies the message or
passes it through unchanged.

At the moment, I have evidence that at least one SMTP software works
(Maillennium), and one SMTP software that does not (QMail). This is not a
very good sampling to make any judgements on.

Chip

[L.Willms]

Post by Chip
The change for Blat is trivial. What is going on here is a

rationalization

Post by Chip
and justification of the proposed change, not an attack on anyone's ideas.
If I make this change, will it cause problems for anyone? Are there any
downsides to this proposed change?

The downside is that it would go and add a CR before _every_ LF, and
the freestanding LF might have some other meanings which then get lost.
Such a proces is irreversible, other than the enconding in printable or
Base64.

Post by Chip
So far, we have heard of only one direct case where
this would help someone, we have not heard of any cases where
folks intentionally send messages without carriage returns.

The problem is not messages _without_ CRs, but messages with
freestanding LFs.

Post by Chip
I would like to see the ethereal packets from *nix and Mac machines,

to see

Post by Chip
what their mail clients do. This might not answer the question

completely,

Post by Chip
but it would give us more information to make rational decisions.

They do _have_ to convert Unix line terminators to the line
terminators used within the Internet mail system. The system "knows"
that it has to convert the file format for crossing the system border.

A Windows based mailer must assume that the file it is handed over to
send is a Windows text file, and not a Unix text file.

When somebody uses a Unix-like system on top of Windows as a host
system, then this system has to take care that the file format is
changed for use with "pure" Windows tools.

So, I am against an automatic conversion, but maybe one or two more
options might be added to a next version of BLAT:

-lf2crlf .... converts all LF into CR/LF pairs
-cr2crlf .... converts all CR into CR/LF pairs

but only in the primary body part, and only when this is plain
text.


Yours,
Lüko Willms
-----------------------------------------------
Frankfurt/Main

[Ross Smith]

Post by L.Willms
I'm against that. I do absolutely not want that BLAT messes with the
files I want to send; there might be LF characters which are meant to be
there.

For attachments, I agree. For body text, blat has to mess with the data, if it wants to talk to qmail and similar MTA.

Post by L.Willms
BLAT is a tool for Windows, and under Windows, all textfiles do use
CF/LF as line end marker.

If you've ever used Cygwin, or Microsoft's Interix, or MKS's toolkit, or any of the other similar systems, I'm sure would retract
that statement.

Post by L.Willms
If somebody takes text files from a Unix system to a Windows system,
without converting the file format, then she or he should not rely on
the mailer to fix that.

I am not taking text files from anywhere. I am generating them purely in Windows.

[Chip]

Post by Ross Smith

Post by L.Willms
I'm against that. I do absolutely not want that BLAT messes with the
files I want to send; there might be LF characters which are meant to be
there.

For attachments, I agree. For body text, blat has to mess with the data,
if it wants to talk to qmail and similar MTA.

Post by L.Willms
BLAT is a tool for Windows, and under Windows, all textfiles do use
CF/LF as line end marker.

If you've ever used Cygwin, or Microsoft's Interix, or MKS's toolkit, or
any of the other similar systems, I'm sure would retract
that statement.

Post by L.Willms
If somebody takes text files from a Unix system to a Windows system,
without converting the file format, then she or he should not rely on
the mailer to fix that.

I am not taking text files from anywhere. I am generating them purely in Windows.

Is it really Blat's job to ensure a user's file has carriage returns, or is
it merely a convenience to fix user sloppiness?

I would like to see the ethereal packets from *nix and Mac machines, to see
what their mail clients do. This might not answer the question completely,
but it would give us more information to make rational decisions.

Chip