[PATCH] HEAD is dead, remove wrong instruction from doc/devel-notes.txt

# HG changeset patch # User Eike Rathke er...@erack.de # Date 1421831657 -3600 # Node ID 5d7345b4c516c733a84eb559f04cc553cdcab7fd # Parent 6e5a62946141f41b9c7c6b1d60f0e348279cc2c3 HEAD is dead, remove wrong instruction from doc/devel-notes.txt Branch HEAD was closed over a year ago. If one

[PATCH] allow short and long key ID user input in any pgp_long_ids mode for pgp_*

# HG changeset patch # User Eike Rathke er...@erack.de # Date 1421599541 -3600 # Node ID 5c6115fba7ac1efbe1f475b6e3bbe1898f3472bf # Parent cc790394468778ced239dc4d3245199cf3bd551e allow short and long key ID user input in any pgp_long_ids mode for pgp_* The following did not work, e.g. when

[PATCH] allow short and long key ID user input in any pgp_long_ids mode for crypt_*

# HG changeset patch # User Eike Rathke er...@erack.de # Date 1421599842 -3600 # Node ID ed00f80073ea372e995fc8d4611991a2e2e08672 # Parent 5c6115fba7ac1efbe1f475b6e3bbe1898f3472bf allow short and long key ID user input in any pgp_long_ids mode for crypt_* The following did not work, e.g. when

Re: [PATCH] allow short and long key ID user input in any pgp_long_ids mode for pgp_*

, support the FSFE https://fsfe.org/support/?erack Use LibreOffice! https://www.libreoffice.org/ # HG changeset patch # User Eike Rathke er...@erack.de # Date 1421599541 -3600 # Node ID aa1783ebf072af28d136308d360758fcf93137d3 # Parent cc790394468778ced239dc4d3245199cf3bd551e allow short and long key

[PATCH 2 of 2] Allow fingerprint user input in crypt_getkeybystr() (part of #3695)

# HG changeset patch # User Eike Rathke er...@erack.de # Date 1423687143 -3600 # Node ID 659e014a1bfba9e75155a6df1223e8a7d1d7008f # Parent 01f6559e4bb51bfe86e9f48812480bd4d57adc03 Allow fingerprint user input in crypt_getkeybystr() (part of #3695) diff --git a/crypt-gpgme.c b/crypt-gpgme.c

[PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

Hi, These patches probably don't qualify to close #3695, but at least a fingerprint is accepted as user input and fingerprints of keys are displayed. For both the pgp_list_pubring_command and pgp_list_secring_command need to contain the --with-fingerprint option, or have with-fingerprint in

[PATCH 1 of 2] Allow fingerprint user input in pgp_getkeybystr() (part of #3695)

# HG changeset patch # User Eike Rathke er...@erack.de # Date 1423687117 -3600 # Node ID 01f6559e4bb51bfe86e9f48812480bd4d57adc03 # Parent 385d7434c9d6f44c732fd12fc76d543f9d5d7233 Allow fingerprint user input in pgp_getkeybystr() (part of #3695) Accept and check input of a fingerprint and find

Re: [PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack Use LibreOffice! https://www.libreoffice.org/ # HG changeset patch # User Eike Rathke er...@erack.de # Date

Re: [PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

Hi Kevin, On Friday, 2015-02-13 18:53:17 -0800, Kevin J. McCarthy wrote: If you are okay with my modifications to your patches, I'll push these after some more testing and giving others a chance to review them. Yes, sure, makes sense. I didn't test the new series though. Thanks Eike --

Re: [PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

Hi Kevin, On Wednesday, 2015-02-11 19:57:18 -0800, Kevin J. McCarthy wrote: First, just a general note. If you add (see #3695) to the top of a patch, the commit will be associated with the ticket automatically. Mentioning the number like in (part of #3695) does not? Ok, I'll use 'see' then.

Re: GPG public key not shown

Hi Heinz, On Friday, 2015-03-27 19:39:06 +0100, Heinz Diehl wrote: The key doesn't appear to be usable for encryption: it only has the sign and certify capabilities set (the last field on the pub line). Why would somebody want to upload a key which isn't suitable for encryption? Because

Re: http://dev.mutt.org/trac/ticket/3638

Hi acefael, On Saturday, 2015-05-02 13:32:23 +0100, acefael wrote: what do you think about the attached patch Why send the mail twice? Anyway.. [...] +Many others not mentioned here contributed code, fixes, , +and suggestions. }; - puts (_(Copyright)); + { +int

Re: [PATCH] Allow multiple crypt-hooks with the same regexp. (closes #3727)

Hi Kevin, On Saturday, 2015-04-04 11:41:12 -0700, Kevin J. McCarthy wrote: This is an updated version of the multiple-crypt-hook patch for consideration. The patch looks big, but a large portion of it is just indentation changes: if you review it ignoring whitespace it's clearer what's

Re: [PATCH] Allow multiple crypt-hooks with the same regexp. (closes #3727)

Hi Kevin, On Sunday, 2015-04-05 00:17:57 +0200, Eike Rathke wrote: indentation changes: if you review it ignoring whitespace it's clearer what's going on. IMHO it is much preferrable if such actions were split into two separate patches, one for the cosmetic change and another one

Re: [PATCH] Allow multiple crypt-hooks with the same regexp. (closes #3727)

Hi Kevin, On Saturday, 2015-04-04 11:41:12 -0700, Kevin J. McCarthy wrote: So this version keeps track of when a key has been selected for an address and adds this: else if (r == M_NO) { if (key_selected || (crypt_hook-next != NULL)) { crypt_hook =

Re: mutt: Remove 'hit enter' prompt for GPGME initialization errors.

Hi, On Sunday, 2015-07-05 13:40:43 -0700, Brendan Cully wrote: Older GPGMEs are missing CMS (S/MIME) support. Don't force the poor users to hit enter every time they start mutt. What is older exactly? And could we assume that anyone using a recent mutt would not be using such older GPGME?

Re: 1.6.0 proposed schedule

Hi, On Saturday, 2016-03-05 14:31:16 -0800, Kevin J. McCarthy wrote: > If you haven't tried out hg tip in a while, now would be a good time to > start testing it. Fwiw, I'm using tip since a few months on my private machine and since a few weeks also in daily work, one Maildir and ~3-5 IMAP

Re: mutt-1.5.24_DJGPP-2.05

Hi peters.al, On Sunday, 2016-02-28 10:43:49 +0100, peters.al wrote: > working in DJGPP ? Are you sure you want that? Eike -- OpenPGP/GnuPG encrypted mail preferred in all private communication. Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit

Re: [PATCH] change M_* symbols to MUTT_*

Hi, On Monday, 2016-05-09 10:13:53 -0700, Kevin J. McCarthy wrote: > Unless there are any objections, I will push this along with the backout > of 23334e967dd7 "Create a wrapper sys_socket.h to work around Solaris > namespace issues." later today. Fwiw, I'm writing this with tip including the

Re: [PATCH 0 of 8] Change Mutt to use window structures for screen drawing

Hi Kevin, On Tuesday, 2016-04-19 15:52:21 -0700, Kevin J. McCarthy wrote: > On Tue, Apr 19, 2016 at 09:22:34PM +0100, Richard Russon wrote: > > Can you put the changes into a public repo that people can fork? > > Perhaps you could elaborate about what you're thinking about? I think what

Re: Preserve pager position only for ops that redirect back to the same message.

Hi Kevin, On Saturday, 2016-08-13 07:32:57 -0700, Kevin J. McCarthy wrote: > I can confirm the behavior, but I can not confirm any regression. > Again, I am seeing the same behavior in 1.6.0, 1.5.24, and 1.5.23: > toggling the headers does *not* go back to the top of the message. Same here,

Re: [PATCH] Preserve pager position only for ops that redirect back to the same message.

Hi Kevin, On Saturday, 2016-08-06 18:03:53 -0700, Kevin J. McCarthy wrote: > Attached is the revised patch. This version doesn't restrict the > operations where the pager position is saved. Instead, it just makes > sure the position is cleared when we return to the index menu. But this means

[PATCH] mx_check_mailbox: prevent dereferencing a null pointer

This happened when in an IMAP index view the underlying connection was terminated, ctx->mx_ops was NULL and thus accessing ctx->mx_ops->check segfaulted. # HG changeset patch # User Eike Rathke <er...@erack.de> # Date 1474491061 -7200 # Wed Sep 21 22:51:01 2016

[SPAM?] Re: index format locale bug

Hi Derek, On Friday, 2016-08-26 17:46:09 -0500, Derek Martin wrote: > On Fri, Aug 26, 2016 at 01:50:40AM +0200, Eike Rathke wrote: > > Alias for the configuration I meant. If both are used the last one wins. > > Simple. > > Yes, I know what you meant. Do you run Mu

Re: index format locale bug

Hi, On Tuesday, 2016-08-23 11:04:57 +0200, Eike Rathke wrote: > Users who not used $locale will experience > a change only if their environment is not 'C' or 'en_US' and > $date_format does not start with "!". Btw, apart from that, having a default date_format="!%a, %b

Re: index format locale bug

Hi Kevin, On Monday, 2016-08-22 20:17:14 -0700, Kevin J. McCarthy wrote: > Please everyone, don't be shy to let me know if you think this is a > stupid change. Well, I think removing the $locale variable was a stupid change ;-) Whether to add $attribution_locale I don't really care, fine for me

Re: index format locale bug

Hi, On Wednesday, 2016-08-24 08:51:01 -0700, Kevin J. McCarthy wrote: > We've merely reduced the effect of the (proposed alias) $locale. Other > places it used to affect, such as the index dates, will now be > controlled by the user's locale environment variables. I suspect that > most users

Re: index format locale bug

Hi, On Tuesday, 2016-08-23 12:18:42 -0500, Derek Martin wrote: > On Tue, Aug 23, 2016 at 11:04:57AM +0200, Eike Rathke wrote: > > Well, I think removing the $locale variable was a stupid change ;-) > > Whether to add $attribution_locale I don't really care, fine for me > &g

Re: snprintf() results may get truncated

Hi Vincent, On Monday, 2017-09-18 13:13:07 +0200, Vincent Lefevre wrote: > > [... _POSIX_PATH_MAX ...] > > (which usually is defined to 256 including null char). > > And it must be 256 in the current POSIX version: > > {_POSIX_PATH_MAX} > Minimum number the implementation will accept as

snprintf() results may get truncated

Hi, This is nothing overly critical (not even in mutt_rmtree() if a truncated string also represents an existing directory entry, as there was a checked opendir(path) and all entries are to be removed, but truncated will not be removed as intended, so..), just a heads-up that some long paths may

PATH_MAX and POSIX (was: snprintf() results may get truncated)

Hi Vincent, On Tuesday, 2017-09-19 12:18:34 +0200, Vincent Lefevre wrote: > Now, I don't see much point in defining both _POSIX_PATH_MAX and > PATH_MAX for similar meanings. POSIX is strange, sometimes. :) Might be ;-) but in this case the important difference is _POSIX_PATH_MAX Minimum number

Re: snprintf() results may get truncated

Hi, On Friday, 2017-09-15 13:02:25 -0500, Derek Martin wrote: > On Fri, Sep 15, 2017 at 09:43:58AM -0700, Kevin J. McCarthy wrote: > > On Fri, Sep 15, 2017 at 12:58:18AM +0200, Eike Rathke wrote: > > > Maybe path related destination buffers also shouldn't be > > > of _

Re: [PATCH] fix recipients when group replying with reply_self enabled

Hi, On Friday, 2017-09-22 13:16:38 -0700, Kevin J. McCarthy wrote: > So the question is if (g)roup reply with 'set reply_self; unset metoo' > should disable the $nometoo behavior. I think so, but please chime in! Might make sense. But I'd not expect it. I'd rather not expect $reply_self to

Re: mutt deletes space characters in recipients address

Hi Lutz, On Tuesday, 2017-12-19 13:44:09 +0100, Lutz Jankowski wrote: > When entering a recipients address that contains a space character, mutt > just deletes it. The behaviour is the same whether you sent the email in a > single command from the terminal or use mutt's interface. > >

Re: mutt deletes space characters in recipients address

Hi, On Tuesday, 2017-12-19 14:29:35 +0100, Eike Rathke wrote: > White-space is not allowed in the local-part according to > https://tools.ietf.org/html/rfc5322#section-3.2.4 Quoted Strings > https://tools.ietf.org/html/rfc5322#section-4.1 Miscellaneous Obsolete Tokens > that in

Re: mutt: Add $change_folder_next option to control mailbox suggesti...

Hi Brendan, Kevin, Simon, On Saturday, 2017-11-11 15:50:11 -0800, Brendan Cully wrote: > This patch brings back the original behaviour of change-folder, which > some people find more useful. Just want to say thank you, I really like this behaviour. Eike -- OpenPGP/GnuPG encrypted mail

Re: Switch to git and gitlab in progress

Hi Kevin, On Sunday, 2017-12-10 19:37:38 -0800, Kevin J. McCarthy wrote: > Sorry things have been so quiet. I've been pretty busy on other stuff, > but what time I have had available has been working on migrating Mutt to > git. Nice move, starred :-) Eike -- OpenPGP/GnuPG encrypted mail

Re: Efail and Mutt

Hi, On Monday, 2018-05-14 15:33:33 +0200, Vincent Lefevre wrote: > And piping a decrypted mail to a browser (e.g. if there is no > text/plain part, and an attacker can ensure that) is not safe. There's nothing wrong with a ~/.mailcap entry similar to this: text/html; /usr/bin/elinks -localhost

Re: PGP decryption no longer works

Hi Vincent, On Monday, 2018-06-25 16:39:19 -0400, Vincent Lefevre wrote: > It seems that a recent change has broken PGP decryption: > I now get a failure from gnupg. No issues with Mutt from > Debian/unstable. No problem here, using most recent master with gpgme on Debian stretch. Eike --

Re: PGP decryption no longer works

Hi Vincent, On Tuesday, 2018-06-26 08:59:06 -0400, Vincent Lefevre wrote: > On 2018-06-26 10:14:09 +0200, Eike Rathke wrote: > > On Monday, 2018-06-25 16:39:19 -0400, Vincent Lefevre wrote: > > > > > It seems that a recent change has broken PGP decryption: > > &g

version number

Hi, Building mutt from master, mutt -h (or -v) display the version as currently Mutt 1.9.4+96 (f6232a25) (2018-03-03) That's somewhat unexpected and apparently in version.sh the distance from latesttag isn't quite what was thought it would be.. Nothing important, just to mention. Eike --

Re: why casting pointer in mutt_mem_free

Hi, On Tuesday, 2018-03-27 12:30:13 -0500, Derek Martin wrote: > > void mutt_mem_free(void *ptr) > > { > > void **p = (void **) ptr; > > if (*p) > > { > > free(*p); > > *p = 0; > > ... > char *x = (char *)malloc(buffsz); > /* do some stuff with x * > ... >

Re: Mailing list status

Hi Kevin, On Sunday, 2018-03-18 12:22:11 -0700, Kevin J. McCarthy wrote: > On Sun, Mar 18, 2018 at 07:44:57PM +0100, Moritz Barsnick wrote: > > My bad. Because Stuart put me on Cc:, I only got the direct mail, and > > not through the list. (I just reconfigured that @mailman... Stupid > >

Re: Alignment attribute

Hi, On Sunday, 2019-04-14 15:18:40 -0700, Kevin J. McCarthy wrote: > On Sun, Apr 14, 2019 at 11:14:05PM +0200, Gero Treuner wrote: > > Just drop that alignment? > > No, let's leave it. Interested I took a glance and yes it should be kept. > > Considering that Mutt doesn't control alignment on

Re: Feedback on ticket 146 - $reverse_realname behavior

Hi Kevin, On Saturday, 2019-06-08 14:20:49 -0700, Kevin J. McCarthy wrote: > Right now, if a To address is missing the personal (name) part, the From > will be filled in with $realname in the reply. > > The ticket submitter expects that if the To address was missing a name, the > reply From

Re: meaning of number of lines in the message (%l in index_format)

Hi, On Monday, 2019-06-24 18:41:56 -0500, Derek Martin wrote: > Or just remove it. If it's not accurate (or even if it is) what value > can it really provide? Even if it isn't accurate it gives me a rough idea about the size of the message (usually after viewed already which calculates the

Re: Ticket 151 - strip leading '-' for mailcap sanitize

Hi Kevin, On Friday, 2019-06-21 12:09:19 -0700, Kevin J. McCarthy wrote: > Perhaps the "expected" behavior is putting '--' before the %s, but neither > the sample mailcap or manual mention that. Not all programs and tools support the '--' mechanism. Eike -- OpenPGP/GnuPG encrypted mail

Re: Ticket 151 - strip leading '-' for mailcap sanitize

Hi Kevin, On Friday, 2019-06-21 12:20:28 -0700, Kevin J. McCarthy wrote: > Just to be clear, the ticket is actually advocating for sanitizing the > leading "-", into "_" as other unsafe characters are. I further wonder if > we should just remove "-" from the whitelist rather than adding a

Re: Ticket 151 - strip leading '-' for mailcap sanitize

Hi Kevin, On Friday, 2019-06-21 13:26:22 -0700, Kevin J. McCarthy wrote: > On Fri, Jun 21, 2019 at 10:03:23PM +0200, Eike Rathke wrote: > > I would not like to have all '-' replaced by '_' in attachments > > (specifically I personally use '-' instead of '_' except when

Building master on Fedora fails

Hi, I tried to build current master on Fedora F29 and that failed at two points: One is the call /usr/bin/docbook2texi --encoding=utf-8 \ --string-param output-file=mutt \ --string-param 'directory-category=Email-software' \ --string-param 'directory-description=Text based mail

Re: Building master on Fedora fails

Hi Kevin, On Sunday, 2019-05-19 14:28:09 -0700, Kevin J. McCarthy wrote: > On Sun, May 19, 2019 at 11:03:17PM +0200, Moritz Barsnick wrote: > > Fedora packages the docbook2X version of docbook2texi as > > db2x_docbook2texi (in package docbook2X). The binary it provides as > > docbook2texi comes

Re: Building master on Fedora fails

Hi, On Tuesday, 2019-05-21 10:34:01 +0200, Vincent Lefevre wrote: > On 2019-05-20 12:50:41 -0700, Kevin J. McCarthy wrote: > > On Mon, May 20, 2019 at 04:51:34PM +0200, Vincent Lefevre wrote: > > > So, before looking at docbook2texi, it is necessary to look at > > > docbook2x-texi. > > > >

Re: Autocrypt

Hi Kevin, On Sunday, 2019-08-11 13:44:53 -0700, Kevin J. McCarthy wrote: > On Sun, Aug 11, 2019 at 10:24:42PM +0200, Eike Rathke wrote: > > The minimal public key of multiple UIDs written as autocrypt keydata in > > my case is 15kB, quite large as mail overhead. I guess

Autocrypt and encrypted/signed mail from a key in pubring

Hi, For an encrypted and signed mail for which the key is both in the regular pubring and in the autocrypt pubring (and autocrypt.db), the signature apparently is verified using the autocrypt keyring, at least I get | WARNING: We have NO indication whether the key belongs to the person named as

Re: Autocrypt

Hi Kevin, On Monday, 2019-08-12 16:13:16 -0700, Kevin J. McCarthy wrote: > On Tue, Aug 13, 2019 at 12:56:37AM +0200, Eike Rathke wrote: > > and then gpg --homedir testdir -k lists the 12 (!) addresses of the > > original key. It seems that the Autocrypt header content for an e

Re: pkg-config usage for sqlite3

Hi Kevin, On Monday, 2019-08-12 10:51:56 -0700, Kevin J. McCarthy wrote: > > why would supplying a non-standard search path to pkg-config files be > > any more problematic than a non-standard path to the library itself? > > By all means, please enlighten me. My understanding from starting to >

Re: Autocrypt

Hi Kevin, On Monday, 2019-08-12 17:38:16 -0700, Kevin J. McCarthy wrote: > On the plus side, it actually gives you some flexibility if you wanted to > take advantage of it. You could create a different base64 export of the > same keyid, each with a single uid, and store it right in the database

Re: Autocrypt

Hi Kevin, On Monday, 2019-08-12 09:07:49 -0700, Kevin J. McCarthy wrote: > On Mon, Aug 12, 2019 at 11:57:14AM +0200, Eike Rathke wrote: > > Tried (then it needs to be done with --export-secret-keys not --export, > > of course..) with 6 of 12 uids but that didn't change an

Re: Autocrypt

Hi, On Tuesday, 2019-08-13 02:59:28 +0200, Eike Rathke wrote: > On Monday, 2019-08-12 17:38:16 -0700, Kevin J. McCarthy wrote: > > > On the plus side, it actually gives you some flexibility if you wanted to > > take advantage of it. You could create a different base64 expo

Re: Autocrypt

Hi Kevin, On Friday, 2019-08-09 14:31:55 -0700, Kevin J. McCarthy wrote: > On Fri, Aug 09, 2019 at 11:14:06PM +0200, Eike Rathke wrote: > > > It's selecting a key from the keyring in $autocrypt_dir. > > > > But that's just after it created the $autocrypt_dir so there

Re: Autocrypt and encrypted/signed mail from a key in pubring

Hi, On Thursday, 2019-08-22 22:11:41 +0200, Eike Rathke wrote: > I don't want the automatically scanned autocrypt keys populate my > regular keyring. I think the better solution at least for me is to sync > the autocrypt pubring from the regular pubring. Just to acknowledge that th

Re: Autocrypt and encrypted/signed mail from a key in pubring

Hi, On Tuesday, 2019-08-20 15:42:13 -0700, Kevin J. McCarthy wrote: > On Sun, Aug 18, 2019 at 03:29:50PM -0700, Kevin J. McCarthy wrote: > > Another choice would be to point $autocrypt_dir at ~/.gnupg (you can > > copy the autocrypt.db file over to save yourself having to recreate > > accounts).

Autocrypt

Hi Kevin, The new Autocrypt feature seems to work :-) Tried with/without overriding conventional PGP encryption and vice versa. Great work, thanks! One caveat: when enabling autocrypt=yes and starting mutt the first time one must ensure to not have some key push in the config, otherwise that

Re: Autocrypt

Hi Kevin, On Wednesday, 2019-08-07 17:40:06 -0700, Kevin J. McCarthy wrote: > > One caveat: when enabling autocrypt=yes and starting mutt the first time > > one must ensure to not have some key push in the config, otherwise that > > interferes with the prompt about setting up the autocrypt

Re: Autocrypt

Hi Kevin, On Thursday, 2019-08-08 15:58:07 -0700, Kevin J. McCarthy wrote: > On Fri, Aug 09, 2019 at 12:36:37AM +0200, Eike Rathke wrote: > > > Yes, today I pushed up the ability to select a key during account > > > creation. > > > It's rather fresh but I th

Re: botched display - mutt or ncurses bug?

Hi, On Thursday, 2019-11-07 21:40:00 +0100, Oswald Buddenhagen wrote: > anyone else seen such a thing? Never. Running Mutt master built on Debian buster and Fedora 29 in Gnome terminal. Eike -- OpenPGP/GnuPG encrypted mail preferred in all private communication. GPG key 0x6A6CD5B765632D3A

Re: Background editing

Hi Kevin, On Sunday, 2020-03-01 12:36:23 -0800, Kevin J. McCarthy wrote: > manual: Seems to work. Nice feature! What is a bit confusing is that when editing simultaneous messages of the same thread then the background_format displays

Re: Background editing

Hi Kevin, On Sunday, 2020-03-01 18:10:51 -0800, Kevin J. McCarthy wrote: > I added %i to the list of expandos for $background_format. Nice, thanks. > Although I didn't add it to the default value, I'm quite open to suggestions > for a good default. I currently have "%5p %10S %s ; To: %r ;

Re: Background editing

Hi, On Sunday, 2020-02-23 13:32:05 -0800, Kevin J. McCarthy wrote: > On Mon, Feb 17, 2020 at 10:03:19AM -0800, Kevin J. McCarthy wrote: Odd enough, I didn't receive that parent message. Anyway.. To conveniently switch between graphics and terminal editor I have the following in muttrc source

Re: Background editing

Hi Kevin, On Thursday, 2020-04-09 20:33:23 -0700, Kevin J. McCarthy wrote: > On Tue, Mar 03, 2020 at 09:11:37PM +0100, Eike Rathke wrote: > > To conveniently switch between graphics and terminal editor I have the > > following in muttrc > > > > source '~/.mutt/dete

Re: Background editing

Hi Kevin, On Saturday, 2020-04-18 12:56:20 -0700, Kevin J. McCarthy wrote: > Are you okay with me adding the same license as the rest of Mutt (GPL 2+) to > the header? Yes of course. Eike -- OpenPGP/GnuPG encrypted mail preferred in all private communication. GPG key 0x6A6CD5B765632D3A -

Re: mutt 1.14.0 released

Hi Kevin, On Sunday, 2020-05-03 07:02:56 -0700, Kevin J. McCarthy wrote: > I'm always glad to hear from long-time users, especially > when they are still happy with the new releases. :) Oh yes, I continuously am, always on a quite recent master build :-) Eike -- OpenPGP/GnuPG encrypted

Re: S/MIME question

Hi isdtor, On Saturday, 2020-09-12 09:32:35 +0100, isdtor wrote: > Basically, what I want to achieve is that the locally saved copy of an > encrypted email is readable by and encrypted to me. By default, this is not > the case, and the saved copy is encrypted to the recipient only. This is due

Re: Taking a break for a bit

Hi Kevin, On Tuesday, 2020-07-28 13:12:24 -0700, Kevin J. McCarthy wrote: > Thank you all! Just to thank YOU instead for gaining expertise and bringing Mutt forward all the last years and making it catch up on important features and squeezing bugs. I know that building community (above the

Re: [PATCH] Change hardcoded subject of replies

Hi, On Friday, 2020-07-24 13:01:39 -0500, Derek Martin wrote: > On Fri, Jul 24, 2020 at 06:56:38AM +0200, Claus Assmann wrote: > > "Re:" is a standard that should not be translated. > > Except some languages don't use it. Rather "some MUAs don't use it in some languages" and those MUAs are

Re: [PATCH] Change hardcoded subject of replies

Hi Kevin, On Thursday, 2020-07-23 09:44:18 -0700, Kevin J. McCarthy wrote: > > -env->subject = safe_strdup ("Re: your mail"); > > +env->subject = safe_strdup ("Re:"); > > I agree the default is weird, but I'd like to give time for others to chime > in about this first. I'll wait a week

Re: [PATCH] Change hardcoded subject of replies

Hi, On Friday, 2020-07-24 13:01:03 -0500, Derek Martin wrote: > I think some other mailers default to something like > "Re: (no subject)" which seems more suitable to me. I agree. Eike -- OpenPGP/GnuPG encrypted mail preferred in all private communication. GPG key 0x6A6CD5B765632D3A - 2265

Re: message_id_format

Hi Kevin, Thanks for that anyway, which hopefully ends the "search for the holy grail of msgid" now and forever :P Eike -- OpenPGP/GnuPG encrypted mail preferred in all private communication. GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Use LibreOffice!

Re: [PATCH] Add skip_quoted_context option

Hi Kevin, On Monday, 2021-06-14 05:49:50 -0700, Kevin J. McCarthy wrote: > Thank you for your feedback Jim and Aaron. It sounds like this would be a > good feature, then. :-) I'm just chiming in to agree :-) Eike -- OpenPGP/GnuPG encrypted mail preferred in all private communication. GPG

Re: Loosening mailcap filename sanitization to allow unicode filenames

Hi Kevin, On Tuesday, 2021-04-27 10:17:29 -0700, Kevin J. McCarthy wrote: > What if we added an allow_8bit parameter to the function, that also passed > through bytes with the 8th bit set? I'd keep this set off in all other > invocations except the mailcap invocations. Allowing *all* 8-bit may

Re: $reply_prefix

Hi, On Friday, 2022-01-14 14:36:13 +0300, Jean Louis wrote: > > > It MAY, and it MAY NOT. There is no strict rule to it. > > > > Indeed, it doesn't say "MAY NOT", so that "Re: " is not forbidden. > > But this does not mean that other prefixes are allowed. > > Quite contrary, my understanding

Re: Upcoming freeze for 2.2.0 and maintainer update

Hi Kevin, On Sunday, 2022-01-23 09:47:57 -0800, Kevin J. McCarthy wrote: > Thank you all for your support, and to the development team for giving me > the maintainership opportunity. I can't thank you enough for keeping mutt being the mailer that sucks less! Eike -- OpenPGP/GnuPG encrypted

Re: IMAP connection closed while Getting mailbox UIDVALIDITY

Hi Andrej, On Monday, 2023-04-17 15:26:19 +0200, Andrej Mikus wrote: > [2023-04-17 09:23:48] 4< * OK [UIDVALIDITY 63817286416513] UIDs valid > > Is the number returned by server too big? Thunderbird has no issues. Might be. In imap/imap.c imap_open_mailbox() the UIDVALIDITY is scanned as

Re: What is a Message-id?

Hi, On Wednesday, 2023-05-24 21:34:08 +0100, Ian Collier wrote: > On Wed, May 24, 2023 at 07:54:32PM +0200, Ludolf Holzheid wrote: > > From RFC 5322: "The message identifier (msg-id) syntax is a limited > > version of the addr-spec construct enclosed in the > >

Re: Message security; protected header fields

Hi, On Thursday, 2024-05-09 19:15:59 -0400, Derek Martin wrote: > Probably fine for preventing casual eavesdropping, but for genuinely > sensitive applications, should not be considered good enough, unless > I'm missing some important detail... If you can't trust but need to, then verify. The