Re: More debian packaging cleanup
On 2019-12-04 03:47:37, Daniel Kahn Gillmor wrote: > This series should apply after "wrap-and-sort -ast" v2 is applied > (id:20191110173748.25792-5-...@fifthhorseman.net). > > In this series, i clean up a few things that i noticed from applying > dh_missing to the debian packaging. In particular, we were failing to > ship notmuch(3) (programmer's manual for libnotmuch) and > notmuch-setup(1) (a symlink or copy of notmuch(1) that is referenced > in notmuch-config(1)). > > This doesn't get us to the point of enabling dh 12 cleanly yet (more > elpa-notmuch cleanup might be blocked on #946142 and answers to the > questions i raised in id:87a7887akl@fifthhorseman.net), but it's > a lot of the way there. Wow, that's great work! I can't believe we weren't shipping those manpages! :) LGTM... a. -- If we do not do the impossible, we shall be faced with the unthinkable. - Murray Bookchin ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Complete Debian packaging transition to dh 12
On 2019-12-09 13:49:06, Daniel Kahn Gillmor wrote: > This series follows the series introduced by > id:20191204084742.398298-1-...@fifthhorseman.net > > Its goal is to move the notmuch debian packaging to dh 12. > > To do this, the series accepts the conclusions about info files > reached in the thread anchored at id:87a7887akl@fifthhorseman.net, > and it also relies on dh_elpa having #946142 resolved, for example, by > merging https://salsa.debian.org/emacsen-team/dh-elpa/merge_requests/2 > into that project. > > What remains here is pretty simple mechanical work, which shouldn't > have an effect on anything else in notmuch other than how the debian > package itself gets assembled. I'm not very familiar with the dh-elpa and dh-missing voodoo that's going on here, I must admit. But this otherwise seems to make sense after a quick review, so: LGTM! :) a. -- C'est trop facile quand les guerres sont finies D'aller gueuler que c'était la dernière Amis bourgeois vous me faites envie Ne voyez vous pas donc point vos cimetières? - Jaques Brel ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: rfc: notmuch-status.el - notmuch status reporting
On 2019-12-05 12:56:46, David Edmondson wrote: > The idea is to layer on top of the existing `notmuch-saved-searches' as > a set of queries that you find interesting. When combined with > `notmuch-jump' it provides, I think, a quick way of seeing the state of > queries that you care about and then jumping to the corresponding > messages. That's pretty neat! -- Quidquid latine dictum sit, altum sonatur. Whatever is said in Latin sounds profound. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
filtering headers from forwarded messages
hey folks-- i recently had cause to forward a set of messages to a colleague via notmuch (thank you for "notmuch-show-forward-open-messages"!), and noticed that forwarding messages that i've personally received leaks quite a bit of metadata about message delivery paths that is (a) generally not useful when i'm forwarding in order to transfer the message content, and (b) potentially harmful to users whose message routing path reveals something bad or awkward about their setup. For example, maybe for some people, their incoming mail path shows that they're actually reading their personal e-mail on their employer's mailsystems, but they don't want to expose their place of employment to someone just by forwarding a message. (this path is exposed by Received: headers) Or, there are internal headers added by local antispam or antimalware filters, and they don't want to expose the specifics of their filtering defenses because it might enable attacks on those systems (or customized bypass mechanisms). So, it occurs to me that someone might want to forward a message (or messages) while filtering the headers in some way. Of course, for messages being forwarded for the purpose of debugging the transit path, you *don't* want to filter out headers. In notmuch-emacs, i can manually filter the headers by editing the reply compose buffer, of course, but it's kind of a pain, and it'd be nice to have it done automatically for me. Some possible filters i can imagine (which might well have problems, i would appreciate any review): - blocklist: remove all headers that are in a fixed set: (Received, Delivered-To, Received-SPF, X-Original-To, Return-Path, X-Virus-Check-By, X-Virus-Scanned, Authentication-Results, X-MS-*, X-Microsoft-*) - allowlist: remove all headers except for a fixed set (To, From, Cc, Subject, Date, Message-Id, References, In-Reply-To, MIME-Version, Content-*, List-*, Sender) - ordered removal: remove all headers up to and including the last Received line Has anyone else considered this use case, or thought about how to make it easy/simple to do the right thing when using Notmuch? Are there other factors that are worth considering? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Complete Debian packaging transition to dh 12
Daniel Kahn Gillmor writes: > This series follows the series introduced by > id:20191204084742.398298-1-...@fifthhorseman.net > > Its goal is to move the notmuch debian packaging to dh 12. pushed to master ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: More debian packaging cleanup
Daniel Kahn Gillmor writes: > This series should apply after "wrap-and-sort -ast" v2 is applied > (id:20191110173748.25792-5-...@fifthhorseman.net). > pushed to master d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
