On Fri, May 10, 2024 at 02:16:12AM +0200, Eike Rathke wrote:
> Hi,
>
> On Thursday, 2024-05-09 19:15:59 -0400, Derek Martin wrote:
>
> > Probably fine for preventing casual eavesdropping, but for genuinely
> > sensitive applications, should not be considered good enough
On Wed, May 08, 2024 at 03:49:12PM +0200, Werner Koch wrote:
> Hi!
>
> Thanks for the summary. I fully agree add these 2 cents:
Thanks.
> In particular using a fixed subject is not going to work in any real
> business because you are not able to ignore mails. For my part, I even
> use a
On Mon, Apr 29, 2024 at 10:53:38PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
> |> 1. https://github.com/autocrypt/protected-headers
> |> 2. https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/
> |
> |Neat. But this feature seems like a m
w you are communicating, or
perhaps whether you should be communicating at all.
> Derek Martin:
> > Yeah unfortunately, as Kevin admitted, this feature was never discussed
> > here when it was implemented
>
> Within the Mutt project, both Autocrypt and protected headers were
> discussed.
On Fri, Apr 26, 2024 at 01:19:44AM +0200, Alejandro Colomar wrote:
> Yeah, most people don't even use PGP
Exactly. On top of that, you have to use one of the small handful of
clients that support it, and then (for at least some of those) you
have to turn it on. Like I said, virtually no one.
On Thu, Apr 25, 2024 at 11:07:30PM +0200, Alejandro Colomar wrote:
> While I don't have proof that no clients have major breakage with these
> header fields, I can say that the most important ones don't have major
> breakage.
Who are you to decide what the most important clients are? If my
On Thu, Apr 25, 2024 at 10:22:16PM +0200, Steffen Nurpmeso wrote:
> You talk to the wrong person given that other people added that
> mechanism and put it into practical use.
Yeah unfortunately, as Kevin admitted, this feature was never
discussed here when it was implemented, so those who care
On Wed, Apr 24, 2024 at 01:07:10AM +0200, Steffen Nurpmeso wrote:
> Sirius via Mutt-dev wrote in
> |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
On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote:
> On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> > However, saying that mutt adds those headers by accident or as a bug seems a
> > bit uninformed.
>
> Fair enough.
But--and I s'pose I may h
On Fri, Apr 19, 2024 at 10:10:13PM +0200, Alejandro Colomar wrote:
> Hi Derek,
>
> On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote:
> > On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> > > It's odd to me that, since OpenPGP and
On Fri, Apr 19, 2024 at 09:58:42PM +0200, Alejandro Colomar wrote:
> I think these days MIME is not so frowned upon as it once was. But you
> have a point. patatt(5) actually implements an idea like yours for
> signing patches including header fields, precisely for avoiding MIME.
To be clear, I
On Fri, Apr 19, 2024 at 09:30:27PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
> <20240419191717.ge2...@bladeshadow.org>:
> ...
> |Secondly, there is a standard mechanism for adding non-standard
> |headers to e-mail: use the string "X-" before the thi
On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> It's odd to me that, since OpenPGP and S/MIME both support MIME
> encapsulation that the draft standard wouldn't use a separate MIME part
> to handle the protected headers vs. stuffing it at the top of the
> message body, which just
On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> Signing header fields sounds reasonable, but I don't entirely like an
> implementation that puts a copy of them in the message body, to be covered
> by GPG. I'd prefer something more direct, that signs headers without
> copying
On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.
Fair enough.
--
Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an
On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote:
> The message interception scenario is possible, but I think highly
> improbable, especially for the sort of people who are using Mutt and
> encryption--savvy users. It requires the attacker have superuser
> access to the
On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote:
> BTW, now that I remember, while developing these things for neomutt(1),
> I found that mutt(1) has a bug (?) by which it does actually protect
> some header fields precisely in the way that I implemented them in
> neomutt(1),
On Thu, Apr 18, 2024 at 11:59:29PM +0200, Alejandro Colomar wrote:
> Protecting the recipients and the in-reply-to doesn't mean hiding it.
> It means providing a copy inside the signed part, so that it can be
> verified against tampering. It's not about encrypting them.
You can already do this
On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:
> Hi mutt(1) and neomutt(1) developers!
>
> I reported around a month ago a couple of security vulnerabilities to
> neomutt(1), but which are also present in mutt(1) and every MUA
> (probably, I didn't do an exhaustive research).
On Thu, Dec 14, 2023 at 12:22:22AM +0100, Vincent Lefevre wrote:
> > Mutt is a user application that already provides two methods of
> > exiting the program "nicely" with two different behaviors: Save state
> > or don't. CTRL-C/SIGINT allows for a third way to terminate the
> > program when it
On Wed, Dec 06, 2023 at 03:10:11PM +0100, Vincent Lefevre wrote:
> The behavior of SIGINT (typically generated by Ctrl-C in the terminal)
> is not documented.
>
> It currently asks whether to exit, with MUTT_YES as the default:
[...]
> Why doesn't it use "query_quadoption (OPT_QUIT," like and ?
On Wed, Nov 15, 2023 at 09:05:15PM +0100, Alejandro Colomar wrote:
> Hi Darek,
Derek.
> > So, acknowledging that this discussion is mostly academic since
> > there seems not to be anyone to maintain/support new features...
>
> Yes, it's still academic and useful, since I plan to patch
On Wed, Nov 15, 2023 at 07:10:52PM +0100, Alejandro Colomar wrote:
> On Wed, Nov 15, 2023 at 04:13:14PM +0100, Werner Koch wrote:
> > Hi!
> >
> > On Fri, 10 Nov 2023 01:41, Alejandro Colomar said:
> >
> > > This is breaking behavior, so it needs some more justification than just
> > > the above.
On Wed, Sep 14, 2022 at 02:53:27PM +0200, Magnus Groß wrote:
> The thing is that even according to your definition, mutt is
> behaving incorrectly: The outgoing message saved via "record" is
> **not** a newly received message.
Yes, it is. Which is to say, when you place a message in a mail
On Wed, Jan 26, 2022 at 10:21:52AM -0800, Will Yardley wrote:
> On Mon, Jan 24, 2022 at 11:30:56AM +0100, Eike Rathke wrote:
> > On Sunday, 2022-01-23 09:47:57 -0800, Kevin J. McCarthy wrote:
> >
> > > Thank you all for your support, and to the development team for
> > > giving me the
On Fri, Jan 14, 2022 at 11:05:14AM +0300, Jean Louis wrote:
>The "Subject:" field is the most common and contains a short
>string identifying the topic of the message. When used in a
>reply, the field body MAY start with the string "Re: " (an
>abbreviation of the Latin "in re",
On Fri, Jan 14, 2022 at 09:10:19AM +0200, Tapani Tarvainen wrote:
> On Thu, Jan 13, 2022 at 08:20:55PM -0800, Kevin J. McCarthy (ke...@8t8.us)
> wrote:
>
> > I've been told other prefixes are often used in some lists, and the
> > practice is getting more common.
>
> Other prefixes have also
On Fri, Jan 14, 2022 at 04:27:10PM -0600, Derek Martin wrote:
> On Thu, Jan 13, 2022 at 09:25:27PM -0800, Kevin J. McCarthy wrote:
> > On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote:
> > > Kevin J. McCarthy wrote on Thu, 13 Jan 2022
> > > at 23:20:55 E
On Fri, Jan 14, 2022 at 09:37:06AM +0100, Vincent Lefevre wrote:
> On 2022-01-13 19:41:12 -0800, Will Yardley wrote:
> > On Thu, Jan 13, 2022 at 09:42:27PM -0500, John Hawkinson wrote:
> > > Perhaps language from RFC5322 Sec. 3.6.5 should be imported into the
> > > documentation for $reply_prefix,
On Thu, Jan 13, 2022 at 09:25:27PM -0800, Kevin J. McCarthy wrote:
> On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote:
> > Kevin J. McCarthy wrote on Thu, 13 Jan 2022
> > at 23:20:55 EST in :
> >
> > > I've been told other prefixes are often used in some lists, and the
> > >
On Fri, Jan 14, 2022 at 03:26:36AM +0100, Vincent Lefevre wrote:
> I strongly disagree with the addition of $reply_prefix
> (commit 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is
> contrary to RFC 5322, and non-standard prefixes are annoying
> in practice and not necessarily recognized by
On Fri, Jan 14, 2022 at 03:19:39AM +0100, Vincent Lefevre wrote:
> On 2022-01-13 15:36:04 -0600, Derek Martin wrote:
> > So... The only difference between this and hdrdefault is that
> > hdrdefault's order does not matter. This is a very minor difference,
> > and the dist
On Thu, Jan 13, 2022 at 06:22:26PM +0100, Vincent Lefevre wrote:
> On 2022-01-12 14:40:38 -0600, Derek Martin wrote:
> > FWIW (particularly with this fixed) I think hdrdefault is redundant,
>
> I don't think it is. IMHO, hdrdefault means the color when no other
> rules match.
On Tue, Jan 11, 2022 at 05:53:45PM -0800, Kevin J. McCarthy wrote:
> On Tue, Jan 11, 2022 at 03:32:09PM -0600, Derek Martin wrote:
> > OK but do you agree that behavior is wrong? :) It's one header,
> > regardless of the wrapping...
>
> I'll have to think more closely
On Tue, Jan 11, 2022 at 11:48:38AM -0800, Kevin J. McCarthy wrote:
> On Tue, Jan 11, 2022 at 12:48:03PM -0600, Derek Martin wrote:
> > On Mon, Jan 10, 2022 at 05:27:32PM -0800, Kevin J. McCarthy wrote:
> > > Can you provide a minimal reproduce of the problem?
> >
>
On Mon, Jan 10, 2022 at 04:45:04PM -0800, Dan Fandrich wrote:
> On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote:
> > 1. Does anyone have any idea why ubuntu is shipping such an ancient
> >version of Mutt? ;-)
>
> 1.13.2 was the most recent release of mutt at
On Mon, Jan 10, 2022 at 06:21:58PM -0600, Derek Martin wrote:
> > I much prefer:
> > #!/bin/sh
> > absent some special reason. /bin/sh exists on all POSIX systems, and
> > bash need not (and if it does, it is not always in /bin).
>
> I agree wholeheartedly, and
I recently was given a laptop by my employer, running Ubuntu 20. I
have some disincentive (which I may ignore, given sufficient reason)
to run what they provide. It seems to ship with mutt-1.13.2. So, now
I have TWO questions...
1. Does anyone have any idea why ubuntu is shipping such an
On Mon, Nov 01, 2021 at 11:47:40AM +1100, Cameron Simpson wrote:
> On 17Oct2021 15:04, Oskari Pirhonen wrote:
> >#! /bin/bash
>
> I much prefer:
> #!/bin/sh
> absent some special reason. /bin/sh exists on all POSIX systems, and
> bash need not (and if it does, it is not always in /bin).
I
On Sat, Jan 08, 2022 at 02:46:48PM -0800, Kevin J. McCarthy wrote:
> I'm thinking about enabling $rfc2047_parameters by default, and would like
> to hear any counter-arguments against this.
I believe the original argument against was that doing so violates the
RFCs, and therefore potentially
On Tue, Nov 23, 2021 at 04:40:28PM -0600, Aaron Poffenberger wrote:
> As for making the fqdn of the From-address available during Message-ID
> generation, I see value in it regardless. But it's not my software. I
> don't get to decide. I'll leave it as it always was: a suggestion.
At any rate,
On Tue, Nov 23, 2021 at 05:52:00PM -0600, Aaron Poffenberger wrote:
> On 2021-11-23 17:28 -0600, Derek Martin wrote:
> > > My mail domain has had correct reverse DNS entries for ages. As soon
> > > as I received the error I verified it from multiple hosts to be sure.
>
On Mon, Nov 22, 2021 at 11:22:33AM -0600, Aaron Poffenberger wrote:
> On 2021-11-22 16:48 +, Claus Assmann wrote:
> > I'm not sure the problem is really related to "fqdn of the Message-ID",
> > could you give a real example:
> > sending from the same host using the same addresses but two
On Tue, Nov 02, 2021 at 07:10:24PM +0100, Petr Pisar wrote:
> V Mon, Nov 01, 2021 at 11:44:25AM +1100, Cameron Simpson napsal(a):
> For that purposes I added ^[3J sequence into Linux 3.0 which erases not only
> whole display but also a scroll-back buffer of the terminal. (Though Linux
>
On Tue, Nov 02, 2021 at 12:17:17PM +0100, Vincent Lefevre wrote:
> On 2021-10-29 14:19:29 -0500, Derek Martin wrote:
> > On Wed, Oct 27, 2021 at 05:10:35PM +0200, Vincent Lefevre wrote:
> > > I was wondering whether this could occur when switching to the
> > > alt
On Wed, Oct 27, 2021 at 05:10:35PM +0200, Vincent Lefevre wrote:
> On 2021-10-25 14:44:32 -0500, Derek Martin wrote:
> > There is an ANSI escape sequence to tee data to your printer, sure...
> > but it can not be used retroactively copy data that is on your
> > terminal to
On Sat, Oct 23, 2021 at 02:04:08PM +0200, Vincent Lefevre wrote:
> On 2021-10-22 10:30:43 -0700, Kevin J. McCarthy wrote:
> > On Fri, Oct 22, 2021 at 12:51:04PM +0200, Vincent Lefevre wrote:
> > > Following my remark about the privacy reason, I think that the patch
> > > would be useful to make
On Fri, Jul 23, 2021 at 03:30:01AM +0200, Vincent Lefevre wrote:
> On 2021-07-22 09:11:56 -0700, Kevin J. McCarthy wrote:
> > What do you think of using memccpy in the strfcpy macro,
>
> IMHO, it is better than strncpy, which unnecessarily pads with
> null bytes.
>
> > if it's available, as Ian
On Mon, Jan 11, 2021 at 08:22:08AM +, Eric Wong wrote:
> Derek Martin wrote:
> Well, mistakes happen... How we deal with them moving forward
> is important, though.
I certainly agree with that.
> Fwiw, I concur the PID in Message-IDs was a bad idea since it
> does unn
On Sat, Jan 09, 2021 at 10:54:28PM +, Eric Wong wrote:
> Hi Remco,
>
> So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac
> (I noticed this in mutt 2.0.2 on FreeBSD)
>
> This is a bad change
You should have just stopped there. This is a bad change, as I argued
when it was
On Thu, Nov 12, 2020 at 04:03:28PM +, Ian Collier wrote:
> On Thu, Nov 12, 2020 at 09:22:45AM -0600, Derek Martin wrote:
> > One point that is not clear to me is, the sigaction manpage explicitly
> > calls out execve, rather than the whole exec family. It seems to
> >
On Thu, Nov 12, 2020 at 12:18:07PM +0100, Oswald Buddenhagen wrote:
> On Thu, Nov 12, 2020 at 10:31:59AM +0100, Matthias Apitz wrote:
> > El día miércoles, noviembre 11, 2020 a las 02:34:57p. m. -0600, Derek
> > Martin escribió:
> > > > > It *is* supported by mutt
On Wed, Nov 11, 2020 at 08:50:27PM -0600, Derek Martin wrote:
> On Wed, Nov 11, 2020 at 02:34:57PM -0600, Derek Martin wrote:
> background.c:
> background_edit_landing_page() has this code:
>
> while (!done)
> {
> wait_rc = waitpid (bg_pid, NULL, WNOHANG);
>
On Wed, Nov 11, 2020 at 08:50:27PM -0600, Derek Martin wrote:
> On Wed, Nov 11, 2020 at 02:34:57PM -0600, Derek Martin wrote:
> Fixing this almost certainly won't fix Matthias' problem, but may at
> least help make it clear why it's happening. There's also a bit of
> tricki
On Thu, Nov 12, 2020 at 01:20:06AM +0100, Oswald Buddenhagen wrote:
> On Wed, Nov 11, 2020 at 02:34:57PM -0600, Derek Martin wrote:
> > On Sat, Nov 07, 2020 at 01:06:00PM +0100, Matthias Apitz wrote:
> > > Does whatever the server is doing affect the mutt process too,
> >
On Wed, Nov 11, 2020 at 02:34:57PM -0600, Derek Martin wrote:
> [...] I would also agree that Mutt's exit status handling is
> incomplete. That probably needs to be fixed. I'd need to review
> the code in more detail to be confident about whether
> blocking/ignoring SIGCHLD is
Hello Matthias,
On Sat, Nov 07, 2020 at 01:06:00PM +0100, Matthias Apitz wrote:
> For more information, and before replying, please read the thread
> http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20201102/002057.html
> (even if the Subject: is wrong, because I started with this Subject:
On Tue, Aug 18, 2020 at 06:34:27AM -0400, Remco Rijnders wrote:
> On Mon, Aug 17, 2020 at 10:37:57PM -0500, Derek wrote in
> <20200818033757.gd28...@bladeshadow.org>:
> > It's worth pointing out one additional point that I haven't: The
> > data in an attachment might be considered sensitive by the
On Fri, Aug 14, 2020 at 11:14:27AM +0200, sacham...@s0c4.net wrote:
> Hi all,
>
> thank you all for this long discussion. Your security concerns are
> clear, as is clearer the intended system-usage scenario (most of you
> have) and Mutt's role in there.
It's worth pointing out one additional
On Thu, Aug 13, 2020 at 10:03:43PM +0200, Vincent Lefevre wrote:
> On 2020-08-11 22:29:41 -0500, Derek Martin wrote:
> > The subversion example is a special case of an application that you
> > use through a web server, that has its own security implications.
>
> Wrong! Sub
On Wed, Aug 12, 2020 at 11:29:06PM +0200, Oswald Buddenhagen wrote:
> On Wed, Aug 12, 2020 at 03:41:50PM -0500, Derek Martin wrote:
> > On Wed, Aug 12, 2020 at 03:16:46PM +0200, Oswald Buddenhagen wrote:
> > > meanwhile, kevin has been actively hostile towards changes he didn't
&
On Wed, Aug 12, 2020 at 03:16:46PM +0200, Oswald Buddenhagen wrote:
> On Wed, Jul 29, 2020 Derek wrote:
> > I'll be honest--what I'd really prefer to see is the two projects merge,
> > where "NeoMutt" would be the place were things were tried, fleshed out,
> > and refined so that they could be
On Wed, Aug 12, 2020 at 02:40:16AM +0200, Vincent Lefevre wrote:
> On 2020-08-06 18:40:50 -0500, Derek Martin wrote:
> > Are you serious, Vincent? I'm pretty sure you well know that this is
> > a horrible idea, clearly contrary to best security practices, that no
> > compet
On Fri, Aug 07, 2020 at 02:31:01PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
> <20200806234050.gb8...@bladeshadow.org>:
> |On Fri, Aug 07, 2020 at 12:56:34AM +0200, Vincent Lefevre wrote:
> |> On 2020-08-06 10:50:23 -0500, Derek Martin wrote:
> |>>
On Fri, Aug 07, 2020 at 12:56:34AM +0200, Vincent Lefevre wrote:
> On 2020-08-06 10:50:23 -0500, Derek Martin wrote:
> > On Wed, Jul 29, 2020 at 12:55:07PM -0500, Derek Martin wrote:
> > > On Tue, Jul 28, 2020 at 08:03:23PM +0200, sacham...@s0c4.net wrote:
> > > &
On Wed, Jul 29, 2020 at 12:55:07PM -0500, Derek Martin wrote:
> On Tue, Jul 28, 2020 at 08:03:23PM +0200, sacham...@s0c4.net wrote:
> > The thread, and even older threads referenced there, is from 2007.
> > Since then, the security field have evolved - now we have SeLinux,
> &g
On Tue, Jul 28, 2020 at 12:59:55AM +0200, Mono DHS wrote:
> Subject says it all
What is the motivation for this patch?
My initial reaction is this patch adds a bunch of configure code that
will be used by pretty close to no one, so I don't see the value. It
will surprise no one who's been
On Tue, Jul 28, 2020 at 08:03:23PM +0200, sacham...@s0c4.net wrote:
> The thread, and even older threads referenced there, is from 2007.
> Since then, the security field have evolved - now we have SeLinux,
> Apparmor and other techniques which are capable to provide even
> better security than
On Sun, Jul 26, 2020 at 03:04:33AM +0300, Maxim Tarasov wrote:
> ---
> init.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/init.h b/init.h
> index 06d4cc9a..f0d2c697 100644
> --- a/init.h
> +++ b/init.h
> @@ -920,7 +920,7 @@ struct option_t MuttVars[] = {
>{
On Wed, Jul 29, 2020 at 01:06:00PM +0100, Richard Russon wrote:
> > I'm going to take a few weeks off from Mutt development.
>
> Thanks for all your hard work on Mutt.
Agree!
> > Five years later
>
> You've been *maintaining* Mutt, but we've been *developing* NeoMutt.
First off I think that's
On Fri, Jul 24, 2020 at 06:56:38AM +0200, Claus Assmann wrote:
> On Fri, Jul 24, 2020, Tom Ryder wrote:
>
> > > > +env->subject = safe_strdup ("Re:");
>
> > Would you or Maxim consider making it a _("translatable string")---or
> > perhaps even better, a configurable one---for those who speak
On Thu, Jul 23, 2020 at 07:15:11PM +0300, Maxim Tarasov wrote:
> First, "Re: your mail" sounds like a spam mail heading and doesn't
> convey any useful information.
True enough, but, the fault is with the original sender for not
providing a meaningful subject, and if they don't want to receive
On Mon, May 11, 2020 at 08:38:19PM +0200, Steffen Nurpmeso wrote:
> Vincent Lefevre wrote in
> <20200510204809.ga71...@zira.vinc17.org>:
> |Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
> |dotlocking still used nowadays?
>
> I find yes. Or at least last i looked, some MTAs aka
On Fri, May 08, 2020 at 06:59:18AM +0200, Petr Pisar wrote:
> On Fri, May 08, 2020 at 06:42:57AM +0200, Claus Assmann wrote:
> > On Thu, May 07, 2020, Remco Rijnders wrote:
> >
> > > - dprint (1, (debugfile, "WEED is %s\n", (flags & CH_WEED) ? "Set" :
> > > "Not"));
> > > + dprint (1,
On Wed, May 06, 2020 at 11:44:06AM +0200, Christopher Zimmermann wrote:
> Hello dear mutt developers,
> I prepared a merge request that needs some consideration.
[...]
Surprising absolutely no one I'm sure, I agree with Kevin. You
already found the correct solution to your problem (use stty to
On Fri, Apr 24, 2020 at 09:57:59AM -0500, Derek Martin wrote:
> > Also note that year ranges (or list of years) are ambiguous. For
> > instance, this version of Mutt is not the one that was published
> > in 1996. The copyright notice should normally give only the year
> >
On Fri, Apr 24, 2020 at 04:16:00PM +0200, Vincent Lefevre wrote:
> On 2020-04-23 13:29:54 -0500, Derek Martin wrote:
> > On Mon, Apr 20, 2020 at 08:09:08PM +0200, ilf wrote:
> > > I think it's fair to honor Kevin as maintainer more than "others".
> > > I woul
On Mon, Apr 20, 2020 at 08:09:08PM +0200, ilf wrote:
> Vincent Lefevre:
> > > > Copyright (C) 1996-2016 Michael R. Elkins and others.
> > > Thanks, but what should it be updated to say? Michael Elkins hasn't
> > > contributed since 2016. Is it correct to swap the date to 2020, or
> > > should I
On Sun, Apr 19, 2020 at 07:38:39AM -0400, Remco Rijnders wrote:
> On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek wrote in
> <20200419021334.go19...@bladeshadow.org>:
> > OK I'm getting pretty bored with this, it's already been decided by
> > Kevin it won't be accepted, but I'll answer this last
OK I'm getting pretty bored with this, it's already been decided by
Kevin it won't be accepted, but I'll answer this last message since it
attempts to directly address a challenge I made.
On Sat, Apr 18, 2020 at 08:00:24PM -0400, Remco Rijnders wrote:
> On Sat, Apr 18, 2020 at 06:23:53PM -0500,
On Sun, Apr 19, 2020 at 01:03:06AM +0200, Oswald Buddenhagen wrote:
> On Sat, Apr 18, 2020 at 01:23:50PM -0500, Derek Martin wrote:
> > On Sat, Apr 18, 2020 at 01:57:50PM -0400, Remco Rijnders wrote:
> > > On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in
> > > &g
On Sun, Apr 19, 2020 at 12:33:19AM +0200, Oswald Buddenhagen wrote:
> On Sat, Apr 18, 2020 at 12:04:05PM -0500, Derek Martin wrote:
> > OK, please enlighten me: Tell me what you've learned,
> >
> nothing, because i don't care. ;)
>
> > how it's any worse than
On Sat, Apr 18, 2020 at 01:57:50PM -0400, Remco Rijnders wrote:
> On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in
> > In other words, this scheme does not guarantee uniqueness, and is
> > therefore broken.
>
> Well, the odds of the same number being selected are about 1 in 2 billion
>
I'd like finally to elaborate on just a couple more points:
On Sat, Apr 18, 2020 at 10:47:58AM -0700, Kevin J. McCarthy wrote:
> On Sat, Apr 18, 2020 at 08:41:47AM -0400, Remco Rijnders wrote:
> > On Fri, Apr 17, 2020 at 07:14:02PM -0700, Kevin wrote:
> > > I would also note that the current
On Sat, Apr 18, 2020 at 08:27:55PM +0300, Consus wrote:
> > > Nope, hostname it is, even if you're using built-in smtp.
> >
> > False. Try it.
>
> Check my headers :)
>
> > Tell mutt your hostname is your domain name. This is a common
> > configuration, so that mutt auto-generates your
On Sat, Apr 18, 2020 at 06:14:58PM +0200, ilf wrote:
> IMHO all the arguments also apply here. IMHO we should chose a form of
> Message-ID that (a) does not include unneccessary system information and (b)
> matches that of other MUAs. Maybe we should follow these "Recommendations
> for generating
On Sat, Apr 18, 2020 at 01:10:47PM +0300, Consus wrote:
> On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
> > On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> > > The Message-ID that mutt generates is supposed to be unique. Up till now
> &g
On Sat, Apr 18, 2020 at 08:26:56AM -0400, Remco Rijnders wrote:
> > - the PID is the only thing that could possibly be vaguely useful to
> > an attacker, but only if they're already able to get onto the
> > user's system, in which case finding out the PID will be trivial
> > anyway.
On Sat, Apr 18, 2020 at 11:07:34AM +0200, Oswald Buddenhagen wrote:
> > Because it adds additional complexity to the program for absolutely zero
> > practical gain.
> >
> actually, the patch makes the code simpler.
I admitted already I did not look at the patch, so I was speaking in
general
On Sat, Apr 18, 2020 at 04:17:45AM +0200, Gero Treuner wrote:
> On Fri, Apr 17, 2020 at 07:59:01PM -0500, Derek Martin wrote:
> > On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> > > The Message-ID that mutt generates is supposed to be unique. Up till now
> &g
On Fri, Apr 17, 2020 at 02:24:22PM -0400, Remco Rijnders wrote:
> The Message-ID that mutt generates is supposed to be unique. Up till now
> mutt would generate this ID based on the current date and time, followed by
> ".G". followed by a letter A to Z (A for the 1st and 27th email sent, Z for
>
On Tue, Mar 10, 2020 at 12:43:54PM +0300, Consus wrote:
> Hi,
>
> Have you considered ability to limit mailboxes that "beep" on new mail?
> Say, I have a bunch of IMAP mailboxes:
I think you can get what you want if you don't subscribe (i.e. use the
"mailboxes" command) to mailboxes you don't
On Tue, Mar 03, 2020 at 10:07:04AM -0800, Kevin J. McCarthy wrote:
> On Tue, Mar 03, 2020 at 10:40:52AM +0300, Consus wrote:
> > It seems like attachments counter (%X) is broken, at least in
> > pager_format. It always expands to 0, no matter how many attached files
> > there is.
>
> It seems to
On Mon, Sep 16, 2019 at 11:16:43AM -0700, Kevin J. McCarthy wrote:
> Just a heads up that I plan on releasing 1.12.2 this coming weekend.
>
> Derek, I feel confident in Gero's fix, but if you have the chance to compile
> and test before the weekend that would be great.
Tried it, looks good! And
On Mon, Sep 16, 2019 at 11:16:43AM -0700, Kevin J. McCarthy wrote:
> Just a heads up that I plan on releasing 1.12.2 this coming weekend.
>
> Derek, I feel confident in Gero's fix, but if you have the chance to compile
> and test before the weekend that would be great.
I'm still trying. I've
On Mon, Sep 09, 2019 at 06:12:49PM -0700, Kevin J. McCarthy wrote:
> On Wed, Sep 04, 2019 at 10:26:31AM -0500, Derek Martin wrote:
> > I'll try to look at this no later than this weekend...
>
> Derek, I've merged Gero's patch into the stable branch in git. It should
> co
I'll try to look at this no later than this weekend...
Thanks!
On Sun, Sep 01, 2019 at 06:19:17PM +0200, Gero Treuner wrote:
> Hi Derek,
>
> On Wed, Aug 28, 2019 at 02:16:10PM -0700, Kevin J. McCarthy wrote:
> > On Mon, Aug 26, 2019 at 02:12:56PM -0500, Derek Martin wrote:
>
On Wed, Aug 28, 2019 at 02:19:39PM -0700, Kevin J. McCarthy wrote:
> On Mon, Aug 26, 2019 at 02:29:22PM -0500, Derek Martin wrote:
> > However, just now, trying to pgp-sign this message, I got:
> >
> > gpg: can't query passphrase in batch mode
> > gpg: skipped "0xD
On Mon, Aug 26, 2019 at 02:12:56PM -0500, Derek Martin wrote:
> I may also just configure with --disable-filemonitor and try again,
> but I suspect I want whatever awesomeness that brings (I vaguely
> remember a discussion about this but sadly not the details).
FWIW this worked.
Howe
Folks,
I downloaded mutt-1.12.1 today, and tried to compile it. I ran
configure thusly:
./configure --enable-sidebar --enable-compressed --enable-hcache
Then make failed to link, thusly:
gcc -std=gnu99 -Wall -pedantic -Wno-long-long -g -O2 -L/lib -o mutt
addrbook.o alias.o attach.o
1 - 100 of 397 matches
Mail list logo
