Re: Emacs: postponing messages
Brian Sniffenwrites: > I just found this thread from June while looking to resume a draft saved > from another program (dovecot) and which was given the 'draft' tag by > synchronization from Maildir flags. Mark, thanks! > > I *think* all I have to do to deal with other clients accessing the > Maildir through IMAP is to remove 'Message-ID from message-deletable > headers, because other clients may be watching for that---though this > only matters if the draft is resumed and postponed again, rather than > deleted. > > Does that sound right? > > (when draft >(notmuch-message-unquote-some-mml)) > > One comment here: anyone using maildir flag synchronization will have > items with tag:draft but no quoted MML. To help them reasonably > *discuss* quoted MML, even when working from a mix of notmuch and other > MUAs, can this use a distinct tag? For example, tag:quoted-mml? I'm not sure if Mark saw this, as it wasn't connected to the original thread. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Emacs: postponing messages
I just found this thread from June while looking to resume a draft saved from another program (dovecot) and which was given the 'draft' tag by synchronization from Maildir flags. Mark, thanks! I *think* all I have to do to deal with other clients accessing the Maildir through IMAP is to remove 'Message-ID from message-deletable headers, because other clients may be watching for that---though this only matters if the draft is resumed and postponed again, rather than deleted. Does that sound right? (when draft (notmuch-message-unquote-some-mml)) One comment here: anyone using maildir flag synchronization will have items with tag:draft but no quoted MML. To help them reasonably *discuss* quoted MML, even when working from a mix of notmuch and other MUAs, can this use a distinct tag? For example, tag:quoted-mml? Thanks, Brian ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
crypto and draft messages [was: Re: Emacs: postponing messages]
On Thu 2016-06-02 14:21:44 -0400, Mark Walters wrote: > There was some discussion on irc yesterday about a better way of > postponing message when using the emacs frontend. I think getting a > moderately nice interface should be quite easy (see below) but there are > some corner cases on what *should* happen that I would like to resolve > before trying to implement anything. one other corner case worth thinking about here (it can probably be postponed until we have base cases handled, but i wanted to bring it up) is how per-message cryptographic operations (mml-secure-*) interact with drafts. In particular, i think that any sort of message signing should *not* happen during saving of a draft, but the intent to sign should be preserved. That is, we should save and restore the #secure tag when saving a draft or restoring a draft, but the saved draft itself should *not* be signed. for encryption, i have a different (and arguably opposite) intuition. if the sender has the ability to *decrypt* mails, i'd argue that saving a draft should encrypt the draft, regardless of the draft's stated intent to encrypt. These cases matter because i know many people use tools like offline-imap to sync their mail store with a remote mailserver. if the remote mailserver can get a copy of the signed draft, it could replay it (effectively making use of an unintentional signature). Likewise, if the user doesn't think about encrypting a message until they're they're ready to send it, then an intermediate/draft version of the message might end up in cleartext on the remote server. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Emacs: postponing messages
On Thu 2016-06-02 14:21:44 -0400, Mark Walters wrote: > My broad idea for postpone is to take the partial message, use notmuch > insert to put it in the database with a "postponed" tag, and then on > resume fetch the raw message and go into notmuch-message-mode, and also > either add a deleted tag to the resumed message, or better actually > delete the resumed message. Finally, we would add postponed to the > excluded tags list, so that postponed messages only show up when > searched for. I'd love to see this happen. The terminology many other mail user agents use for this workflow is often "draft" or "drafts" so we might do well to adopt that term, instead of using "postpone", which i don't think is as widely-used. > An alternative would be to attach the attachments with the postponed > message. This is probably doable by writing the message (as if being > fcc'd) to notmuch insert, and then using the mime-to-mml function to > reverse the process. The downside here is that now the attached file is > not the current file in the filesystem when you send -- ie its different > from the normal case. I like this approach, and i don't think that the caveat you're describing is a particuarly bad one, though it depends on how mime-to-mml works. I just tested it, and mime-to-mml actually produced something that was not directly sendable in notmuch-message-mode, because it didn't include the "--text follows this line--" break between headers and body :/ But this is probably fixable ;) However, mime-to-mml actually embedded the content of the included sub-part upon reconstruction and the filename was only the leaf filename (i'd included /home/dkg/tmp/test.txt, and in the reconstructed #part it said filename="test.txt" nofile=yes) Since this doesn't include the original path of the file (and it said "nofile=yes"), then i don't think it's a problem. One thing i should note is that if there's a message-id assigned during saving of the draft, then we need to think carefully about how a draft that gets saved multiple times gets indexed. it'll have the same message-id, which is good, but there will likely be multiple files referencing it, each with different content. ideally, there would only be one copy indexed, and it would be the latest one. Also, the actually-sent mail should be indexed in preference over a previous draft. The above pieces would all be really great to have! In addition, if they were in place, it'd be good to have an variant notmuch-search view that lists the recipients instead of the senders, so that i can do a search for tag:draft and actually see who the messages were sent to, instead of my own name (as the sender) on each item :) --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Emacs: postponing messages
Dear All There was some discussion on irc yesterday about a better way of postponing message when using the emacs frontend. I think getting a moderately nice interface should be quite easy (see below) but there are some corner cases on what *should* happen that I would like to resolve before trying to implement anything. My broad idea for postpone is to take the partial message, use notmuch insert to put it in the database with a "postponed" tag, and then on resume fetch the raw message and go into notmuch-message-mode, and also either add a deleted tag to the resumed message, or better actually delete the resumed message. Finally, we would add postponed to the excluded tags list, so that postponed messages only show up when searched for. Now the main difficulty I see is what to do with attachments. If we just leave the mml #part markers in the message then the file might have disappeared by the time we resume (or could even be a different file). This would be a particular problem if people attach files that are in /tmp say. Further the way rfc822 forwarding works (ie the default forwarding in notmuch/emacs) is to put each attachment of the message that is being forwarded into its own emacs buffer, and include these buffers via the mml markers. These buffers would all disappear if the user restarts emacs between postponing and resume. An alternative would be to attach the attachments with the postponed message. This is probably doable by writing the message (as if being fcc'd) to notmuch insert, and then using the mime-to-mml function to reverse the process. The downside here is that now the attached file is not the current file in the filesystem when you send -- ie its different from the normal case. Any thoughts or comments very gratefully received! Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch