Hello John.
JHolder wrote in
<[email protected]>:
|First of all, thank you for s-mailx, it has been a tool that I have
|relied on for some time whenever I need SMTP on a server without an MTA.
A lot remains to do, but thank you.
|Recently, I have run into a problem where CSV files with CRLF line
|endings are getting mangled and arrive at the the recipient with the
|0x0D, 0x0A changed to three 0x0A characters. I thought the easiest way
|to solve this would be to force the attachments to base64, but I have
|not been able to find the correct settings to make this happen.
|
|I have experimented with -X mimetype, and I can change the mimetype of
|the attachment, but I cannot get the attachment to base64. I thought
|perhaps -S sendcharsets would help, but no luck in any of my testing.
|
|Could anyone point me in the direction I need to look to figure this out?
This is an interesting point, John.
It is actually feature, and we take quite some steps to get there!
It seems your files are plain US-ASCII with relatively short lines
and nothing else in sight which would enforce us to encode the
files.
For text files on UNIX/POSIX the line endings are \n (U+000A,
LF), on elder MacOS \r (U+000D, CR), and on MS-DOS and
follow-ups, some (most) text-based network protocols and whatnot
\r\n.
On MS- i think the file interface for ISO C and other
programming languages allows specifying whether the file is
O_BINARY or O_TEXT, and the C library and others would
automatically convert \n to \r\n as necessary in O_TEXT mode
(depending on mount point even says the [1] that i searched for
this answer).
[1] https://cygwin.com/pipermail/cygwin/2019-February/240094.html
We are a UNIX/POSIX program, and on UNIX the line ending is \n,
and no conversion takes place. (There is no separation in
between text and binary files, it is just that text files happen
to have lines separated by \n, this is why POSIX has the notion
of a "Printable File", too.)
So we classify the file, it seems to be a text-file which, to its
own disappointment, has \r\n line endings, which we explicitly
deal with in order to make these files available on UNIX without
the need for an additional program (there were dos2unix and
unix2dos in the past, i think tr(1) would do for this, too).
[if(c == '\n'){}
...]
/* A bit hairy is handling of \r=\x0D=CR.
* RFC 2045, 6.7:
* Control characters other than TAB, or CR and LF as parts of CRLF
* pairs, must not appear. \r alone does not force _CTRLCHAR below since
* we cannot peek the next character. Thus right here, inspect the last
* seen character for if its \r and set _CTRLCHAR in a delayed fashion */
/*else*/ if(lastc == '\r')
mtc |= a_MT_C_CTRLCHAR;
So we _would_ assume the file is binary if there would be a sole
\r somewhere, or whatever else, but not as part of \r\n.
So short answer: we cannot yet. In fact the predecessor Heirloom
mailx did not normalize line endings if i recall correctly, ...
Yes, i changed this with (Rewrite file-content classification..,
2013-01-02, commit cacee1b57027a8fff), stating among others:
- Be more compliant to what the RFC states. It seems that
the former implementation was somewhat based upon mutt(1)
code, but that doesn't seem to be very compliant either?
Anyway, don't care no more for \f, but be aware of the
explicitly forbidden \r's that are not part of a CRLF.
In general handling of content tries to go for
text/quoted-printable not binary/base64, i.e., not treating
rather regular control characters as an indicator to use
the latter. I.e., if file(1)/libmagic(3) is the opinion
something is text it doesn't seem useful to treat it as
binary.
As a nice side effect $-DOS files (those which use the
terminal newline sequence in text files) are no longer
binary data but are just treated the very way the RFC
requires. (Though the quoted-printable layer as of NOW is
buggy and creates "buggy output" just as mutt(1) does.
This will be fixed before the release, however.)
Well, hmhm. What a mess.
Anyhow: what you want is the _explicit_ possibility to specify
that an attachment shall be treated as binary, no matter what?
Thanks for the suggestion, i will try to find a solution for it!
Until then there is not much you can do, unfortunately, except
maybe packing these files with ZIP or anything else that is
understood on the Windows receiver side? (If you would have
control of the receiver side, you could install a MIME handler for
CSV, and automatically convert POSIX to terminal newline
sequences.)
Ciao John!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
