Re: Message security; protected header fields
In days of yore (Sat, 20 Apr 2024), Steffen Nurpmeso thus quoth: > Kurt Hackenberg wrote in > |Agreed. > > I do not, actually. Especially since it already is actively used. > The question always is "how do receivers act upon this", of > course, and this especially means the graphical, even > browser-based monsters which users cannot configure, more, which > have uneducated -- or better say "unaware" -- user bases. I would worry less about the users and more about breaking clients. The method of "be liberal about what you receive and conservative about what you send" is apt. Being standards-compliant is safe. > Those clients, and i do not even know how well GMail or Outlook > (or Apple Mail) can deal with S/MIME or PGP signed or even > encrypted (hmm..) email, would have to take and treat the secured > headers as the real ones. But, quite the opposite, you hear > statements of participants on user complaints like "i cannot > [click-]open your attachment" and such for PGP etc detached > signatures etc etc etc. > (You also hear "please use > for quoting, my mailer does not > understand your |", even though the leading whitespace was the > very first quotation method ever used (in a RFC), and is still > standardized in POSIX .. whatever.) Outlook and Apple Mail are able to use S/MIME out of the box. GnuPG is something you have to work on to get to a functioning state, but it is possible. For GMail there is a browser-plugin called FlowCrypt that will give you GnuPG encryption. For Apple Mail, using MacGPG will do the same. Not sure about browser mail via icloud.com, but FlowCrypt should work there too (I just have not tested it). Outlook and GnuPG I have not tried to get working, but there is some GUI offering of GnuPG for Windows, so I assume it is possible. > |I would like to hold off on this until the draft becomes an RFC, if \ > |it does. Agreed - though as Mutt can produce at least the Subject line this way when signing messages, we can test different mail clients to see how they behave. I will endeavour to test Mac Mail, Outlook (new) and web-UI for Gmail, Outlook and Apple mail to see how they render it. I will also test KMail. I do not envisage clients breaking, but never say never. Stranger things have happened throughout history. -- Kind regards, /S
Correct parsing of obsolete header syntax
Hi,
When mutt parses a header line that includes a space in the header name field,
it treats this line and all following lines as body text.
This has the unwanted effect of moving genuine headers into the body of the
message.
Although the ASCII space character is not usually permitted in a header name
field, RFC 5322 defines as an 'obsolete syntax' headers with any amount of WSP
characters immediately before the colon.
Parsing them correctly is actually a MUST in RFC 5322, (although generation of
headers in this obsolete format is a MUST NOT in the same RFC 5322).
The code responsible for this in mutt is in parse.c, function
mutt_read_rfc822_header() and seems to have been this way in every mutt
version released.
So maybe this is actually a feature and not a bug, perhaps a work-around for
compatibility with broken muas in use at the time.
In any case, if it is now considered a bug then something like the following
would fix it, although I'm not really familiar with the mutt codebase so you
might prefer a different approach.
--- parse.c.distFri Aug 18 00:03:18 2023
+++ parse.c Sat Dec 2 09:14:46 2023
@@ -1596,7 +1596,7 @@
while ((loc = ftello (f)),
*(line = mutt_read_rfc822_line (f, line, &linelen)) != 0)
{
-if ((p = strpbrk (line, ": \t")) == NULL || *p != ':')
+if ((p = strpbrk (line, ": \t")) == NULL || (*p != ':' && *(p + strspn(p,
" \t")) != ':'))
{
char return_path[LONG_STRING];
time_t t;
Correct parsing of obsolete header syntax
Hi,
When mutt parses a header line that includes a space in the header name field,
it treats this line and all following lines as body text.
This has the unwanted effect of moving genuine headers into the body of the
message.
Although the ASCII space character is not usually permitted in a header name
field, RFC 5322 defines as an 'obsolete syntax' headers with any amount of WSP
characters immediately before the colon.
Parsing them correctly is actually a MUST in RFC 5322, (although generation of
headers in this obsolete format is a MUST NOT in the same RFC 5322).
The code responsible for this in mutt is in parse.c, function
mutt_read_rfc822_header() and seems to have been this way in every mutt
version released.
So maybe this is actually a feature and not a bug, perhaps a work-around for
compatibility with broken muas in use at the time.
In any case, if it is now considered a bug then something like the following
would fix it, although I'm not really familiar with the mutt codebase so you
might prefer a different approach.
--- parse.c.distFri Aug 18 00:03:18 2023
+++ parse.c Sat Dec 2 09:14:46 2023
@@ -1596,7 +1596,7 @@
while ((loc = ftello (f)),
*(line = mutt_read_rfc822_line (f, line, &linelen)) != 0)
{
-if ((p = strpbrk (line, ": \t")) == NULL || *p != ':')
+if ((p = strpbrk (line, ": \t")) == NULL || (*p != ':' && *(p + strspn(p,
" \t")) != ':'))
{
char return_path[LONG_STRING];
time_t t;
Re: mutt on OpenBSD
> I recently hit a similar issue on Gentoo when I tried building Mutt > using GnuTLS (forgot to note down the versions, but I think it was Mutt > 2.2.3 and GnuTLS 3.7.8 according to Portage logs). I backed out when I > saw the "accept cert" prompt, though, since I wasn't sure how to > proceed, and instead rebuilt it with OpenSSL since it worked before (and > continues to do so today). > > Currently on Mutt 2.2.10. I saw that ebuild update but haven't updated yet :) In any case, I solved the OpenBSD issue. Problem between keyboard and chair. Setting out to try Kevin's suggestion, I found I had set ssl_usesystemcerts=no. There was a question mark in the comment next to it and I don't remember why I changed away from the default here or what I was checking.
mutt on OpenBSD
This is more of a heads-up as the problem isn't in mutt per se. A while back, mutt stopped working correctly for me on OpenBSD, and of course, I completely failed to take notice at which point and with which release exactly ... What is the problem? When you connect to a server for the first time, mutt prompts to accept the server cert (o)nce or (a)lways, in the latter case, saving it into $certificate_file. If you choose to save the cert, the next time you connect to the server, connection will fail with SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed The workaround is to accept the certificate (o)nce, for the current session only, every time. I verified this with two different servers and non-overlapping certificate chains. My guess is that the problem is really with libressl and probably started with OpenBSD 7.0 (libressl 3.3.4) or 6.9 (3.3.2). As a test, I installed openssl 1.1.1t from ports and rebuilt the mutt port so that it configures and links against openssl. No more problem. mutt -d 5 wasn't much help in trying to debug this. This is the scenario when the server cert doesn't exist in the certificate file and is added to it [2023-04-25 12:15:23] Looking up disroot.org... [2023-04-25 12:15:23] Connecting to disroot.org... [2023-04-25 12:15:23] ssl_load_certificates: loading trusted certificates [2023-04-25 12:15:23] ssl_socket_open: Error loading trusted certificates [2023-04-25 12:15:23] ssl_verify_callback: checking cert chain entry /CN=disroot.org (preverify: 0 skipmode: 0) [2023-04-25 12:15:23] X509_verify_cert: unable to get local issuer certificate (20) [2023-04-25 12:15:24] Certificate saved [2023-04-25 12:15:25] ssl_cache_trusted_cert: trusted [2023-04-25 12:15:25] ssl interactive_check_cert: done=2 [2023-04-25 12:15:25] TLSv1.3 connection using TLSv1/SSLv3 (TLS_AES_256_GCM_SHA384) [2023-04-25 12:15:26] Connected to disroot.org:993 on fd=4 And this is the scenario where the certificate exists in the file [2023-04-25 12:15:35] Looking up disroot.org... [2023-04-25 12:15:35] Connecting to disroot.org... [2023-04-25 12:15:35] ssl_load_certificates: loading trusted certificates [2023-04-25 12:15:35] SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed [2023-04-25 12:15:36] Connected to disroot.org:993 on fd=-1 [2023-04-25 12:15:37] mutt_index_menu[831]: Got op 102 [2023-04-25 12:15:37] mutt_buffer_pool_free: 15 of 15 returned to pool It seems libressl has had problems with certificate chains before.
[PATCH v3] Add socket send/receive timeout options
On an unreliable connection (e.g., laptop put to sleep and changing wifi
networks) I've had mutt fairly regularly become stuck in SSL_read and
have to be killed.
Per some of the comments on
https://stackoverflow.com/questions/46517875/ssl-read-blocks-indefinitely
adding a timeout to the socket should carry over to the SSL_read call.
Using this socket_receive_timeout option appears to resolve the issue
for me.
Signed-off-by: Matthew Sotoudeh
---
Thanks all for the comments!
Changelog:
* Add socket_ prefix and socket_send_timeout option per Kevin, Petr
suggestions
* Wrap the init.h, global.h additions in #ifdef USE_SOCKET (I think
that flag should control compilation of mutt_socket.c as well?)
I decided to stick to the < 0 check for consistency with the rest of the
code (as noted). From my reading of the man pages, setsockopt is
supposed to return either 0 or -1, so < 0 is already a
broader-than-necessary check, if anything. But happy to revise that if
others have strong preferences.
globals.h | 2 ++
init.h| 16
mutt_socket.c | 16
3 files changed, 34 insertions(+)
diff --git a/globals.h b/globals.h
index 06ce410e..3f22ad35 100644
--- a/globals.h
+++ b/globals.h
@@ -103,6 +103,8 @@ WHERE char *MsgFmt;
WHERE char *Preconnect;
WHERE char *Tunnel;
WHERE short NetInc;
+WHERE short SocketReceiveTimeout;
+WHERE short SocketSendTimeout;
#endif /* USE_SOCKET */
#ifdef MIXMASTER
diff --git a/init.h b/init.h
index e160d3d3..ea0bb975 100644
--- a/init.h
+++ b/init.h
@@ -4150,6 +4150,22 @@ struct option_t MuttVars[] = {
** Also see $$write_bcc.
*/
#endif /* USE_SMTP */
+#ifdef USE_SOCKET
+ { "socket_receive_timeout", DT_NUM, R_NONE, {.p=&SocketReceiveTimeout},
{.l=0} },
+ /*
+ ** .pp
+ ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) after
+ ** this many seconds. A zero (default) or negative value causes Mutt to wait
+ ** indefinitely for the read to complete.
+ */
+ { "socket_send_timeout", DT_NUM, R_NONE, {.p=&SocketSendTimeout}, {.l=0} },
+ /*
+ ** .pp
+ ** Causes Mutt to timeout any socket write operation (e.g. SSL_write) after
+ ** this many seconds. A zero (default) or negative value causes Mutt to wait
+ ** indefinitely for the write to complete.
+ */
+#endif /* USE_SOCKET */
{ "sort",DT_SORT, R_INDEX|R_RESORT, {.p=&Sort}, {.l=SORT_DATE} },
/*
** .pp
diff --git a/mutt_socket.c b/mutt_socket.c
index 3e192072..898faa07 100644
--- a/mutt_socket.c
+++ b/mutt_socket.c
@@ -433,6 +433,22 @@ static int socket_connect (int fd, struct sockaddr* sa)
save_errno = 0;
+ if (SocketReceiveTimeout > 0)
+ {
+struct timeval tv = { SocketReceiveTimeout, 0 };
+if (setsockopt (fd, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(tv)) < 0)
+ dprint (1, (debugfile, "socket_connect: error setting receive timeout
(%s)\n",
+ strerror(errno)));
+ }
+
+ if (SocketSendTimeout > 0)
+ {
+struct timeval tv = { SocketSendTimeout, 0 };
+if (setsockopt (fd, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv, sizeof(tv)) < 0)
+ dprint (1, (debugfile, "socket_connect: error setting send timeout
(%s)\n",
+ strerror(errno)));
+ }
+
if (connect (fd, sa, sa_size) < 0)
{
save_errno = errno;
--
2.34.1
Re: [PATCH v2] Add a receive_timeout option for sockets
On Tue, Nov 29, 2022 at 11:35:11AM -0800, Kevin J. McCarthy wrote: > On Tue, Nov 29, 2022 at 02:19:26PM +0100, Oswald Buddenhagen wrote: > > On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev > > wrote: > > > + ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) > > > after > > > + ** this many seconds. A zero (default) or negative value causes Mutt > > > to wait > > > + ** indefinitely for the read to complete. > > > > > have you checked how this plays along with imap IDLE? > > Thanks Oswald. I'll take a closer look before committing, but I don't think > it should have a particular effect, at least for Mutt's implementation. > Mutt sends IDLE, polls the socket for up to $imap_poll_timeout, and then > reads looking for the "+" response. It's possible I'm not exercising all corner cases here, but to add some empirical data: just tried running this patch with imap_idle and a relatively small receive_timeout for a bit, and didn't notice any difference in behavior. Even with receive_timeout=0, imap_idle=yes, my Mutt config only seems to (intentionally) do long-blocking reads on stdin/waiting for user input. imap_check_mailbox sets up the idle with the server and returns quickly after that, with or without receive_timeout. Thanks for all the feedback, Matthew
Re: [PATCH v2] Add a receive_timeout option for sockets
Thanks for pointing that out ! To second Kevin's comments below, I personally didn't find a SNDTIMEO necessary. Also worth noting that, at least in my case, large writes (sending email, etc.) happen while I'm sitting down, so a much more stable network connection vs., e.g., background downloading of new mail. Happy to add a SO_SNDTIMEO while we're at it just in case/for consistency, though, if people prefer that. Best, Matthew On Tue, Nov 29, 2022 at 11:28:29AM -0800, Kevin J. McCarthy wrote: > On Tue, Nov 29, 2022 at 09:44:25AM +0100, Petr Pisar wrote: > > If a network is unreliable, you will have similar problem with writing > > to the TCP socket. I think it would be better to rename the option to > > socket_timeout and use the same value for both setsockopt(, SO_RCVTIMEO, ) > > and > > setsockopt(, SO_SNDTIMEO, ). > > Thanks for your feedback Petr. In my experience, I've found that writing > (small amounts) to a "hung" socket doesn't seem to be a problem - the > computer buffers it or something; it's trying to read the response back that > hangs. The $imap_poll_timeout code works in that way, at least, sending a > NOOP and polling those seconds for a response. > > If that's not always the case then we can add a SNDTIMEO too. > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
[PATCH v2] Add a receive_timeout option for sockets
On an unreliable connection (e.g., laptop put to sleep and changing wifi
networks) I've had mutt fairly regularly become stuck in SSL_read and
have to be killed.
Per some of the comments on
https://stackoverflow.com/questions/46517875/ssl-read-blocks-indefinitely
adding a timeout to the socket should carry over to the SSL_read call.
Using this receive_timeout option appears to resolve the issue for me,
thought others may find it useful.
Signed-off-by: Matthew Sotoudeh
---
Thanks for the great tips! Hope this is a bit nicer formatted :)
(Also, happy to move to gitlab if preferable & more changes desired for
this. Sent here just bc doc/devel-notes.txt suggested.)
Changelog per recent David/Kevin suggestions:
* move setsockopt to right before the connect
* check return value of setsockopt, log the error if it fails
globals.h | 1 +
init.h| 7 +++
mutt_socket.c | 8
3 files changed, 16 insertions(+)
diff --git a/globals.h b/globals.h
index 06ce410e..b782114e 100644
--- a/globals.h
+++ b/globals.h
@@ -236,6 +236,7 @@ WHERE short PagerContext;
WHERE short PagerIndexLines;
WHERE short PagerSkipQuotedContext;
WHERE short ReadInc;
+WHERE short ReceiveTimeout;
WHERE short ReflowWrap;
WHERE short SaveHist;
WHERE short SendmailWait;
diff --git a/init.h b/init.h
index e160d3d3..e268d796 100644
--- a/init.h
+++ b/init.h
@@ -3221,6 +3221,13 @@ struct option_t MuttVars[] = {
** .pp
** Also see $$postponed variable.
*/
+ { "receive_timeout", DT_NUM, R_NONE, {.p=&ReceiveTimeout}, {.l=0} },
+ /*
+ ** .pp
+ ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) after
+ ** this many seconds. A zero (default) or negative value causes Mutt to wait
+ ** indefinitely for the read to complete.
+ */
{ "record", DT_PATH, R_NONE, {.p=&Outbox}, {.p="~/sent"} },
/*
** .pp
diff --git a/mutt_socket.c b/mutt_socket.c
index 3e192072..9468319e 100644
--- a/mutt_socket.c
+++ b/mutt_socket.c
@@ -433,6 +433,14 @@ static int socket_connect (int fd, struct sockaddr* sa)
save_errno = 0;
+ if (ReceiveTimeout > 0)
+ {
+struct timeval tv = { ReceiveTimeout, 0 };
+if (setsockopt (fd, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(tv)) < 0)
+ dprint (1, (debugfile, "socket_connect: error setting receive timeout
(%s)\n",
+ strerror(errno)));
+ }
+
if (connect (fd, sa, sa_size) < 0)
{
save_errno = errno;
--
2.34.1
[PATCH] Updated: add a receive_timeout option for sockets
Per feedback from Kevin & David (thanks!), moved the timeout code into
socket_connect and updated the description to be more descriptive and
more closely match the existing connect_timeout.
There is some open question about where exactly in socket_connect to put
the timeout code. Currently I put it after the basic input validation
but it may be slightly better to wait until the socket is actually
opened? But being a global option anyways, I don't think it can hurt
anything.
Signed-off-by: Matthew Sotoudeh
---
globals.h | 1 +
init.h| 7 +++
mutt_socket.c | 6 ++
3 files changed, 14 insertions(+)
diff --git a/globals.h b/globals.h
index 06ce410e..b782114e 100644
--- a/globals.h
+++ b/globals.h
@@ -236,6 +236,7 @@ WHERE short PagerContext;
WHERE short PagerIndexLines;
WHERE short PagerSkipQuotedContext;
WHERE short ReadInc;
+WHERE short ReceiveTimeout;
WHERE short ReflowWrap;
WHERE short SaveHist;
WHERE short SendmailWait;
diff --git a/init.h b/init.h
index e160d3d3..e268d796 100644
--- a/init.h
+++ b/init.h
@@ -3221,6 +3221,13 @@ struct option_t MuttVars[] = {
** .pp
** Also see $$postponed variable.
*/
+ { "receive_timeout", DT_NUM, R_NONE, {.p=&ReceiveTimeout}, {.l=0} },
+ /*
+ ** .pp
+ ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) after
+ ** this many seconds. A zero (default) or negative value causes Mutt to wait
+ ** indefinitely for the read to complete.
+ */
{ "record", DT_PATH, R_NONE, {.p=&Outbox}, {.p="~/sent"} },
/*
** .pp
diff --git a/mutt_socket.c b/mutt_socket.c
index 3e192072..4e1b7889 100644
--- a/mutt_socket.c
+++ b/mutt_socket.c
@@ -407,6 +407,12 @@ static int socket_connect (int fd, struct sockaddr* sa)
return -1;
}
+ if (ReceiveTimeout > 0)
+ {
+struct timeval tv = { ReceiveTimeout, 0 };
+setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(tv));
+ }
+
/* Batch mode does not call mutt_signal_init(), so ensure the alarm
* interrupts the connect call */
if (ConnectTimeout > 0)
--
2.34.1
[PATCH] Add a receive_timeout option for sockets
On an unreliable connection (e.g., laptop put to sleep and changing wifi
networks) I've had mutt fairly regularly become stuck in SSL_read and
have to be killed.
Per some of the comments on
https://stackoverflow.com/questions/46517875/ssl-read-blocks-indefinitely
adding a timeout to the socket should carry over to the SSL_read call.
Using this receive_timeout option appears to resolve the issue for me,
thought others may find it useful.
Signed-off-by: Matthew Sotoudeh
---
globals.h | 1 +
init.h| 6 ++
mutt_socket.c | 5 +
3 files changed, 12 insertions(+)
diff --git a/globals.h b/globals.h
index 06ce410e..b782114e 100644
--- a/globals.h
+++ b/globals.h
@@ -236,6 +236,7 @@ WHERE short PagerContext;
WHERE short PagerIndexLines;
WHERE short PagerSkipQuotedContext;
WHERE short ReadInc;
+WHERE short ReceiveTimeout;
WHERE short ReflowWrap;
WHERE short SaveHist;
WHERE short SendmailWait;
diff --git a/init.h b/init.h
index e160d3d3..f701c9a7 100644
--- a/init.h
+++ b/init.h
@@ -3221,6 +3221,12 @@ struct option_t MuttVars[] = {
** .pp
** Also see $$postponed variable.
*/
+ { "receive_timeout", DT_NUM, R_NONE, {.p=&ReceiveTimeout}, {.l=0} },
+ /*
+ ** .pp
+ ** Receive timeout (in seconds) to set on opened sockets. Zero (default)
+ ** means no timeout.
+ */
{ "record", DT_PATH, R_NONE, {.p=&Outbox}, {.p="~/sent"} },
/*
** .pp
diff --git a/mutt_socket.c b/mutt_socket.c
index 3e192072..28c56996 100644
--- a/mutt_socket.c
+++ b/mutt_socket.c
@@ -617,6 +617,11 @@ int raw_socket_open (CONNECTION* conn)
fd = socket (cur->ai_family, cur->ai_socktype, cur->ai_protocol);
if (fd >= 0)
{
+ if (ReceiveTimeout > 0)
+ {
+ struct timeval tv = { ReceiveTimeout, 0 };
+ setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(tv));
+ }
if ((rc = socket_connect (fd, cur->ai_addr)) == 0)
{
fcntl (fd, F_SETFD, FD_CLOEXEC);
--
2.34.1
Re: [PATCH] bugfix for handling incomplete IMAP header cache
On Sat, Aug 21, 2021 at 12:50:20PM -0700, Kevin J. McCarthy wrote: > On Sat, Aug 21, 2021 at 09:32:11PM +0200, Pieter-Tjerk de Boer via Mutt-dev > wrote: > > in RFC3501, > > section 2.3.1.2, the MSN is described as "A relative position from 1 to > > the number of messages in the mailbox". This implies there can be no > > holes, or am I overlooking something? > > This was observed in Trac ticket 3942: > <https://gitlab.com/muttmua/trac-tickets/-/blob/master/tickets/closed/3942-mutt_with_hanging_on_large_Exchange_Deleted_Messages_folder.txt> Ouch, that seems a rather severely broken IMAP server implementation then. The assumption, made by mutt and discussed in that ticket, namely that the MSNs are consecutive and can't exceed the message count, is in fact well supported by the RFC: not just by the sentence I quoted but also by the further examples given in that RFC. > > But I think it wouldn't solve the problem that the unsuccesfully-deleted > > message jumps to a different position in the unsorted mailbox view. > > I understand, but I don't think unsorted makes a particular promise here. > It just reflects the messages as they are assembled into the index. Well, as a user, I would expect 'unsorted' to match the order the messages have on the IMAP server. This is practically useful, as it ensures that the latest additions to the mailbox are all together at the end. Could we solve this by applying my previous patch, and adding a check at the end that the index values (derived from MSN as per my patch) are in fact consecutive, and modifying them as needed? This check would only need to be done if an MSN has been seen that's larger than the message count. If you agree, I'd be willing to write the code for this, but I don't have a broken IMAP server to test against... On Sat, Aug 21, 2021 at 01:21:37PM -0700, Kevin J. McCarthy wrote: > I've pushed up two commits to branch kevin/stable-imap-header-cache-hole on > gitlab. > <https://gitlab.com/muttmua/mutt/-/commits/kevin/stable-imap-header-cache-hole>. > The first is your msn_begin fix commit and the second is a currently > untested commit changing the sort order before generating msgset strings. Nice! For what it's worth, I tested it the same way as I tested my own earlier patch (triggering the bug by temporarily making the IMAP server unreachable), and it works okay in that case. Regards, Pieter-Tjerk
Re: [PATCH] bugfix for handling incomplete IMAP header cache
On Sat, Aug 21, 2021 at 07:15:12AM -0700, Kevin J. McCarthy wrote: > On Sat, Aug 21, 2021 at 11:35:19AM +0200, Pieter-Tjerk de Boer via Mutt-dev wr > > This bug isn't just cosmetic; it can lead to unintended deletion of > > large amounts of mails. > > I'm very sorry to hear about the loss of email. That's the most terrible > bug there can be. :-( Thanks; indeed, I was not amused, and that's an understatement... :-( > > Fortunately, fixing this is trivial; at two places in imap/message.c, > > replace > >ctx->hdrs[idx]->index = idx; > > by > >ctx->hdrs[idx]->index = h.data->msn-1; > > Unfortunately I don't think this is the correct fix. There can in fact be > holes in the MSN sequence. I'm by no means an IMAP or mutt code expert (never touch mutt code, nor studied the IMAP RFCs, until trying to fix this bug), but in RFC3501, section 2.3.1.2, the MSN is described as "A relative position from 1 to the number of messages in the mailbox". This implies there can be no holes, or am I overlooking something? > I think a better fix would be changing the sort order to use UID instead > when creating the msgset, Indeed, that would be a more robust solution to the message delete problem, as it then no longer relies on MSN and UID being monotonically related. But I think it wouldn't solve the problem that the unsuccesfully-deleted message jumps to a different position in the unsorted mailbox view. Regards, Pieter-Tjerk
[PATCH] bugfix for handling incomplete IMAP header cache
The below patch fixes mutt's IMAP message number handling in case it is started with a header cache in which a mail somewhere "in the middle" is missing (i.e., the cache does contain a mail later than the one that is missing). This bug isn't just cosmetic; it can lead to unintended deletion of large amounts of mails. Let me give a step-by-step example of what went wrong and how that could lead to losing mail: 0. Use mutt with IMAP, header caching enabled, but not CONDSTORE nor QRESYNC. 1. Open an IMAP mailbox with e.g. 5 mails in it, with e.g. UIDs 11...15. 2. Mark the 3rd mail, UID=13, for deletion. 3. Give the sync-mailbox command; mutt immediately deletes the mail from the header cache and tells the IMAP server to also delete it. 4. Assume that the server does not actually do the synchronization; this could e.g. happen due to a network problem, or the server could simply say "NO" (as the server I'm using sometimes does). Now the mail with UID=13 is missing from the header cache, but it is still on the server. 5. Exit and restart mutt. 6. Mutt will first populate its view of the mailbox from its header cache, then request headers for the missing UID=13 mail, and _append_ the UID=13 mail after the other mails. So in mutt's view the mailbox contains UIDs in the order 11,12,14,15,13. Note that this order violates the IMAP specification (and assumption in the code) that UIDs are monotonically increasing. 7. The user sees that mail 13 has jumped to the end of the mailbox, if not otherwise sorted; this may be confusing or surprising, but by itself it's not a serious problem. 8. Assume a new mail arrives, with UID 16. In mutt's view, the mailbox now contains UIDs 11,12,14,15,13,16. 9. Mark mails 13 and 16 for deletion. 10. Give the sync-mailbox command. In mutt's view, the two mails to be deleted are consecutive in mailbox order, and therefore it will tell the server to delete the entire UID range 13:16 . 11. Sadly, this inadvertently also deletes mails 14 and 15 ! This is not just theory. I've several times lost hundreds of mails due to (presumably) this bug (though of course I wasn't yet aware of exactly what was happening). Fortunately, fixing this is trivial; at two places in imap/message.c, replace ctx->hdrs[idx]->index = idx; by ctx->hdrs[idx]->index = h.data->msn-1; I.e., instead of writing the array index into the index field, write the correct message number into it; this field is defined as "the absolute (unsorted) message number" in mutt.h. I also checked what happens if CONDSTORE and QRESYNC are enabled. In that case, verify_qresync() notices that the quick resync didn't work correctly, but the subsequent attempt at a normal resync fails in a different way: it doesn't fetch the headers for the missing mail. To the user, it then looks as if the mail is no longer in the mailbox, even though the server still has it. The below patch fixes this too. Regards, Pieter-Tjerk --- imap/message.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/imap/message.c b/imap/message.c index 103e48e5..42a9414d 100644 --- a/imap/message.c +++ b/imap/message.c @@ -240,6 +240,7 @@ int imap_read_headers (IMAP_DATA* idata, unsigned int msn_begin, unsigned int ms void *pmodseq = NULL; unsigned long long hc_modseq = 0; char *uid_seqset = NULL; + unsigned int msn_begin_original = msn_begin; #endif /* USE_HCACHE */ ctx = idata->ctx; @@ -357,6 +358,7 @@ retry: FREE (&uid_seqset); uid_validity = 0; uidnext = 0; + msn_begin = msn_begin_original; goto retry; } @@ -509,7 +511,7 @@ static int read_headers_normal_eval_cache (IMAP_DATA *idata, idata->msn_index[h.data->msn - 1] = ctx->hdrs[idx]; int_hash_insert (idata->uid_hash, h.data->uid, ctx->hdrs[idx]); -ctx->hdrs[idx]->index = idx; +ctx->hdrs[idx]->index = h.data->msn - 1; /* messages which have not been expunged are ACTIVE (borrowed from mh * folders) */ ctx->hdrs[idx]->active = 1; @@ -943,7 +945,7 @@ static int read_headers_fetch_new (IMAP_DATA *idata, unsigned int msn_begin, idata->msn_index[h.data->msn - 1] = ctx->hdrs[idx]; int_hash_insert (idata->uid_hash, h.data->uid, ctx->hdrs[idx]); -ctx->hdrs[idx]->index = idx; +ctx->hdrs[idx]->index = h.data->msn - 1; /* messages which have not been expunged are ACTIVE (borrowed from mh * folders) */ ctx->hdrs[idx]->active = 1; -- 2.20.1
[PATCH] Generate version string during make not configure
I've been using this in my personal build for a long time, according to the author date on the commit it's been at least since 2012. I've submitted it once before as part of a series to support getting the version information from git back when the official version control was still in mercurial. I figure that it's pays to resend it. 8<-- Switch to generating the version string during make process rather than at configure time. This makes it easier to keep the detailed version string accurate when doing development which doesn't require that the configure script be rerun. --- .gitignore | 1 + Makefile.am | 7 ++- commands.c | 1 + compose.c| 1 + configure.ac | 3 --- dotlock.c| 1 + init.c | 1 + muttlib.c| 1 + sendlib.c| 1 + status.c | 1 + 10 files changed, 14 insertions(+), 4 deletions(-) diff --git a/.gitignore b/.gitignore index 2cec7439c..ee5a93606 100644 --- a/.gitignore +++ b/.gitignore @@ -44,6 +44,7 @@ /smime_keys /txt2c /stamp-doc-rc +/version.h /doc/instdoc /doc/manual.txt /doc/manual.xml diff --git a/Makefile.am b/Makefile.am index c95c21a2a..92edce221 100644 --- a/Makefile.am +++ b/Makefile.am @@ -22,7 +22,7 @@ if BUILD_HCACHE HCVERSION = hcversion.h endif -BUILT_SOURCES = keymap_defs.h patchlist.c reldate.h conststrings.c $(HCVERSION) +BUILT_SOURCES = keymap_defs.h patchlist.c reldate.h conststrings.c version.h $(HCVERSION) bin_PROGRAMS = mutt $(DOTLOCK_TARGET) $(PGPAUX_TARGET) mutt_SOURCES = \ @@ -140,6 +140,11 @@ keymap_alldefs.h: $(srcdir)/OPS $(srcdir)/OPS.SIDEBAR $(srcdir)/OPS.PGP $(srcdir $(srcdir)/OPS.MIX $(srcdir)/OPS.CRYPT $(srcdir)/OPS.SMIME \ > keymap_alldefs.h +version.h: FORCE + echo '#define MUTT_VERSION "'`sh "$(srcdir)/version.sh"`'"' > $@.tmp + cmp -s $@ $@.tmp && rm -f $@.tmp || mv $@.tmp $@ +FORCE: + reldate.h: $(srcdir)/mkreldate.sh $(srcdir)/ChangeLog echo 'const char *ReleaseDate = "'`(cd $(srcdir) && ./mkreldate.sh)`'";' > reldate.h diff --git a/commands.c b/commands.c index cd65a0d21..a94962ad2 100644 --- a/commands.c +++ b/commands.c @@ -21,6 +21,7 @@ # include "config.h" #endif +#include "version.h" #include "mutt.h" #include "mutt_curses.h" #include "mutt_menu.h" diff --git a/compose.c b/compose.c index 6ca9c5a12..367c25588 100644 --- a/compose.c +++ b/compose.c @@ -21,6 +21,7 @@ # include "config.h" #endif +#include "version.h" #include "mutt.h" #include "mutt_curses.h" #include "mutt_idna.h" diff --git a/configure.ac b/configure.ac index d8aebe336..59d25207c 100644 --- a/configure.ac +++ b/configure.ac @@ -10,9 +10,6 @@ AC_CONFIG_HEADERS([config.h]) AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/VERSION']) -MUTT_VERSION=`env sh "$srcdir/version.sh"` -AC_DEFINE_UNQUOTED(MUTT_VERSION,"$MUTT_VERSION", [Full textual version string.]) - AC_USE_SYSTEM_EXTENSIONS ALL_LINGUAS="de eu ru it es uk fr pl nl cs id sk ko el zh_TW zh_CN pt_BR eo gl sv da lt tr ja hu et ca bg ga fi" diff --git a/dotlock.c b/dotlock.c index 5bf03480a..9dd958ad2 100644 --- a/dotlock.c +++ b/dotlock.c @@ -46,6 +46,7 @@ #include #endif +#include "version.h" #include "dotlock.h" #ifdef HAVE_GETOPT_H diff --git a/init.c b/init.c index e5c78961c..a9cb2821f 100644 --- a/init.c +++ b/init.c @@ -20,6 +20,7 @@ # include "config.h" #endif +#include "version.h" #include "mutt.h" #include "mapping.h" #include "mutt_curses.h" diff --git a/muttlib.c b/muttlib.c index 7789479c0..5e25c10d9 100644 --- a/muttlib.c +++ b/muttlib.c @@ -21,6 +21,7 @@ # include "config.h" #endif +#include "version.h" #include "mutt.h" #include "mutt_curses.h" #include "mime.h" diff --git a/sendlib.c b/sendlib.c index 2128c94ef..28da96403 100644 --- a/sendlib.c +++ b/sendlib.c @@ -22,6 +22,7 @@ # include "config.h" #endif +#include "version.h" #include "mutt.h" #include "mutt_curses.h" #include "rfc2047.h" diff --git a/status.c b/status.c index a069072fe..1c6b0353f 100644 --- a/status.c +++ b/status.c @@ -20,6 +20,7 @@ # include "config.h" #endif +#include "version.h" #include "mutt.h" #include "mutt_menu.h" #include "mutt_curses.h" -- 2.20.1.613.g9968bcf4fb
[PATCH] Add format attribute for buffer_printf functions
Let compilers know that `mutt_buffer_printf()` and `mutt_buffer_add_printf()` expect the second argument to be a `printf`-style format string with the arguments for the format starting at the third argument. This allows warnings to be shown if these are incorrect. --- buffer.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/buffer.h b/buffer.h index 3312ad866..22bb68b8f 100644 --- a/buffer.h +++ b/buffer.h @@ -42,10 +42,12 @@ void mutt_buffer_increase_size (BUFFER *, size_t); void mutt_buffer_fix_dptr (BUFFER *); /* These two replace the buffer contents. */ +__attribute__((format (printf,2,3))) int mutt_buffer_printf (BUFFER*, const char*, ...); void mutt_buffer_strcpy (BUFFER *, const char *); /* These append to the buffer. */ +__attribute__((format (printf,2,3))) int mutt_buffer_add_printf (BUFFER*, const char*, ...); void mutt_buffer_addstr (BUFFER*, const char*); void mutt_buffer_addch (BUFFER*, char); -- 2.20.1.613.g9968bcf4fb
Re: [Mutt] #3518: IDNA2008 support by libidn2 usage in mutt
#3518: IDNA2008 support by libidn2 usage in mutt --+-- Reporter: rsc | Owner: mutt-dev Type: enhancement | Status: new Priority: major| Milestone: 2.0 Component: mutt |Version: Resolution: | Keywords: --+-- Old description: > At the moment, mutt only has IDNA2003 support by GNU libidn. As IDNA2003 > was updated, changed and revised by IDNA2008, there's now GNU libidn2. > Unfortunately IDNA2003 and IDN2008 are very different, thus the new > library is also very different. Nevertheless I would like to see IDNA2008 > support in mutt. > > As it is hard (and makes less to no sense) to support IDNA2003 and > IDNA2008 in parallel, I would recommend to replace IDNA2003 by IDNA2008 > support, which means that the requirement in the end switches over from > libidn to libidn2 simply. > > GNU libidn2 upstream is http://www.gnu.org/s/libidn/#libidn2, the latest > version at the moment is 0.5. New description: At the moment, mutt only has IDNA2003 support by GNU libidn. As IDNA2003 was updated, changed and revised by IDNA2008, there's now GNU libidn2. Unfortunately IDNA2003 and IDN2008 are very different, thus the new library is also very different. Nevertheless I would like to see IDNA2008 support in mutt. As it is hard (and makes less to no sense) to support IDNA2003 and IDNA2008 in parallel, I would recommend to replace IDNA2003 by IDNA2008 support, which means that the requirement in the end switches over from libidn to libidn2 simply. GNU libidn2 upstream is http://www.gnu.org/s/libidn/#libidn2, the latest version at the moment is 0.5. -- Comment (by kevin8t8): Hi mmuzila, Sorry for my delay in replying. Would you mind opening a pull request in our gitlab project? Thank you! -Kevin -- Ticket URL: <https://dev.mutt.org/trac/ticket/3518#comment:3> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str
--+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: closed
Priority: major| Milestone:
Component: mutt |Version:
Resolution: fixed| Keywords:
--+--
Comment (by kevin8t8):
Interesting. When I tested, I saw in the index.
However, I do notice the month and day are off; I think exactly because of
the reason you say: Mutt's algorithm and localtime()'s diverge.
This is likely why we were getting the segv even though the input year was
less than {{{INT_MAX}}} - the divergence at such a large year grows big
enough that localtime() converts it back to something greater than that.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3990#comment:7>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: Resolution: fixed| Keywords: --+-- Comment (by vinc17): For the example, I get year 1 instead of . Could this be due to the incorrect leap years (the algorithm is valid up to 2099)? And could there be obscure bugs due to the fact that this algorithm is used with unsupported years? -- Ticket URL: <https://dev.mutt.org/trac/ticket/3990#comment:6> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str
--+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: closed
Priority: major| Milestone:
Component: mutt |Version:
Resolution: fixed| Keywords:
--+--
Changes (by kevin8t8):
* status: new => closed
* resolution: => fixed
Comment:
I've added commits 189e52d5 and 2a857f63 to the stable branch, which will
be included in the next stable release. (Likely in the next couple weeks).
These address the direct issues causing the segfault: in this case the
large year, despite being less than {{{INT_MAX}}}, was still causing
{{{localtime}}} to return NULL. I've added a cap at .
As noted in #3989, the larger issue of improving gmtime() and localtime()
error handling has been added to a gitlab ticket
https://gitlab.com/muttmua/mutt/issues/11
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3990#comment:5>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3989: segfault in mutt_local_tz
#3989: segfault in mutt_local_tz --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: Resolution: fixed| Keywords: --+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: I've added commits 189e52d5 and 2a857f63 to the stable branch, which will be included in the next stable release. (Likely in the next couple weeks). These address the direct issues causing the segfault: in this case is_from() parsing was not checking the range of the year, and passed a negative year into mutt_mktime(). I've changed it to behave like mutt_parse_date(), which rejects values outside of the int range, causing the header line to be ignored. Because the invalid date is part of the From separator, that means the message will no longer be seen in the mbox. The larger issue of improving gmtime() and localtime() error handling I've added to a gitlab ticket https://gitlab.com/muttmua/mutt/issues/11 Thank you again for opening this ticket. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3989#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str
--+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version:
Resolution: | Keywords:
--+--
Comment (by vinc17):
The bug is in Mutt: it doesn't check whether {{{localtime}}} or
{{{gmtime}}} succeeds. POSIX says: "If an error is detected, gmtime()
shall return a null pointer". But Mutt passes {{{tm}}} to {{{strftime}}}
without checking whether it is a null pointer. So there are two issues.
1. Check whether {{{tm}}} is a null pointer. I don't know what should be
done in such a case. If the second issue is solved, this should never
happen. Perhaps exit with an error message giving information about the
time that lead to this error.
2. Make sure that the time is always representable in a {{{tm}}}
structure. The maximum year for the {{{tm}}} structure is mathematically
1900 + {{{INT_MAX}}}. But for simplicity, {{{INT_MAX}}} would also be OK
(thus the year could always be represented in an {{{int}}} if need be,
even without the 1900 offset). Capping the value to would be OK too,
I assume, with the advantage that the year would always be representable
on 4 digits, thus avoiding potential display issues.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3990#comment:4>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3518: IDNA2008 support by libidn2 usage in mutt
#3518: IDNA2008 support by libidn2 usage in mutt --+-- Reporter: rsc | Owner: mutt-dev Type: enhancement | Status: new Priority: major| Milestone: 2.0 Component: mutt |Version: Resolution: | Keywords: --+-- Comment (by mmuzila): Hi, I would like to ask what is the current status of libidn2 support in Mutt. I've already created a patch <1> that makes mutt to use libidn2 instead of libidn. <1> https://gitlab.com/mmuzila/mutt/commit/b53167669ff46f65d39f801130a53b4387b37125 -- Ticket URL: <https://dev.mutt.org/trac/ticket/3518#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str
--+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version:
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
One fix would be to add an additional range check in mutt_mktime() below
the TM_YEAR_MAX check. Something like:
{{{
/* 64-bit platforms can theoretically hold a very large year, but other
system
* calls such as strftime() and gmtime() error out on large year values.
* Cap the value at year .
*/
if (t->tm_year > -1900)
t->tm_year = -1900;
}}}
I think the TM_YEAR_MAX check is still needed for 32-bit time_t platforms,
so this would be in addition.
I believe this would also "fix" #3989 although I think we should still add
a NULL check there for correctness.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3990#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: Resolution: fixed| Keywords: --+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: Thank you Vincent. Also, thank you Joseph for reporting these issues. I apologize for my terse comment - looking again I realize I sounded like an ass. I saw the range checks just below, but didn't look closely enough that the size of and current location in the mbox matters too. I'm indisposed this week, so haven't had any time to address those yet, but will soon. Thanks again. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3988#comment:6> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Comment (by vinc17): OK on both points. The bug is now fixed in the master branch, assuming that the mailbox size is less than twice the maximum signed offset, which is necessarily true on 64-bit in practice. And on 32-bit, the mbox file has to be huge (more than 1 GB), but this is controlled by the user and there may be other issues with such a huge mailbox on 32-bit (e.g. lack of address space or other limitation). So I suppose that this fix is sufficient in practice. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3988#comment:5> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox
--+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version:
Resolution: | Keywords:
--+--
Comment (by josephbisch):
Regarding comment #3, I don't think it is very plausible in practice.
There is the check for the content-length being > 0, so the content-length
can't be so huge such that it wraps around by itself. So {{{loc}}} has to
be large. So the overall filesize of the mbox has to be large. Maybe on
32-bit, but we are still talking about a huge mbox file.
Regarding comment #2, a website could purposefully provide a specially
crafted mbox file, so it doesn't necessarily mean a bug is not a big
problem because the file itself is invalid. Though this bug probably isn't
a big problem for the reason I outlined in the first paragraph of this
comment.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3988#comment:4>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox
--+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version:
Resolution: | Keywords:
--+--
Comment (by vinc17):
Moreover, I suppose that without ubsan, there could be an issue if due to
a huge content-length and wrapping, {{{tmploc}}} would point to a "From "
of a previous mail, so that the content-length would incorrectly be
regarded as valid. I haven't tried, but if this is possible, this could be
bad.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3988#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Comment (by vinc17): I think that the attached patch should fix the problem in practice. Now, this may not be a big problem since an invalid content-length means that the user has edited the mbox file with a text editor or there is a bug in some software. Note: Obviously, MDA's should remove the "Content-Length:" header if invalid otherwise there is a risk of mail loss (for instance, if a second message is received and the content-length points just after this second message, so that the second message is regarded as part of the first message, which could be a spam). -- Ticket URL: <https://dev.mutt.org/trac/ticket/3988#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Changes (by vinc17): * Attachment "bug3988.patch" added. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3988> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Comment (by kevin8t8): Wait, looking at mutt_mktime, we had this debate before, and chose to cap it at TM_YEAR_MAX. So it doesn't overflow there, but strftime is very unhappy. Doesn't this argue for just limiting the year at something within the realm of a 32-bit int, just to prevent collateral damage? -- Ticket URL: <https://dev.mutt.org/trac/ticket/3990#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Comment (by kevin8t8): This is dying inside libc, but perhaps we should add some reasonable-value year filtering when we are reading in. I'll have to take a look at the header reading code. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3990#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3989: segfault in mutt_local_tz
#3989: segfault in mutt_local_tz --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Comment (by kevin8t8): This is a good catch. We're not checking if gmtime returns NULL. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3989#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Comment (by kevin8t8): I'm really not inclined to care about this much. Vincent? -- Ticket URL: <https://dev.mutt.org/trac/ticket/3988#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Changes (by josephbisch): * Attachment "testcase.mbox" added. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3990> Mutt <http://www.mutt.org/> The Mutt mail user agent
[Mutt] #3990: segfault in hdr_format_str
#3990: segfault in hdr_format_str
-+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version:
Keywords: |
-+--
The attached mbox causes a segfault. The following is from the 20171129
nightly:
{{{
(gdb) bt
#0 0x7f16f1f9601d in __strftime_internal () from /usr/lib/libc.so.6
#1 0x7f16f1f980b6 in strftime_l () from /usr/lib/libc.so.6
#2 0x55973f3eb56c in hdr_format_str (dest=dest@entry=0x7ffe7c67b2e0
"%b %d", destlen=destlen@entry=1024, col=9, cols=cols@entry=211,
op=,
src=0x559740740fa9 "%b %d} %-15.15L (%?l?%4l&%4c?) %s",
prefix=0x7ffe7c67b1e0 "", ifstring=0x7ffe7c67b260 "",
elsestring=0x7ffe7c67b6e0 "LINES", data=140730985593664,
flags=(MUTT_FORMAT_MAKEPRINT | MUTT_FORMAT_ARROWCURSOR |
MUTT_FORMAT_INDEX)) at hdrline.c:424
#3 0x55973f42b8a8 in mutt_FormatString (dest=0x7ffe7c67bb70 " 1 N
", destlen=1023, col=col@entry=0, cols=211, src=,
callback=callback@entry=0x55973f3eb080 ,
data=140730985593664, flags=(MUTT_FORMAT_MAKEPRINT |
MUTT_FORMAT_ARROWCURSOR | MUTT_FORMAT_INDEX)) at muttlib.c:1513
#4 0x55973f3ec5b9 in _mutt_make_string (dest=,
destlen=, s=, ctx=,
hdr=, flags=) at hdrline.c:779
#5 0x55973f3f3d53 in menu_redraw_index
(menu=menu@entry=0x55974074d1e0) at menu.c:263
#6 0x55973f3d28f8 in index_menu_redraw (menu=0x55974074d1e0) at
curs_main.c:521
#7 0x55973f3d2ddd in mutt_index_menu () at curs_main.c:676
#8 0x55973f3ba380 in main (argc=1, argv=,
environ=) at main.c:1252
}}}
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3990>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3989: segfault in mutt_local_tz
#3989: segfault in mutt_local_tz --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Changes (by josephbisch): * Attachment "testcase.mbox" added. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3989> Mutt <http://www.mutt.org/> The Mutt mail user agent
[Mutt] #3989: segfault in mutt_local_tz
#3989: segfault in mutt_local_tz
-+--
Reporter: josephbisch | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version:
Keywords: |
-+--
I received a segfault when using the attached mbox file. The following
corresponds to the 20171129 nightly:
{{{
(gdb) bt
#0 mutt_local_tz (t=, t@entry=-67769428965821859) at
date.c:62
#1 0x55f530fa054b in mbox_parse_mailbox
(ctx=ctx@entry=0x55f533023ae0) at mbox.c:305
#2 0x55f530fa0cb8 in mbox_open_mailbox (ctx=0x55f533023ae0) at
mbox.c:434
#3 0x55f530fa962d in mx_open_mailbox (path=, flags=0,
pctx=0x0) at mx.c:634
#4 0x55f530f69368 in main (argc=1, argv=,
environ=) at main.c:1246
}}}
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3989>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox --+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Resolution: | Keywords: --+-- Changes (by josephbisch): * Attachment "testcase.mbox" added. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3988> Mutt <http://www.mutt.org/> The Mutt mail user agent
[Mutt] #3988: signed integer overflow in mbox_parse_mailbox
#3988: signed integer overflow in mbox_parse_mailbox -+-- Reporter: josephbisch | Owner: mutt-dev Type: defect | Status: new Priority: major| Milestone: Component: mutt |Version: Keywords: | -+-- Using a version of mutt compiled with ubsan, the attached mbox file causes the following output from ubsan: mbox.c:320:15: runtime error: signed integer overflow: 629 + 9223372036854775807 cannot be represented in type 'long' -- Ticket URL: <https://dev.mutt.org/trac/ticket/3988> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3195: mutt-1.5.19: The crash of mutt's pager on messages with quoted text.
#3195: mutt-1.5.19: The crash of mutt's pager on messages with quoted text.
--+--
Reporter: rdna@… | Owner: mutt-dev
Type: defect | Status: closed
Priority: major| Milestone:
Component: mutt |Version:
Resolution: invalid | Keywords:
--+--
Changes (by kevin8t8):
* reporter: Andrey Ignatov => rdna@…
Old description:
> {{{
> Package: mutt
> Version: 1.5.19
> Severity: important
>
> -- Please type your report below this line
>
> Hi;
>
> The mutt had crashed when I try open any messages with the quoted text
> like:
>
>
> However mutt work's normally on messages without quoted text.
>
> -- System Information
> System Version: FreeBSD rdna.yandex.ru 7.1-PRERELEASE FreeBSD
> 7.1-PRERELEASE #2: Mon Feb 9 15:40:24 MSK 2009
> r...@rdna.yandex.ru:/usr/obj/usr/src/sys/RDNA amd64
>
> -- Build environment information
>
> (Note: This is the build environment installed on the system
> muttbug is run on. Information may or may not match the environment
> used to build mutt.)
>
> - gcc version information
> cc -I/usr/local/include
> Using built-in specs.
> Target: amd64-undermydesk-freebsd
> Configured with: FreeBSD/amd64 system compiler
> Thread model: posix
> gcc version 4.2.1 20070719 [FreeBSD]
>
> - CFLAGS
> -pipe -g
>
> -- Mutt Version Information
>
> Mutt 1.5.19 (2009-01-05)
> Copyright (C) 1996-2009 Michael R. Elkins and others.
> Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
> Mutt is free software, and you are welcome to redistribute it
> under certain conditions; type `mutt -vv' for details.
>
> System: FreeBSD 7.1-PRERELEASE (amd64)
> ncurses: ncurses 5.6.20080503 (compiled with 5.6)
> libiconv: 1.11
> libidn: 1.9 (compiled with 1.9)
> hcache backend: Berkeley DB 4.6.21: (September 27, 2007)
> Compile options:
> -DOMAIN
> -DEBUG
> -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE -USE_FCNTL
> +USE_FLOCK
> +USE_POP +USE_IMAP -USE_SMTP
> +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +USE_GSS +HAVE_GETADDRINFO
> +HAVE_REGCOMP -USE_GNU_REGEX +COMPRESSED
> +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
> +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
> +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME
> -CRYPT_BACKEND_GPGME
> -EXACT_ADDRESS -SUN_ATTACHMENT
> +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
> +HAVE_LANGINFO_YESEXPR
> +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE
> -ISPELL
> SENDMAIL="/usr/sbin/sendmail"
> MAILPATH="/var/mail"
> PKGDATADIR="/usr/local/share/mutt"
> SYSCONFDIR="/usr/local/etc"
> EXECSHELL="/bin/sh"
> -MIXMASTER
> To contact the developers, please mail to .
> To report a bug, please visit http://bugs.mutt.org/.
>
> patch-1.5.17.sidebar.20080412
> patch-1.5.7.ust.maildir-mtime.2
> vvv.quote
> patch-1.5.0.ats.date_conditional.1
> dgc.deepif.1
> vvv.initials
> rr.compressed
> patch-1.5.4.cd.ifdef.1
>
> -- Core Dump Analysis Output
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "amd64-marcel-freebsd"...
> Core was generated by `mutt'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libncursesw.so.7...done.
> Loaded symbols for /lib/libncursesw.so.7
> Reading symbols from /usr/lib/libgssapi.so.9...done.
> Loaded symbols for /usr/lib/libgssapi.so.9
> Reading symbols from /usr/lib/libkrb5.so.9...done.
> Loaded symbols for /usr/lib/libkrb5.so.9
> Reading symbols from /usr/lib/libasn1.so.9...done.
> Loaded symbols for /usr/lib/libasn1.so.9
> Reading symbols from /lib/libcrypto.so.5...done.
> Loaded symbols for /lib/libcrypto.so.5
> Reading symbols from /usr/lib/libroken.so.9...done.
> Loaded symbols for /usr/lib/libroken.so.9
> Reading symbols from /lib/libcrypt.so.4...done.
> Loaded symbols for /lib/libcrypt.so.4
> Reading symbols from /usr/lib/libcom_err.so.4...done.
> Loaded symbols for /usr/lib/libcom_err.so.4
> Reading symbols from /usr/lib/libssl.so.5...done.
> Loaded symbols for /usr/lib/libssl.so.5
> Reading symbols from /lib/libz.so.4...done.
> Loaded symbols for /lib/libz.so.4
> Reading symbols from /usr/local/lib/lib
Re: [Mutt] #2900: mutt-1.5.15: Crashes on a mail message in a very wide xterm
#2900: mutt-1.5.15: Crashes on a mail message in a very wide xterm
-+--
Reporter: olav@… | Owner: mutt-dev
Type: defect | Status: closed
Priority: major | Milestone:
Component: mutt|Version:
Resolution: fixed | Keywords:
-+--
Changes (by kevin8t8):
* reporter: Olav Vitters => olav@…
Old description:
> {{{
> Package: mutt
> Version: mutt-1.5.15
> Severity: important
>
> -- Please type your report below this line
> I recompiled Mutt again to avoid problems caused by the patches added
> within the RPM. I reproduced the bug using the command:
> ./mutt -n -F ~/.muttrc2 -f ~/Mail/crash2
>
> the ~/.muttrc2 is attached. ~/Mail/crash2 is a Maildir with one message
> in it. I'll try to attach that message after the bugreport has been
> created..
>
> Note that the crash only occurs if I make the xterm as wide as my screen
> allows (237 columns). Some email messages crash on a smaller xterm
> though.
>
> -- System Information
> System Version: Linux bkor.dhs.org 2.6.21.1-tmb-desktop-1mdvsmp #1 SMP
> Sun May 6 08:58:41 EDT 2007 i686 AMD Athlon(tm) MP 1600+ GNU/Linux
> RedHat Release: Mandriva Linux release 2008.0 (Cooker) for i586
>
> -- Build environment information
>
> (Note: This is the build environment installed on the system
> muttbug is run on. Information may or may not match the environment
> used to build mutt.)
>
> - gcc version information
> gcc
> Using built-in specs.
> Target: i586-mandriva-linux-gnu
> Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-
> slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-
> checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java
> --host=i586-mandriva-linux-gnu --with-cpu=generic --with-system-zlib
> --enable-threads=posix --enable-shared --enable-long-long --enable-
> __cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
> --enable-java-awt=gtk --with-java-
> home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo
> --disable-libjava-multilib --enable-ssp --disable-libssp
> Thread model: posix
> gcc version 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)
>
> - CFLAGS
> -Wall -pedantic -ggdb
>
> -- Mutt Version Information
>
> Mutt 1.5.15 (2007-04-06)
> Copyright (C) 1996-2007 Michael R. Elkins and others.
> Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
> Mutt is free software, and you are welcome to redistribute it
> under certain conditions; type `mutt -vv' for details.
>
> System: Linux 2.6.21.1-tmb-desktop-1mdvsmp (i686)
> ncurses: ncurses 5.5.20051029 (compiled with 5.5)
> libidn: 0.6.9 (compiled with 0.6.9)
> Compile options:
> -DOMAIN
> +DEBUG
> -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
> +USE_FCNTL -USE_FLOCK -USE_INODESORT
> -USE_POP -USE_IMAP -USE_SMTP -USE_GSS -USE_SSL_OPENSSL
> -USE_SSL_GNUTLS -USE_SASL -HAVE_GETADDRINFO
> +HAVE_REGCOMP -USE_GNU_REGEX
> +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
> +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
> +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME
> -CRYPT_BACKEND_GPGME
> -EXACT_ADDRESS -SUN_ATTACHMENT
> +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
> +HAVE_LANGINFO_YESEXPR
> +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID -USE_HCACHE
> ISPELL="/usr/bin/ispell"
> SENDMAIL="/usr/sbin/sendmail"
> MAILPATH="/var/mail"
> PKGDATADIR="/usr/local/share/mutt"
> SYSCONFDIR="/usr/local/etc"
> EXECSHELL="/bin/sh"
> -MIXMASTER
> To contact the developers, please mail to .
> To report a bug, please visit http://bugs.mutt.org/.
>
> -- Core Dump Analysis Output
>
> GNU gdb 6.6-1mdv2007.1 (Mandriva Linux release 2007.1)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i586-mandriva-linux-gnu"...
> Using host libthread_db library "/lib/i686/libthread_db.so.1".
> Reading symbols from /usr/lib/libncursesw.so.5...done.
> Loaded symbols for /usr/lib/libncursesw.so.5
> Reading symbols from /usr/lib/libidn.so.11...done.
> Loaded symbols for /usr/lib/libidn.so.11
> Reading symbols from /lib/i686/libc.so.6...Reading symbols from
> /usr/lib/debug/lib/i686/libc-2.4.so.debug...done.
> done.
>
Re: [Mutt] #1471: omission of reference to "include" in manual
#1471: omission of reference to "include" in manual
---+--
Reporter: rupert@… | Owner: mutt-dev
Type: defect| Status: closed
Priority: trivial | Milestone:
Component: mutt |Version: 1.3.28i
Resolution: fixed | Keywords:
---+--
Changes (by kevin8t8):
* reporter: Rupert Levene => rupert@…
Old description:
> {{{
> Package: mutt
> Version: 1.3.28-2
> Severity: wishlist
>
> -- Please type your report below this line
>
> The section of the manual that talks about replying doesn't describe
> the include option. It doesn't say that you are given the option to
> include the original message either. This made it hard for me to find
> the include option.
>
> Suggested rethink:
>
> Mutt will then enter the _c_o_m_p_o_s_e menu and prompt you for
> the
> recipients to place on the ``To:'' header field. Next, it will ask
> you for the ``Subject:'' field for the message, providing a default if
> you are replying to or forwarding a message. See also ``$askcc'',
> ``$askbcc'', ``$autoedit'', ``$include'' and ``$fast_reply'' for
> changing
> how Mutt asks these questions.
>
> -- Build environment information
>
> (Note: This is the build environment installed on the system
> muttbug is run on. Information may or may not match the environment
> used to build mutt.)
>
> - gcc version information
> cc
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> gcc version 2.95.4 20011002 (Debian prerelease)
>
> - CFLAGS
> -Wall -pedantic -g -O2
>
> -- Mutt Version Information
>
> Mutt 1.3.28i (2002-03-13)
> Copyright (C) 1996-2001 Michael R. Elkins and others.
> Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
> Mutt is free software, and you are welcome to redistribute it
> under certain conditions; type `mutt -vv' for details.
>
> System: Linux 2.2.20 (i686) [using ncurses 5.2]
> Compile options:
> -DOMAIN
> -DEBUG
> -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
> +USE_FCNTL -USE_FLOCK
> +USE_POP +USE_IMAP -USE_GSS -USE_SSL +USE_GNUTLS +USE_SASL
> +HAVE_REGCOMP -USE_GNU_REGEX
> +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
> +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
> +HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT
> +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS
> +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
> +HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO
> ISPELL="/usr/bin/ispell"
> SENDMAIL="/usr/sbin/sendmail"
> MAILPATH="/var/mail"
> PKGDATADIR="/usr/share/mutt"
> SYSCONFDIR="/etc"
> EXECSHELL="/bin/sh"
> MIXMASTER="mixmaster"
> To contact the developers, please mail to .
> To report a bug, please use the flea(1) utility.
>
> patch-1.5.tlr.mx_open_append.2
> patch-1.3.28.cvs.indexsegfault
> patch-1.3.27.bse.xtitles.1
> patch-1.3.26.appoct.3
> patch-1.3.15.sw.pgp-outlook.1
> patch-1.3.27.admcd.gnutls.19
> Md.use_editor
> Md.paths_mutt.man
> Md.muttbug_no_list
> Md.use_etc_mailname
> Md.muttbug_warning
> Md.gpg_status_fd
> patch-1.3.24.rr.compressed.1
> patch-1.3.25.cd.edit_threads.9.1
> patch-1.3.23.1.ametzler.pgp_good_sign
>
> >How-To-Repeat:
> >Fix:
> }}}
New description:
{{{
Package: mutt
Version: 1.3.28-2
Severity: wishlist
-- Please type your report below this line
The section of the manual that talks about replying doesn't describe
the include option. It doesn't say that you are given the option to
include the original message either. This made it hard for me to find
the include option.
Suggested rethink:
Mutt will then enter the _c_o_m_p_o_s_e menu and prompt you for the
recipients to place on the ``To:'' header field. Next, it will ask
you for the ``Subject:'' field for the message, providing a default if
you are replying to or forwarding a message. See also ``$askcc'',
``$askbcc'', ``$autoedit'', ``$include'' and ``$fast_reply'' for
changing
how Mutt asks these questions.
-- Build environment information
(Note: This is the build environment installed on the system
muttbug is run on. Information may or may not match the environment
used to build mutt.)
- gcc version information
cc
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
- CFLAGS
-Wall -pedantic -g -O2
-- Mutt Version Information
Mutt 1.3.28i (2002-03-13)
Copyright (
Re: [Mutt] #1046: Request that the "uncolor" command work with "body"/"header" objects in addition to "index"
#1046: Request that the "uncolor" command work with "body"/"header" objects in
addition to "index"
--+--
Reporter: arno@… | Owner: mutt-dev
Type: enhancement | Status: closed
Priority: trivial | Milestone:
Component: mutt |Version: 1.3.27i
Resolution: fixed| Keywords:
--+--
Changes (by kevin8t8):
* reporter: Arno => arno@…
Old description:
> {{{
> Package: mutt
> Version: 1.3.27i
> Severity: wishlist
>
> -- Please type your report below this line
>
>
> -- Build environment information
>
> (Note: This is the build environment installed on the system
> muttbug is run on. Information may or may not match the environment
> used to build mutt.)
>
> [ Editor's Note: Yes, it's the same system...but I really don't think
> it makes any difference. ]
>
> - gcc version information
> gcc
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
>
> - CFLAGS
> -Wall -pedantic -g -O2
>
> -- Mutt Version Information
>
> ]2;Mutt 1.3.27i (2002-01-22)Mutt 1.3.27i (2002-01-22)
> Copyright (C) 1996-2001 Michael R. Elkins and others.
> Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
> Mutt is free software, and you are welcome to redistribute it
> under certain conditions; type `mutt -vv' for details.
>
> System: Linux 2.4.7-10 (i686) [using slang 10404]
> Compile options:
> -DOMAIN
> -DEBUG
> -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
> +USE_FCNTL -USE_FLOCK
> +USE_POP +USE_IMAP -USE_GSS +USE_SSL -USE_SASL
> +HAVE_REGCOMP -USE_GNU_REGEX
> +HAVE_COLOR -HAVE_START_COLOR -HAVE_TYPEAHEAD -HAVE_BKGDSET
> -HAVE_CURS_SET -HAVE_META -HAVE_RESIZETERM
> +HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT
> +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
> +HAVE_LANGINFO_YESEXPR
> +HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO
> ISPELL="/usr/bin/ispell"
> SENDMAIL="/usr/sbin/sendmail"
> MAILPATH="/var/mail"
> PKGDATADIR="/usr/local/share/mutt"
> SYSCONFDIR="/usr/local/etc"
> EXECSHELL="/bin/sh"
> MIXMASTER="mixmaster"
> To contact the developers, please mail to .
> To report a bug, please use the flea(1) utility.
>
> --- Begin /home/arno/.muttrc
> set folder="~/.mail"
> set spoolfile="~/.mail/inc/inbox"
> set mbox=!
> source ~/.mutt/rc.mailboxes
> source ~/.mutt/rc.alias_lists
> source ~/.mutt/rc.alias_unet
> source ~/.mutt/rc.alias_io
> source ~/.mutt/rc.alias_personal
> source ~/.mutt/links/rc.$TERM
> source ~/.mutt/rc.bind
> source ~/.mutt/rc.macro
> source ~/.mutt/rc.headers_friendly
> source ~/.mutt/rc.pgp
> source ~/.mutt/rc.gpg
> source ~/.mutt/rc.score
> source ~/.mutt/rc.autoview
> source ~/.mutt/rc.lists_io
> source ~/.mutt/rc.lists_personal
> source ~/.mutt/rc.hook_folder
> source ~/.mutt/rc.hook_save
> source ~/.mutt/rc.hook_send
> source ~/.mutt/rc.hook_fccsave
> source ~/.mutt/rc.hook_fcc
> source ~/.mutt/rc.hook_pgp
> set abort_nosubject=ask-yes
> set abort_unmodified=ask-yes
> set alias_file="~/.mutt/rc.alias"
> set alias_format="%4n %t %-10a %r"
> set allow_8bit=yes
> set alternates="a...@daaave.org r...@daaave.org daa...@io.com
> l...@ftp.cdrom.com l...@wcarchive.cdrom.com daa...@undernet.org
> hello_nu...@hotmail.com daa...@www.com alt_...@hotmail.com
> a...@synchronic.net a...@morphium.org"
> set arrow_cursor=no
> set ascii_chars=no
> set askbcc=no
> set askcc=no
> set attach_format="%u%D%I %t%4n %T%.40d%> [%.7m/%.10M, %.6e%?C?, %C?, %s]
> "
> set attach_sep="\n"
> set attach_split=yes
> set attribution="On %d, %n wrote:"
> set auto_tag=no
> set autoedit=no
> set beep=yes
> set beep_new=yes
> set bounce_delivered=yes
> set certificate_file=""
> set charset="iso-8859-1"
> set check_new=yes
> set collapse_unread=yes
> set confirmappend=no
> set confirmcreate=yes
> set copy=yes
> set date_format="!%a, %b %d, %Y at %I:%M:%S%p %Z"
> set default_hook="~f %s !~P | (~P ~C %s)"
> set delete=yes
> set delete_untag=yes
> set dotlock_program="$HOME/bin/mutt_dotlock"
> set dsn_notify="failure,delay"
> set dsn_return=full
> set edit_headers=no
> set editor="joe -nobackups -autoindent -linums -tab 2 -spaces -indentc 32
> -istep 2 -rmargin 72 -mold muttinit"
> set encode_from=no
&g
Re: [Mutt] #3987: Bug in Yahoo Mail where body contains an empty text attachment if sent through mutt
#3987: Bug in Yahoo Mail where body contains an empty text attachment if sent through mutt --+-- Reporter: Peter92 | Owner: mutt-dev Type: defect | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.5.24 Resolution: | Keywords: --+-- Comment (by Peter92): Haha thanks, for the record it doesn't appear to be all Yahoo accounts (tested with a friend who is on yahoo.fr, both our accounts are old but his didn't have the issue), but if you'd want to try at some point I can pass you an unused account where it does happen. I'd use gmail instead, but the 1tb limit Yahoo has is pretty nice for backing up various bits :) -- Ticket URL: <https://dev.mutt.org/trac/ticket/3987#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3986: send-hook for Cc and Bcc executed too late
#3986: send-hook for Cc and Bcc executed too late ---+-- Reporter: alahouze | Owner: mutt-dev Type: defect| Status: closed Priority: major | Milestone: Component: mutt |Version: Resolution: invalid | Keywords: send-hook my_hdr ---+-- Comment (by alahouze): Actually, the macro must be on "compose", and I added a `send-hook '!~Q' "push m"` too, which initializes the headers like I want when I create a new mail. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3986#comment:3> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3987: Bug in Yahoo Mail where body contains an empty text attachment if sent through mutt
#3987: Bug in Yahoo Mail where body contains an empty text attachment if sent
through mutt
--+--
Reporter: Peter92 | Owner: mutt-dev
Type: defect | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.5.24
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
This isn't "more of" a bug on the side of Yahoo; it's unequivocally
Yahoo's issue (which, strangely, I still can't reproduce).
Peeking at RFC 2183, the abstract at the very beginning says:
It specifies the "Content-Disposition" header field, which is optional
and valid for any MIME entity ("message" or "body part").
and to make it perfectly clear, section 2.10 plainly states:
It is permissible to use Content-Disposition on the main body of an
[RFC 822] message.
Furthermore, as if it weren't ridiculous enough that they are mishandling
a 20-year old RFC, the header itself says {{{inline}}}. Sigh. Okay,
enough ranting, it's not as if this is your fault.
I need to take a closer look at the code to see what, if anything, is
possible. The code for writing headers and body are reused in many
situations, and things like $fcc_attach, encryption, signing, and
$fcc_clear, make this less easy than one might initially think.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3987#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
[Mutt] #3987: Bug in Yahoo Mail where body contains an empty text attachment if sent through mutt
#3987: Bug in Yahoo Mail where body contains an empty text attachment if sent through mutt -+-- Reporter: Peter92 | Owner: mutt-dev Type: defect | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.5.24 Keywords: | -+-- Same issue as here: https://dev.mutt.org/trac/ticket/3970 Like the above ticket, I've been finding either TEXT.txt or 1.txt (if other attachments are present) in any email sent via mutt. With a bit of narrowing down options I think I found the culprit, but have no idea how to fix it. As you can see at https://forums.yahoo.net/t5/Temporary-Errors/Content- Disposition-inline-headers-not-being-respected/td-p/226349, Yahoo Mail doesn't like the "Content-Disposition: inline" header, and will treat the body as an attachment. It's more of a bug on the side of Yahoo, but it should probably be a lot easier to fix in mutt. Looking at a few of my other emails, it appears most don't contain that line. I've attempted overriding the line but it didn't work, is there anyway to disable it? Here is the pastebin of one of the emails with the issue, as you can see there is no actual attachment: https://pastebin.com/tzYEsL1S -- Ticket URL: <https://dev.mutt.org/trac/ticket/3987> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3986: send-hook for Cc and Bcc executed too late
#3986: send-hook for Cc and Bcc executed too late
---+--
Reporter: alahouze | Owner: mutt-dev
Type: defect| Status: closed
Priority: major | Milestone:
Component: mutt |Version:
Resolution: invalid | Keywords: send-hook my_hdr
---+--
Changes (by kevin8t8):
* status: new => closed
* resolution: => invalid
Comment:
Just to clarify my previous comment before I close this ticket. The send-
hook's purpose is to change settings based on the recipients of a message,
not to set such recipients.
If you need suggestions on how to make your desired changes, I would
advise emailing mutt-users. They are a creative bunch, and perhaps better
informed than whence you were told to report this as a bug.
One quick suggestion would be to try making the changes in a macro
instead:
{{{
# Override 'm' to set a Cc header
macro index,pager m "my_hdr Cc: Contact Example
"
# Clean up the cc header so it doesn't appear for replies
send-hook . unmy_hdr cc
}}}
You could override 'm' as the above does, or use another key sequence just
for those cases you want the cc. Again, mutt-users may have better ideas.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3986#comment:2>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3986: send-hook for Cc and Bcc executed too late
#3986: send-hook for Cc and Bcc executed too late ---+-- Reporter: alahouze | Owner: mutt-dev Type: defect| Status: new Priority: major | Milestone: Component: mutt |Version: Resolution:| Keywords: send-hook my_hdr ---+-- Comment (by kevin8t8): Please see https://muttmua.gitlab.io/mutt/manual-dev.html#send-hook the second note: send-hook's are only executed once after getting the initial list of recipients. Adding a recipient after replying or editing the message will not cause any send-hook to be executed, similarly if $autoedit is set (as then the initial list of recipients is empty). Also note that my_hdr commands which modify recipient headers, or the message's subject, don't have any effect on the current message when executed from a send-hook. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3986#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
[Mutt] #3986: send-hook for Cc and Bcc executed too late
#3986: send-hook for Cc and Bcc executed too late
--+--
Reporter: alahouze | Owner: mutt-dev
Type: defect| Status: new
Priority: major | Milestone:
Component: mutt |Version:
Keywords: send-hook my_hdr |
--+--
Hi,
I have a hook to initialize Cc on new mails only:
{{{ send-hook !~Q 'my_hdr Cc: Contact Example ' }}}
When I create a new mail for the first time, Cc header is not initialized.
When I create a second new mail, it is.
I also have a folder hook to reset send hook (I have a multi account
configuration, each one in a separate folder). Let's say account1 for the
one I want Cc on new mails and account2 for the other one.
1. I make a new mail on account1: Cc is not initialized but should be
2. I make another new mail on account1: Cc is initialized
3. Then I make a mail on account2: Cc is initialized but should not be
4. Finally I make another new mail on account2: Cc is not initialized
It seems the hook is run after the mail edition.
I am using neomutt, so I discussed about it with flatcap on
#neomutt@freenode who confirmed the bug for Cc and Bcc headers, and
confirmed it on upstream mutt too and so he asked me to open a new ticket
here, so here it is.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3986>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3985: viewing HTML attachments frequently fails with "File not found"
#3985: viewing HTML attachments frequently fails with "File not found" ---+-- Reporter: adrianvm | Owner: mutt-dev Type: defect| Status: closed Priority: major | Milestone: Component: mutt |Version: Resolution: wontfix | Keywords: ---+-- Comment (by adrianvm): So obvious now that you explain it, and easy to work around now that I understand what's going on. Thanks. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3985#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3985: viewing HTML attachments frequently fails with "File not found"
#3985: viewing HTML attachments frequently fails with "File not found" ---+-- Reporter: adrianvm | Owner: mutt-dev Type: defect| Status: closed Priority: major | Milestone: Component: mutt |Version: Resolution: wontfix | Keywords: ---+-- Changes (by kevin8t8): * status: new => closed * resolution: => wontfix Comment: This is due to a race condition. Firefox returns immediately when you launch a new tab. Mutt then cleans up the temp file. It's a coin toss whether firefox will try to read the temp file before or after it's removed. See https://gitlab.com/muttmua/mutt/wikis/MuttFaq/Attachment "How to view HTML attachments in a new tab in firefox" for an explanation and one possible solution. Another possibility would be using a helper script instead. Cameron Simpson maintains one called apphelper: * blurb: http://www.cskk.ezoshosting.com/cs/css/apphelper.html * script: https://bitbucket.org/cameron_simpson/css/src/tip/bin/apphelper * wrapper: https://bitbucket.org/cameron_simpson/css/src/tip/bin-cs/ah -- Ticket URL: <https://dev.mutt.org/trac/ticket/3985#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
[Mutt] #3985: viewing HTML attachments frequently fails with "File not found"
#3985: viewing HTML attachments frequently fails with "File not found" --+-- Reporter: adrianvm | Owner: mutt-dev Type: defect| Status: new Priority: major | Milestone: Component: mutt |Version: Keywords:| --+-- If I select an HTML message part my browser (firefox) is invoked on the file /tmp/mutt.html. This file, unfortunately, does not exist most of the time, and hence I get the error "File not found" from firefox. If I repeatedly select the HTML message part it usually works after 5-10 attempts. (So I have in my browser perhaps 8 tabs that say "file not found" and then finally the tab for /tmp/mutt.html with the actual message content. My mutt version is: NeoMutt 20170609 (1.8.3). -- Ticket URL: <https://dev.mutt.org/trac/ticket/3985> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by kevin8t8): Overall the testing looked good, so I'll push the patch later on today. However, my testing did uncover a bug when resuming encrypted S/MIME drafts, which affects mutt prior to this patch. I'll push a fix up to stable for that afterwards, and then will close this ticket. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:20> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: closed Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: fixed| Keywords: --+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: I've pushed db252e61 up to master and 667a4710 to stable. Thanks for everyone's feedback and help. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:21> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by kevin8t8): Thank you very much for testing the patch. I'm glad to hear the S/MIME changes are working for you. That's very helpful, because I don't use S/MIME myself and can only test in my small artificial environment. I'm still going to review and test for a couple more days. If all looks good, I'll push it up. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:19> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by michele): Perfekt! The patch worked find for me, but I just could test it with S/MIME. I had to set ''only'' the `smime_default_key` value (and of course importing `smime.rc`) to use it. Well done 👍 -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:18> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by kevin8t8): I'm attaching a preliminary patch. I haven't gone over it thoroughly, and have only lightly tested it, so it might blow up or do something weird. I'll spend some more time on it the next couple days, but if you feel daring you are welcome to try it out. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:17> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Changes (by kevin8t8): * Attachment "ticket-3983.patch" added. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by michele): Goog 👍. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:16> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
--+--
Reporter: michele | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.9.2
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
Okay, my rambling on in the last comment has helped me think things
through, and I think there is a solution.
PGP:
* Create {{{$pgp_default_key}}}
- this will be used for encryption (for {{{$postpone_encrypt}}} and
{{{$pgp_self_encrypt}}}).
- this will be used for signing unless {{{$pgp_sign_as}}} is set.
- {{{$pgp_self_encrypt_as}}} will become an alias for this. I'll
mention in the docs, but note it is deprecated.
* {{{$pgp_sign_as}}} continues to be available. Those with separate
signing keys should continue to use it, but others can just put their key
into {{{$pgp_default_key}}}. The pgp "sign (a)s" menu will set
{{{$pgp_sign_as}}} (as it does now).
* Change the default of {{{$pgp_self_encrypt}}} to set.
S/MIME:
* {{{$smime_default_key}}}
- will be used for encryption for {{{$postpone_encrypt}}} and
{{{$smime_self_encrypt}}}.
- will be used for decryption unless
{{{$smime_decrypt_use_default_key}}} is unset.
- will be used for signing unless {{{$smime_sign_as}}} is set
- {{{$smime_self_encrypt_as}}} will become an alias for this, which I'll
also mention in the docs but note it is deprecated.
* Create {{{$smime_sign_as}}}
- this is available for those with separate encryption and signing keys.
- Change the s/mime "sign (a)s" menu to set this instead.
* Change the default of {{{$smime_self_encrypt}}} to set.
How does this sound?
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:15>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
--+--
Reporter: michele | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.9.2
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
I haven't spent much time looking at the s/mime decryption code, and was
curious why the variable is called {{{smime_default_key}}}, so I'm taking
a closer look.
It looks like {{{smime_default_key}}} '''will''' be used for decryption if
{{{smime_decrypt_use_default_key}}} is set. This was set up before I
added a capability flag to the s/mime .index files. Since the value is
overwritten by "sign (a)s", I'm not sure this is a very good idea
anymore...
So we might be able to do this for s/mime, but I have reservations given
the sign (a)s overwriting behavior. It's more certainly not a good idea
for pgp.
If I could wipe the slate clean, I would probably create a
{{{pgp_default_key}}}, along with {{{pgp_sign_key}}} and
{{{pgp_encrypt_key}}} that would override the value in
{{{pgp_default_key}}} if they were set. I might also store the value set
by "sign (a)s" in the pgp menu in a separate place, instead of overwriting
the configuration variable. Likewise for s/mime.
But given the current state, I'd rather keep the self-encrypt vars as is.
The variables won't get surprisingly overwritten, and (for pgp) we won't
suddenly start trying to encrypt using a key with no encryption
capability.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:14>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
--+--
Reporter: michele | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.9.2
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
As I said in comment:1, {{{pgp_sign_as}}} and {{{smime_default_key}}}
(there is no {{{pgp_default_key}}}) specify '''signing''' keys. Those
variables are also set when the user chooses "sign (a)s" in the PGP and
S/MIME menu.
Those two variables are unsuitable for holding a self-encrypt key, because
they in fact could be set to a key without encryption capabilities.
Yes, this does happen: I sometimes have to explain on IRC why someone
can't send an encrypted email to someone, because the key does not have
encryption capability set.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:13>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by vinc17): Replying to [comment:11 michele]: > Hi Vincent. Using the sender's key (`smime_default_key` resp. `pgp_default_key`) as default was my suggestion. Read the first paragraph in my description of this ticket. Yes, this is what should be done, IMHO. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:12> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3984: Very large IMAP folders result in "could not copy message"
#3984: Very large IMAP folders result in "could not copy message" -+-- Reporter: darac | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: IMAP|Version: Resolution: fixed | Keywords: patch -+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: I've added commits 8fcf8eda and e0229b87 to our git repos (on gitlab.com). Those also cleaned up the msn and imap literal parsing. They are in the stable branch, and so will be in the next stable release. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3984#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3984: Very large IMAP folders result in "could not copy message"
#3984: Very large IMAP folders result in "could not copy message" -+-- Reporter: darac | Owner: mutt-dev Type: defect | Status: new Priority: major | Milestone: Component: IMAP|Version: Resolution: | Keywords: patch -+-- Comment (by kevin8t8): Thank you for the bug report and patch. I actually noticed the atoi() calls before and wondered about the very issue you reported, but didn't want to touch something that was "working". :-/ I'll take a look at the patch this weekend. Thanks again. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3984#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3984: Very large IMAP folders result in "could not copy message"
#3984: Very large IMAP folders result in "could not copy message" -+-- Reporter: darac | Owner: mutt-dev Type: defect | Status: new Priority: major | Milestone: Component: IMAP|Version: Resolution: | Keywords: patch -+-- Changes (by darac): * Attachment "mutt-unsigned.patch" added. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3984> Mutt <http://www.mutt.org/> The Mutt mail user agent
[Mutt] #3984: Very large IMAP folders result in "could not copy message"
#3984: Very large IMAP folders result in "could not copy message" +-- Reporter: darac | Owner: mutt-dev Type: defect | Status: new Priority: major | Milestone: Component: IMAP|Version: Keywords: patch | +-- Dear Maintainer, For some reason, one of the mailboxes on my dovecot server has very large UIDs (> 2!**31). Trying to open messages with these very large UIDs results in mutt complaining "Could not copy message" and failing to open the message. Upon investigation, I found that this is because mutt occasionally treats UIDs as signed integers (the RFC states that they are, in fact, unsigned ints). In the attached patch, I have tried to track down as many instances of UIDs being treated as ints as I can (changing declarations, replacing the use of atoi() with strtoul(), printing with '%u' instead of '%d' and so on). This now means I can open messages in the affected mailbox. [This bug is a clone of Debian Bug https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=861235] -- Ticket URL: <https://dev.mutt.org/trac/ticket/3984> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by michele): Hi Vincent. Using the sender's key (`smime_default_key` resp. `pgp_default_key`) as default was my suggestion. Read the first paragraph in my description of this ticket. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:11> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
--+--
Reporter: michele | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.9.2
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
Hi Vincent, I'm not sure I understand your suggestion. I know that gpg
can be configured to do this via the {{{encrypt-to}}} config in
{{{~/.gnupg/gpg.conf}}}. Otherwise, it is not done by default.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:10>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by vinc17): Shouldn't the sender's key used by default? -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:9> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3755: imap: accumulates the same certificate over and over in ~/.mutt/certificates but doesn't recognize at startup
#3755: imap: accumulates the same certificate over and over in ~/.mutt/certificates but doesn't recognize at startup -+- Reporter: ecloud | Owner: brendan Type: defect | Status: closed Priority: major | Milestone: Component: IMAP|Version: 1.5.23 Resolution: fixed | Keywords: -+- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: I had to trace back through again, but it turns out GnuTLS doesn't have the same issue OpenSSL had. It adds hostname and fingerprint entries into the $certificate_file. So accepting (a)lways for a hostname mismatch with GnuTLS should not prompt again. With OpenSSL, we ended up disabling the (a)lways option for hostname mismatches. (And would suggest using an account hook to disable $ssl_verify_host for just that connection if this is otherwise unsolvable.) In either case, you shouldn't have the same cert being appended again and again to your cert file as of the 1.9.0 release. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3755#comment:3> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by kevin8t8): Replying to myself, perhaps it's worth exploring ways to add this to the UI. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:8> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
--+--
Reporter: michele | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.9.2
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
Changing the default of {{{pgp_self_encrypt}}} to "yes" will make no
difference, because they must supply {{{pgp_self_encrypt_as}}}. How does
it make a significant difference at that point?
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:7>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by vinc17): Most users won't read details in the manual. IMHO, it's rather surprising that one cannot read something one has written, so I would say that the default should be "yes". If some people think that this may be a security issue (which one???), then this could be changed to a quad-option with something like ask_yes or ask_no. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:6> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by kevin8t8): I've added a paragraph to the "Sending Cryptographically Signed/Encrypted Messages" section in the manual, mentioning the self-encrypt options. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:5> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3755: imap: accumulates the same certificate over and over in ~/.mutt/certificates but doesn't recognize at startup
#3755: imap: accumulates the same certificate over and over in ~/.mutt/certificates but doesn't recognize at startup -+- Reporter: ecloud | Owner: brendan Type: defect | Status: new Priority: major | Milestone: Component: IMAP|Version: 1.5.23 Resolution: | Keywords: -+- Comment (by kevin8t8): This was fixed for OpenSSL in git commit 0d80c9be back in March. Unfortunately, GnuTLS was not fixed. I'll try to dive into that file and see if I can fix it there too. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3755#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3476: copyright years are not up-to-date
#3476: copyright years are not up-to-date -+-- Reporter: vinc17 | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: mutt|Version: Resolution: fixed | Keywords: -+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: These have been updated a few times, so closing this ticket out. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3476#comment:1> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3962: Backspace Key doesn't work in pager and Tmux
#3962: Backspace Key doesn't work in pager and Tmux -+--- Reporter: ManDay | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: user interface |Version: Resolution: wontfix | Keywords: BackSpace -+--- Changes (by kevin8t8): * status: new => closed * resolution: => wontfix Comment: Closing this ticket, as it wasn't a Mutt issue. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3962#comment:11> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3980: Can we integrate support for /etc/mailname?
#3980: Can we integrate support for /etc/mailname? +-- Reporter: antonio@… | Owner: mutt-dev Type: defect | Status: closed Priority: trivial| Milestone: Component: mutt |Version: 1.9.1 Resolution: wontfix| Keywords: patch +-- Comment (by antonio@…): That's no problem! I wasn't aware that I could do `cat /etc/mailname` in Muttrc, clearly that is the best way of assigning the hostname, rather than patching the code. I'll drop the patch from Debian and move to this setting in one of the next Debian releases. Thanks! -- Ticket URL: <https://dev.mutt.org/trac/ticket/3980#comment:10> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
--+--
Reporter: michele | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.9.2
Resolution: | Keywords:
--+--
Comment (by code@…):
{{{
I'd be inclined to agree with Kevin: The whole point of encryption is
to be exclusive about who can read it, and changing this changes the
model to one that's more permissive, which may result in bad
consequences for unsuspecting users.
OTOH, I'm somewhat in favor of anything that makes it easier for
people to adopt encrypted e-mail (though, TBH, I think that ship has
sailed), and I can't really think of any particularly good arguments
for why one might not want to be able to read one's own encrypted
correspondence.
I'm somewhat inclined to engage Werner on the subject. [Or, Werner,
if you're still paying attention to Mutt and issues relating to its
use of GPG, please feel free to pipe up!] If this can wait a while I
s'pose I'll do that.
}}}
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:4>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by kevin8t8): I think adding something to the manual does make sense. I'll take a look at that soon. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:3> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3982: recipient's S/MIME certificate disappear after sending encrypted email
#3982: recipient's S/MIME certificate disappear after sending encrypted email --+-- Reporter: michele | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: 1.9.1 Resolution: fixed| Keywords: --+-- Comment (by michele): I tried to explain better what I mean in the enhancement #3983. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3982#comment:6> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) --+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Resolution: | Keywords: --+-- Comment (by michele): Thank you for letting me know your arguments... which make sense ;-) Maybe this (*) should be anyway mentioned in the [http://www.mutt.org/doc/manual/#record documentation] for the `record` variable. (*) i.e. that while sending encrypted emails (with S/MIME or PGP), per default the copy saved to the outgoing messages won't be decryptable anymore, unless one sets the `smime_self_encrypt` and `smime_self_encrypt_as` resp. `pgp_self_encrypt` and `pgp_self_encrypt_as` variables. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
--+--
Reporter: michele | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor| Milestone:
Component: mutt |Version: 1.9.2
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
{{{pgp_sign_as}}} and {{{smime_default_key}}} specify signing keys. In
some cases the signing key and encryption key will be different, thus the
new configuration variables.
I'm not all that concerned that Mutt users may be put off by this, as they
tend to be more interested in correctness and configurability than user-
friendly or a "batteries included" experience. Repetition can be avoided
by using a $my_ variable, or by assigning one configuration variable to
the other.
I'll give a few days for the other devs to comment, but am against this
request.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3983#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
[Mutt] #3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt)
#3983: Change smime_self_encrypt default to yes (same for pgp_self_encrypt) -+-- Reporter: michele | Owner: mutt-dev Type: enhancement | Status: new Priority: minor| Milestone: Component: mutt |Version: 1.9.2 Keywords: | -+-- I suggest to change the default for `smime_self_encrypt` to `yes` and to encrypt the messages also using the key in `smime_default_key` as default, which one can override with the key in `smime_self_encrypt_as` (if set to a non empty value). By the way, what is the use case in using a different key as the one defined in `smime_self_encrypt`? Same story for PGP. This behaviour would be the same as for other mail clients (like Mac Mail) and more user friendly. Moreover this would simplify user's configuration ;-) Bests, Michele -- Ticket URL: <https://dev.mutt.org/trac/ticket/3983> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3982: recipient's S/MIME certificate disappear after sending encrypted email
#3982: recipient's S/MIME certificate disappear after sending encrypted email --+-- Reporter: michele | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: 1.9.1 Resolution: fixed| Keywords: --+-- Comment (by kevin8t8): No, the workaround I mentioned requires a correct value to be placed in $smime_self_encrypt_as, which would be different for each person. 1.9.2 is a stable release, so distros that include the 1.9.x series should upgrade or include that patch. The bug doesn't affect users prior to 1.9.0. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3982#comment:5> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3982: recipient's S/MIME certificate disappear after sending encrypted email
#3982: recipient's S/MIME certificate disappear after sending encrypted email --+-- Reporter: michele | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: 1.9.1 Resolution: fixed| Keywords: --+-- Comment (by michele): Should the workaround not be the default? -- Ticket URL: <https://dev.mutt.org/trac/ticket/3982#comment:4> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3982: recipient's S/MIME certificate disappear after sending encrypted email
#3982: recipient's S/MIME certificate disappear after sending encrypted email --+-- Reporter: michele | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: 1.9.1 Resolution: fixed| Keywords: --+-- Comment (by kevin8t8): I've just released 1.9.2 with this fix. Also, one workaround for the problem is to enable $smime_self_encrypt and set a value for $smime_self_encrypt_as. This will cause the certificate list to have more than one cert, causing the unlink to fail. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3982#comment:3> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3982: recipient's S/MIME certificate disappear after sending encrypted email
#3982: recipient's S/MIME certificate disappear after sending encrypted email --+-- Reporter: michele | Owner: mutt-dev Type: defect | Status: closed Priority: major| Milestone: Component: mutt |Version: 1.9.1 Resolution: fixed| Keywords: --+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: This is fixed in https://gitlab.com/muttmua/mutt/commit/9eedfd4e1b62d1749f7e93d85fb0930e7d2cdf8f I will push out a release with this fix either tonight or tomorrow. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3982#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3982: recipient's S/MIME certificate disappear after sending encrypted email
#3982: recipient's S/MIME certificate disappear after sending encrypted email
--+--
Reporter: michele | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version: 1.9.1
Resolution: | Keywords:
--+--
Comment (by kevin8t8):
Yikes!
It looks like changeset:085fc55029d8 exposed some goofed up cleanup code.
Previously certfile had a leading space, which the changeset converted to
a trailing space.
This should have had no effect, but the code below has erroneous calls to
{{{mutt_unlink(certfile)}}}. Since it previously had a leading space, the
call was a noop, but is now causing damage.
I can only guess that I just wasn't paying attention to the certfiles when
I tested the change.
I will release 1.9.2 this weekend with the fix. Thank you for reporting
the issue.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3982#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
[Mutt] #3982: recipient's S/MIME certificate disappear after sending encrypted email
#3982: recipient's S/MIME certificate disappear after sending encrypted email
-+--
Reporter: michele | Owner: mutt-dev
Type: defect | Status: new
Priority: major| Milestone:
Component: mutt |Version: 1.9.1
Keywords: |
-+--
Tested on Fedora 26 (mutt-1.9.1) and also macOS (NeoMutt 20171027
installed with macport).
How to reproduce:
- start mutt (with default smime.rc)
- enter IMAP password
- compose a new email
- enter a text and exit the editor (vi)
- set the security to "e" (encrypt)
- send
An strace shows that the certificate has been deleted:
{{{
[pid 7621] lstat("/u/mmarcio/.smime/certificates/0cf3fc1c.0",
{st_mode=S_IFREG|0600, st_size=2291, ...}) = 0
[pid 7621] open("/u/mmarcio/.smime/certificates/0cf3fc1c.0",
O_RDWR|O_NOFOLLOW) = 8
[pid 7621] fstat(8, {st_mode=S_IFREG|0600, st_size=2291, ...}) = 0
[pid 7621] fcntl(8, F_GETFL) = 0x28002 (flags
O_RDWR|O_LARGEFILE|O_NOFOLLOW)
[pid 7621] unlink("/u/mmarcio/.smime/certificates/0cf3fc1c.0") = 0
}}}
(full strace attached)
Is this a bug (in that case please fix it) or a feature (is there a
workaround)?
Bests,
Michele
PS: by the way... the encrypted arrives to destination ;-)
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3982>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #3981: auto loging issue
#3981: auto loging issue -+-- Reporter: harsh | Owner: mutt-dev Type: defect | Status: closed Priority: major | Milestone: Component: mutt|Version: Resolution: fixed | Keywords: -+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed -- Ticket URL: <https://dev.mutt.org/trac/ticket/3981#comment:4> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3981: auto loging issue
#3981: auto loging issue -+-- Reporter: harsh | Owner: mutt-dev Type: defect | Status: new Priority: major | Milestone: Component: mutt|Version: Resolution: | Keywords: -+-- Comment (by kevin8t8): Did you figure anything out with this? Have you tried posting to mutt- users? -- Ticket URL: <https://dev.mutt.org/trac/ticket/3981#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3981: auto loging issue
#3981: auto loging issue
-+--
Reporter: harsh | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: mutt|Version:
Resolution: | Keywords:
-+--
Changes (by harsh):
* cc: kevin@… (added)
Comment:
{{{
Thanks for the help. It got resolved.
Regards
Harsh
On Mon, Dec 11, 2017 at 9:08 AM, Mutt wrote:
}}}
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3981#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Re: [Mutt] #973: encrypt mail with more keys than recipient list (think mailinglist)
#973: encrypt mail with more keys than recipient list (think mailinglist) --+--- Reporter: Marco d'Itri | Owner: mutt-dev Type: enhancement | Status: closed Priority: trivial | Milestone: Component: crypto |Version: Resolution: fixed| Keywords: #1610 + #1897 --+--- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: No objections were raised, so I'm going to consider the multiple crypt- hook along with $crypt_confirmhook as an acceptable (if not perfect) solution. -- Ticket URL: <https://dev.mutt.org/trac/ticket/973#comment:9> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3687: Threads expand when other IMAP clients access IMAP folder
#3687: Threads expand when other IMAP clients access IMAP folder -+-- Reporter: G11_a | Owner: mutt-dev Type: defect | Status: closed Priority: minor | Milestone: Component: user interface |Version: 1.5.21 Resolution: fixed | Keywords: -+-- Changes (by kevin8t8): * status: new => closed * resolution: => fixed Comment: Ticket seems to be too old. I believe the fixes from comment:1 have taken care of this, so am marking this as fixed. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3687#comment:2> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3975: Not plain/text /usr/share/doc/mutt/manual.txt.gz
#3975: Not plain/text /usr/share/doc/mutt/manual.txt.gz --+-- Reporter: jaalto | Owner: mutt-dev Type: defect | Status: closed Priority: trivial | Milestone: Component: mutt |Version: Resolution: wontfix | Keywords: patch --+-- Changes (by kevin8t8): * status: new => closed * resolution: => wontfix Comment: Sorry I'm going to close this as won't fix. I don't think the ui behavior change is merited. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3975#comment:13> Mutt <http://www.mutt.org/> The Mutt mail user agent
Re: [Mutt] #3980: Can we integrate support for /etc/mailname?
#3980: Can we integrate support for /etc/mailname? +-- Reporter: antonio@… | Owner: mutt-dev Type: defect | Status: closed Priority: trivial| Milestone: Component: mutt |Version: 1.9.1 Resolution: wontfix| Keywords: patch +-- Changes (by kevin8t8): * status: new => closed * resolution: => wontfix Comment: Sorry Antonio, but it sounds like the consensus is against this. I'm going to close it as won't fix. -- Ticket URL: <https://dev.mutt.org/trac/ticket/3980#comment:9> Mutt <http://www.mutt.org/> The Mutt mail user agent
