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)

Reply via email to