Steffen,
That is great news, I look forward to the release. In the meantime, I have been using unix style line endings for those that can take it.
Thank you, John On 10/3/22 15:59, Steffen Nurpmeso wrote:
Hello John. Steffen Nurpmeso wrote in <20220929164300.bw8t5%[email protected]>: |JHolder wrote in | <[email protected]>: ... ||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 today have implemented such a thing, but it will require v14.10 (_hopefully_ around christmas). base64 can be enforced by prefixing ! to a character set specification: -a file[=[!]input-charset[#[!]output-charset]], --attach=.. (Send mode) Attach file, subject to tilde expansion (see Filename transformations and folder). In Compose mode the COMMAND ESCAPES ~@ and especially the scriptable ~^ provide alternatives for attaching files. If file is not accessible but contains an equal-sign `=' a character set specification is split off. If only an input one is given it is fixated and no conversion is applied; an empty, or the special string hyphen-minus `-' means ttycharset. If an output one is given the conversion is performed on-the-fly, not considering file type nor content; however, empty string or hyphen-minus `-' enforce the default Character sets conversion (`-a file', `-a file=#', and `-a file=-#-' are identical), later applied after MIME- classifying file (HTML mail and MIME attachments, The mime.types files). Without `,+iconv,' in features only this mode is available. The character set names may be prefixed with exclamation mark `!' to enforce base64 mime-encoding of the attachment. ... || ||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! This applies only to the saving side it seems. When writing a test for the new feature i recognized that storing the attachment in the message does, actually, not convert the terminal newline sequence to the UNIX/POSIX one, i falsely remembered this. (But, it is rather by accident.) When we then write the part out, however, we normalize. |Thanks for the suggestion, i will try to find a solution for it! Even more cryptic magic. |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?[.] I have to think about what more can or should be done. But the above will do it, regardless the outcome. You have been credited with the above mail, please complain if this is not a good thing to do. Thanks for the suggestion, 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)
