Hello John. Steffen Nurpmeso wrote in <20221003205932.wlnsf%[email protected]>: |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=.. ... |||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. ... ||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.
Ok, so what i did is pushing a fix to [master] and all the [stable] series, we unfortunately have to enforce a MIME encoding for all text files which have CRLF line endings until "the magic", long envisioned, MIME layer rewrite will finally happen. This may also be quoted-printable, so the above user enforced base64 request i keep nonetheless. The problem as it happens was introduced by myself, once i tweaked our MBOX code to comply to the standard RFC 4155, which explicitly requires LF line endings. Of course a fully complying code would reencode all parts of a mail message accordingly, dependent upon what the actual target is, user display, MBOX, Maildir, SMTP, etc. Yet this is exactly what the BSD Mail codebase never could. So we have the RFC 5322 Internet Message Format standard which requires CRLF, and RFC 4155 MBOX which requires LF. Since this is a Unix program and we effectively _never_ could truly deal with CRLF, only pass it through when existing (but not only in a message part content, mind you), i went with RFC 4155 since that does usually exactly what UNIX users want, and this software cannot Windows nor old MacOS anyway. With that single exception you ran into. Ciao John -- and thank you for the report! --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)
