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

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

[Martin Jambor]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

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?

Thanks a lot,

Martin




[-- Attachment #2: 1633684554.29424_1.virgil.gz --]
[-- Type: application/x-gzip, Size: 1805 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

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

[Tomi Ollila]

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 a lot,
>
> Martin

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

[Martin Jambor]

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