On Sat, Jan 01, 2011 at 09:16:46AM +0100, Remco Rijnders wrote:
Having had a further look at this, it seems the address parser / tokenizer
sees ':' as a token to split on. I wonder if this is a widely used
convention or one solely used by mutt. If there is no valid use case for
seperating
On Mon, Jan 09, 2012 at 12:34:21PM +0100, Olaf Hering wrote:
there was a patch floating around (quite some time ago) which enabled mutt
to reconnect mail threads by inserting correct In-reply-to: and References:
header tags. I cant find the patch via google search. Also, I did not use
that
Hi all,
On Wed, Mar 30, 2016 at 11:14:48AM +0200, Vincent Lefevre wrote:
> > > I don't feel strongly about the date being there. How do the other
> > > developers feel about just removing the date?
>
> Well, I like to have the date (it can provide useful information,
> e.g. to make sure that
Hi,
On Mon, Apr 16, 2018 at 07:53:56AM -0500, Paul Keusemann wrote:
> I have just built mutt-1.9.5 on several platforms and ran into a problem
> with the version.sh script on systems where /bin/sh is not bash.
>
> This:
>
> { [ -e ".git" ] && command -v git >/dev/null 2>&1; } \
> || exec cat
oes
compare_stat() (which I couldn't use here anyway) care about st_rdev?
#ifdef:
More of these ;-) I consider it not a bad thing, because on the event
that mutt's architecture is modernized it helps to understand
dependencies.
So, have fun!
Kind regards,
Gero
commit aefde7a91eba442e021c8
Hi,
On Mon, Apr 02, 2018 at 03:12:49PM +0200, Gero Treuner wrote:
> Tested
>
> - Mailbox types: see above
> - General compilation: on Linux with/without **1 inotify
> - Sidebar compilation: breaks with same message in original and patched
> source with my configuration/s
On Thu, Apr 11, 2019 at 07:43:46PM -0700, Kevin J. McCarthy wrote:
> On Thu, Apr 11, 2019 at 10:08:56PM -0400, Aaron Schrab wrote:
> > There are already a few uses of __attribute__ in the mutt code; mostly
> > in `intl/` but also one in `monitor.c`.
> The monitor.c use did get through on my
Hi,
On Sat, Jun 22, 2019 at 12:24:16PM +0200, Vincent Lefevre wrote:
> FYI, due to incorrect mailcap rules, which use '%s' or similar
> instead of just %s, the filename quoting system in Mutt eventually
> makes the filename *unquoted*, i.e. reversing its purpose, e.g.
>
> "less
Hi Derek,
On Mon, Aug 26, 2019 at 02:29:22PM -0500, Derek Martin wrote:
> 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
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:
> > /home/ddm/tmp/mutt-1.12.1/buffy.c:276: undefined reference to
> > `mutt_monitor_remove'
> > /home/ddm/tmp/mutt-1.12.1/buffy.c:310: undefined reference
Hi,
On Fri, Nov 01, 2019 at 06:42:33AM +0800, Kevin J. McCarthy wrote:
> I'm looking for a bit of history and discussion of the correct behavior of
> MTAs with respect to Bcc headers.
I'm sure this was discussed many years ago (but I don't remember the
course).
> Ticket #185
Hi all,
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
> > mutt would generate this ID based on the current date and time, followed by
> >
Hi,
On Mon, Apr 20, 2020 at 05:03:00PM +0200, Matthias Andree wrote:
> Am 20.04.20 um 15:51 schrieb Kevin J. McCarthy:
> > My time is a bit limited to continue on this right now. But later, I
> > would appreciate others opinions about randomizing versus hashing
>
> Other than that, whatever
On Mon, Apr 20, 2020 at 05:57:00PM +0200, Vincent Lefevre wrote:
> On 2020-04-19 16:34:57 +0200, Gero Treuner wrote:
> > For the small purpose of avoiding collisions within a time frame of 1s
> > a couple of extra bytes are comparatively high cost IMO.
> >
> > But you a
Hi Vincent,
On Mon, Apr 20, 2020 at 07:38:06PM +0200, Vincent Lefevre wrote:
> > For hiding our pid etc. all data which can be found in the same email
> > or maybe related emails is of no use for feeding to the hash, because
> > it can easily be inserted as constants in brute-force searchs. Only
Hi Remco and all,
On Sun, Apr 19, 2020 at 08:02:05AM -0400, Remco Rijnders wrote:
> On the proposal to use a hashed value for the GA12345 part, I now have some
> doubts as I think it would be a small effort to iterate through all
> plausible values for this to regenerate the hashes and still make
Hi all,
On Mon, Apr 20, 2020 at 09:49:11PM +0100, Ian Collier wrote:
> As Arnt has implied, the current method of generating the Message-ID
> does not *guarantee* uniqueness; merely makes it highly improbable to
> be non-unique. The thing is that we are not just concerned with other
> instances
Hi,
> > > You would have to salt the values in some way before the hash and
> > > that might effect the deterministic part you'd like to keep.
> >
> salting doesn't make a hash collision more likely.
That's why more sources of deterministic data are required and the
reason to inspect inode data
Hi,
On Wed, Apr 22, 2020 at 09:05:28PM -0400, re...@webconquest.com wrote:
> On Mon, Apr 20, 2020 at 11:18:55AM +0200, Oswald wrote in
[...]
> Thanks, I will incorporate this in the patch!
Here is another patch calling the openssl/gnutls random functions if
compiled with any of those, otherwise
On Tue, Apr 21, 2020 at 10:54:25PM +0200, Vincent Lefevre wrote:
> On 2020-04-20 19:57:23 +0200, Gero Treuner wrote:
> > This is necessary to stay on the deterministic track: For this we
> > require that different Mutt instances use information which differs by
> > the pid and
Hi Kevin,
On Wed, Apr 22, 2020 at 06:21:01PM -0700, Kevin J. McCarthy wrote:
> Exactly. I don't think it's worth the trouble, and it still wouldn't
> completely fix the problems.
>
> I think I would prefer to make "exact address" deprecated in 1.14 and remove
> it for 1.15.
Probably in this
Hi Vincent,
On Sun, Apr 26, 2020 at 10:51:51PM +0200, Vincent Lefevre wrote:
> On 2020-04-26 02:33:00 +0200, Gero Treuner wrote:
> > The MessageId still starts with the time, but is now included in the
> > base64 part, joined with the random section before encoding.
>
> W
Hi Christopher,
On Thu, May 07, 2020 at 10:28:38AM +0200, Christopher Zimmermann wrote:
> On Thu, May 07, 2020 at 09:52:14AM +1000, Cameron Simpson wrote:
>
> On Thu, May 07, 2020 at 03:57:37AM +0200, Vincent Lefevre wrote:
>
> > On my Mutt pages https://www.vinc17.net/mutt/index.en.html
> > I
Hi,
On Thu, May 14, 2020 at 11:51:08AM +0200, Oswald Buddenhagen wrote:
> On Wed, May 13, 2020 at 08:03:02PM -0700, Kevin J. McCarthy wrote:
> > On Sun, Apr 19, 2020 at 01:03:06AM +0200, Oswald Buddenhagen wrote:
> > > on a tangent, mutt's thread linking features do not work if the
> > >
Hi,
On Thu, May 14, 2020 at 02:45:51PM +, Arnt Gulbrandsen wrote:
> FYI you need an @domain as well. Arnt
And as it is not fixable, because that would make it match nothing, I
second your solution to not use those without "@" for new messages.
Gero
Hi Oswald,
On Thu, May 14, 2020 at 02:37:31PM +0200, Oswald Buddenhagen wrote:
> On Thu, May 14, 2020 at 12:41:59PM +0200, Gero Treuner wrote:
> > This notifies about possible problems and transparently shows sender's
> > responsibility. If one of the users then complains at
On Thu, May 07, 2020 at 01:13:49PM +0200, Gero Treuner wrote:
> > > That's bad because it doesn't honor the way the user has configured
> > > his terminal. Moreover, I fear that in case of crash, this may leave
> > > the terminal settings in the altered state (zsh offe
Hi Christopher,
On Wed, May 06, 2020 at 11:44:06AM +0200, Christopher Zimmermann wrote:
> New functions `suspend` and `interrupt` are implemented.
> `suspend` is used to trigger SIGTSTP and is bound to \Cz by default.
> `interrupt` calls `mutt_query_exit` and is used to mimic the \Cc behaviour.
Hi Remco,
On Fri, May 29, 2020 at 03:51:52PM -0400, Remco Rijnders wrote:
> +/* Generate and Base64 encode 96 random bits and fill the buffer
> + output_B64 with the result. */
> +void mutt_base64_random96(char output_B64[static 17])
> +{
> + u_int32_t randombits[3] = { mutt_random32(),
Hi,
On Fri, May 29, 2020 at 03:33:28PM -0700, Kevin J. McCarthy wrote:
> On Fri, May 29, 2020 at 03:58:35PM -0400, Remco Rijnders wrote:
> I think your comments in make a good case for not
> putting crypto-level randomization into a PRNG function, and I would like to
> think about it before
Hi Kevin,
> I'm not thinking about performance issues, but about the use and possible
> misuse of entropy. I'm not even convinced it's appropriate for Message-ID,
> so I certainly wouldn't like to see it put in a generic function used for
> temp files and message part boundaries.
According to
Hi all,
Congratulations to all lead by Kevin for the release of Mutt 2.0!
This event is worth an article in the online portal of the leading IT
magazine for German speaking countries (supposedly printed issue follows
- we'll see in 2 weeks).
Title (translated)
Pure keyboard: Email client
Hi Gregory,
On Sun, Nov 15, 2020 at 01:24:36PM +, Gregory Heytings wrote:
> > I'm not convinced this would be a generally useful feature, though, and
> > I don't like to add options that have a user-size of "one".
> >
>
> I know, but in fact I'm convinced it could be a killer feature. It's
Hi all,
I stumbled over an issue with the subject these days, which I aleady saw
1-2 years ago, causing the subject to be displayed corruptly on another
device.
It looks that there are inconsistencies in various places (even on the
other device), and - while preparing for a fix - more knowledge
Hi Kevin,
On Thu, Nov 05, 2020 at 08:43:42AM -0800, Kevin J. McCarthy wrote:
> On Thu, Nov 05, 2020 at 04:47:20PM +0100, Gero Treuner wrote:
[...]
> > So the space between the encoded words is not shown,
>
> Yes, this is correct according the section 6.2 which Arnt mentione
Hi Arnt,
Thanks for the input.
On Thu, Nov 05, 2020 at 02:32:03PM +0100, Arnt Gulbrandsen wrote:
> On Thursday 5 November 2020 09:49:44 CET, Gero Treuner wrote:
> > * I interpret RFC2047 that separating encoded blocks by space (without
> > newline) means two words, so space shou
Hi Arnt,
On Thu, Nov 05, 2020 at 06:39:35PM +0100, Arnt Gulbrandsen wrote:
> On Thursday 5 November 2020 18:02:15 CET, Gero Treuner wrote:
> > Then the logic and also my case is compliant to the standard, although
> > it is not ideal to cut within plain text words when
Hi,
On Fri, May 13, 2022 at 06:14:13PM +0200, Ludolf Holzheid wrote:
> Of course it is possible for TUI programs to let the terminal wrap the
> lines. However, I expect it to be difficult to get it right for all
> terminals (and all corner cases).
>
> For your problem, a simple workaround might
38 matches
Mail list logo
