With permission of Stephen.. --- Forwarded from Steffen Nurpmeso <[email protected]> --- Date: Tue, 08 Oct 2024 01:27:29 +0200 Message-ID: <20241007232729.HI2KASAF@steffen%sdaoden.eu>
Stephen Isard wrote in <[email protected]>: |On Mon, 7 Oct 2024, Steffen Nurpmeso steffen-at-sdaoden.eu |s-nail| wrote: |... |> Well it is alongside RFC 2045, 6.8: |> |> Care must be taken to use the proper octets for line breaks if base64 |> encoding is applied directly to text material that has not been |> converted to canonical form. In particular, text line breaks must be |> converted into CRLF sequences prior to base64 encoding. The |> important thing to note is that this may be done directly by the |> encoder rather than in a prior canonicalization step in some |> implementations. | |I see. So alpine is obeying this. I won't bother the maintainer then. Well you could ask for "the same thing", but "vice versa". The original line ending is lost. There are plenty of projects which ship with mixed files, ie, native Windows compilation stuff aside Unix one. Whatever. |> The thing *for me* is that *i* want that Unix files remain Unix |> files and DOS files remain DOS files. | |Sounds good to me! | |> But, anyway, and for "now", a DOS file (and it was one, was it?) | |A DOS file? Me? Never. The test file started out on linux | |$ od -c test |0000000 t e s t \n |0000005 | |Alpine was running on linux when I attached it. I got started on this |because I used alpine to send a colleague a copy of your oauth-helper.py |program. He detached it in s-nail with 'w /dev/null' and got an error |message "python3\r not found" when he tried to run it. Interesting that it encodes a plain 7-bit US-ASCII as base64. I tested with the November 2023 mutt i had around, and it saves it like so --AkcUNkjZwO65vk9z Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="mutt.test" test (that was your thing saved by mutt) and so --M8+YkUu9KKfmmIkT Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename=test test ie identical. S-nail (devel) instead does # </dev/null s-nail -:/ -Smta=test -s test -a test -a mutt.test d@a ... --=-=EYiqZYNcNg8-_UlNoqSoaXslx_cP98ghL8ip=-= Content-Disposition: attachment; filename="test" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable test=0D=0A= --=-=EYiqZYNcNg8-_UlNoqSoaXslx_cP98ghL8ip=-= Content-Disposition: attachment; filename="mutt.test" Content-Type: text/plain; charset="us-ascii" test Sigh, too long and dumb MIME boundaries, but, other than that, i think we go into the right direction, only much tooooo slow. And we need an option so users can choose line endings for text files they are saving. (This not in v14.10, i think that hack would be a horrible thing to implement.) So in summary we have - Alpine: - changes line endings to \r\n before encoding, as RFC 2045 tells [in a weak moment, imho] - [normalizes to native newline upon saving??] - mutt: - normalizes newlines to Unix (local?) line ending when attaching - and ditto when saving - s-nail: - takes what it is given and leaves it unchanged when attaching, - and ditto when saving Wonderful. It seems to me that with patience and all the tools available you can get the result that you want. (On Unix.) (v14.10, aka the attachment handling rewrite, choosed not to leave off the Content-Type: field even in the default fallback case: #if 0 XXX explicit is better, and i am in fear of some version of some software not XXX liking that: make it an option?? if(mtcfcp->mtcfc_charset_is_ascii && mtcfcp->mtcfc_ct_is_text_plain){ rv = 0; goto jleave; } #endif) Yes, in parts software frightens me. It is in TODO... Ciao! Argh!! This was not to the list!! Oh please .. let me forward it??? -- End forward <20241007232729.HI2KASAF@steffen%sdaoden.eu> --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)
