Re: Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding

[Martin Jambor <mjambor@suse.cz>]

Hi,

On Thu, Oct 14 2021, Tomi Ollila wrote:
> On Wed, Oct 13 2021, Martin Jambor wrote:
>
>> Hi,
>>
>> I have stumbled upon strange behavior of emacs-notmuch.  When I extract
>> (some?) plain text attachments into files using notmuch-show-save-part
>> (by pressing ".s"), the file they end up in has Windows encoding of line
>> ends (CRLF) even though both the machine used to send and receive the
>> email are Linux ones.
>>
>> I can reproduce the issue with the attached example email.  Emacs
>> notmuch extracts the attachment into a windows encoding file while mutt
>> or metamail does not.
>>
>> Can anyone else reproduce this behavior?  Any ideas how to fix it?
>
> Are you talking about this attachment in the gzipped email content:
>
>   ---1609908220-525021627-1633684545=:5930
>   Content-Type: text/plain; charset=US-ASCII; name=status
>   Content-Transfer-Encoding: BASE64
>   Content-Description: test
>   Content-Disposition: attachment; filename=status
>
>   U3RhdHVzDQo9PT09PT0NCg0KVGhlIEdDQyBkZXZlbG9wbWVudCBicmFuY2gg
>   ...
>   NTgzMS5odG1sDQo=
>
>   ---1609908220-525021627-1633684545=:5930--
>
> I manually extracted the BASE64 content, it does have the 
> CRLF line endings...
>

Thanks for looking into it.  I guess that explains it then.  Apparently
the behavior of mutt (and possibly other email clients) is to convert
the format to the local one. I did not expect metamail to do that,
though.

Thanks again,

Martin