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 _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org