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.
RFC 2822 - Internet Message Format
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
|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.