Re: muchsync & sent mail
Hi, On Wed, Jan 26 2022, Brian May wrote: > Hello, > > I have noticed that my muchsync setup doesn't appear to sync my > ~/Maildir/sent folder. > This does not happen to me, the sent folder is synced just like any other. Even drafts do. Martin ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding
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-le...@notmuchmail.org
Emacs notmuch extracts text attachments as if they had Windows (CRLF) encoding
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 1633684554.29424_1.virgil.gz Description: 1633684554.29424_1.virgil.gz ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: backing up tags
Hello, On Fri, Mar 26 2021, Alan Schmitt wrote: > Hello, > > I do not include my (huge, more than 5GB) notmuch database in backups, > as it can be recreated from the email files… with one exception: tags. > So I’m wondering if there is a way to backup these tags (and only the > tags) with the hope it would be much smaller. Do you know ways to do it? > I believe that "notmuch dump" is supposed to do exactly that. At least I hope so because that is how I am backing up my email tags :-) Martin ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Tag duplicate messages with notmuch insert
Hi, On Mon, Oct 15 2018, David Bremner wrote: > David Bremner writes: > >> Thomas Schneider writes: >> >>> From notmuch-insert(1): >>> If the new message is a duplicate of an existing message in the database (it has same Message-ID), it will be added to the maildir folder and notmuch database, but the tags will not be changed. >>> >>> It might however be desired to apply the new tags even when the message >>> is a duplicate. How complicated would it be to implement this? >> >> It doesn't look especially hard, assuming the obvious small change to >> add_file() in notmuch-insert.c works. I didn't look at the equivalent >> code path in notmuch-new.c. Presumably you'd want them both to behave >> the same way. > > Just to be clear, I wasn't commenting on whether it was the right thing > to do or not, just whether it would be hard. It seems likely to be > annoying to at least some people to have messages show up as unread > again (or whatever the tags are) when new copies arrive. > [If enabled,] such messages should get only the +new tag, not the +unread tag. Or whatever the user configured, of course. Martin ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: tell me how to do this right (mail sent to lists)
Hi, I am a notmuch newbie and do not use afew (but have my own post-new hook script), but... On Wed, Oct 10 2018, Jeff Templon wrote: > Hi David, all: > > David Bremner writes: > >> The tag is not associated with the file in Sent, it is associated >> with the message-id. > > I guess I didn't make myself clear enough, again. I didn't mean that > the tag is associated with the file. What I am guessing is something > like this: > > for message in new_messages: >if message.id not in database: > process message and determine list of tags > appy those tags to the messageID > > new_messages is the list of files that notmuch had not yet seen. ...I don't think the above is entirely accurate. IIUC, what happens is that when notmuch sees a message for the first time during "notmuch new", it simply and only applies the tags specified in the tags entry of [new] section in .notmuch-config file to them - the default I believe is "unread;inbox;new". Then the post-hook is executed, which in your case I presume runs afew somehow, and typically that hook goes over all messages with the tag new, process them in an arbitrary way, sometimes adding further tags according to the contents, and eventually drops the new tag. I guess a potential problem is that notmuch sees the message the first time when you send it and it adds the new tag and post-hook processes the outgoing version. When it arrives back, I believe notmuch does not apply the new tag to it anymore. This means that post-hook does not get to process the incoming version, which might be a problem if you want to see stuff added by a remote party, for example when you want to grep the file and look for Sender header in order to mark it as coming from a particular mailing list. That is the reason I do not attempt this in my post-hook and rely on notmuch "tag:new AND to:mailinglist@address" search which is not really precise but at least it should be probably faster. Perhaps it would be a good idea to split the tags entry in [new] section into two, one for tags added to each previously unknown message-id (default would be unread and inbox) and a new one for each new file (default new)? Let me stress again that I am a newbie and can be completely wrong about anything above, so take it with a grain of salt. Thanks, Martin ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
