On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
> For now, you can try this patch. I'll think about whether to include it in
That looks good in my simple tests, thanks!
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
you're leaking the random strings. i suggest passing in fixed-size
buffers instead.
I am not sure I understand how the random strings are being leaked,
and I'd
On Thu, Apr 23, 2020 at 12:58:04AM +0200, Vincent Lefevre wrote:
but your example does not use this old syntax.
Unfortunately, the exact address code makes a copy of all addresses, not
just old syntax ones.
One of the solutions I suggested would be to only copy for the old
syntax but:
On Wed, Apr 22, 2020 at 08:31:29PM -0400, re...@webconquest.com wrote:
I have tried to reproduce this issue with and without
--enable-exact-address, and unless I did something wrong (very well
possible), I observed the issue with both set ups.
It encoded the To: header to iso8859 for me,
On Mon, Apr 20, 2020 at 11:18:55AM +0200, Oswald wrote in
<20200420091855.GA283365@ugly>:
+ r = rand_uint64();
+
+ rbuf[0] = r & 0xFF;
+ rbuf[1] = (r >> 8) & 0xFF;
+ rbuf[2] = (r >> 16) & 0xFF;
+ rbuf[3] = (r >> 24) & 0xFF;
+ rbuf[4] = (r >> 32) & 0xFF;
+ rbuf[5] = (r >> 40) &
On Mon, Apr 20, 2020 at 04:52:13PM +0200, Vincent wrote in
<20200420145213.gb726...@zira.vinc17.org>:
Since you're interested only in a 64-bit unsigned number, this
should be:
r = r * ((uint64_t) RAND_MAX + (uint64_t) 1) + (uint64_t) random();
Thanks, I will incorporate this in the patch!
On Tue, Apr 21, 2020 at 09:54:17AM +0200, Gero wrote in
<20200421075417.gv11...@innocircle.com>:
One thing, though: use base36, not base64 - as recommended in [0].
Base64 only saves 4 characters and you don't necessarily need to put all
160 bits of the sha1 into the Message-ID.
Also agreed.
On Mon, Apr 20, 2020 at 06:57:29PM +0200, Vincent wrote in
<20200420165729.ge726...@zira.vinc17.org>:
Between 13:23 and 18:23, either Derek didn't send any mail, or he did
send mail (with another Mutt instance). Or perhaps he sent 26 messages
elsewhere with the same instance (though this is
On Mon, Apr 20, 2020 at 01:14:40PM -0700, Kevin wrote in
<20200420201440.gg17...@afu.lan>:
On Mon, Apr 20, 2020 at 08:20:08PM +0100, Steve Karmeinsky wrote:
I’d agree with that sentiment
Thank you ilf and Steve.
But the phrase "standing on the shoulders of giants" is very true in
this case.
On Thu, Apr 23, 2020 at 12:58:04AM +0200, Vincent wrote in
<2020045804.ga1081...@zira.vinc17.org>:
> BTW: I use --enable-exact-address as otherwise mutt shows addresses
> in a "nice" format that doesn't match reality and caused me grief
> several times when I copied those addresses into a
On Wed, Apr 22, 2020 at 02:57:22PM -0700, Kevin J. McCarthy wrote:
The "exact address" is also a mess with respect to IDNA encoding.
Fixing it will require some thought. The whole point was to capture
the address "as typed", but we have to parse it to properly apply 2047
and IDNA.
Looking
On 2020-04-22 14:45:35 +0200, Claus Assmann wrote:
> On Thu, Feb 27, 2014, Claus Assmann wrote:
> > When replying to an address that used an utf-8 encoded name, e.g.,
> >
> > From: =?utf-8?B?U2VuZGVyIFfDpGNoCg==?=
> >
> > mutt turned this into
> >
> > To: Sender
On Wed, Apr 22, 2020 at 02:31:32PM -0700, Kevin J. McCarthy wrote:
I'm looking at whether encode_specials should be set for the exact
address (ptr->val) value. My suggestion would be to try turning it
off as a workaround for now.
The "exact address" is also a mess with respect to IDNA
On Wed, Apr 22, 2020 at 10:50:42PM +0200, Claus Assmann wrote:
I've added some debugging (see below) and found this:
rfc2047_encode_adrlist: in:M� V�z Garc�a
rfc2047_encode_adrlist:
out:=?iso-8859-1?B?TaogVuF6IEdhcmPtYSA8ckBlc210cC5vcmc+?=
(I set charset=iso-8859-1 for my tests)
So it's
I've added some debugging (see below) and found this:
rfc2047_encode_adrlist: in:M? V?z Garc?a
rfc2047_encode_adrlist:
out:=?iso-8859-1?B?TaogVuF6IEdhcmPtYSA8ckBlc210cC5vcmc+?=
(I set charset=iso-8859-1 for my tests)
So it's encoding the entire address, not just the display name.
I guess some
On Wed, Apr 22, 2020 at 05:55:21PM +0200, Claus Assmann wrote:
I haven't take a look at the problem yet; just wanted to know whether to
look out for something I've done or a deeper problem.
Looks like "a deeper problem" :-(
Thanks, and hopefully someone who is familiar with the code can fix
On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
> Claus, I see this is a reply from a 2014 email to the list. Has the problem
> been continuous since then, or did it get fixed and then broken again?
It seems it never got fixed. I guess I ignored it as the problem
happened very seldom. However,
On Wed, Apr 22, 2020 at 02:45:35PM +0200, Claus Assmann wrote:
On Thu, Feb 27, 2014, Claus Assmann wrote:
When replying to an address that used an utf-8 encoded name, e.g.,
From: =?utf-8?B?U2VuZGVyIFfDpGNoCg==?=
mutt turned this into
To: Sender
On Thu, Feb 27, 2014, Claus Assmann wrote:
> When replying to an address that used an utf-8 encoded name, e.g.,
>
> From: =?utf-8?B?U2VuZGVyIFfDpGNoCg==?=
>
> mutt turned this into
>
> To: Sender =?utf-8?B?V8OkY2g/IDxzZW5kZXJAZXhhbXBsZS5jb20+?=
> instead of
> To: Sender =?utf-8?B?V8OkY2g/?=
On 2020-04-21 23:21:14 +0100, Ian Collier wrote:
> On Tue, Apr 21, 2020 at 11:16:03PM +0200, Vincent Lefevre wrote:
> > This is a user-side problem. Users should make sure that their
> > hostname setting is unique (possibly with a very high probability,
> > assuming no attacks). See below.
>
>
20 matches
Mail list logo
