On Thu, Apr 23, 2020 at 07:11:08AM -0700, Kevin J. McCarthy wrote:
Claus, would it be acceptable for Mutt to normalize the email
addresses you send or reply to? That way, 2047-encoding and IDNA
can be properly applied.
As a compromise for this release, I have pushed a change that disables
wr
On Thu, Apr 23, 2020 at 07:11:08AM -0700, Kevin J. McCarthy wrote:
Claus, would it be acceptable for Mutt to normalize the email
addresses you send or reply to? That way, 2047-encoding and IDNA can
be properly applied.
A patch for that behavior would look like this:
diff --git a/rfc2047.c b/
On Thu, Apr 23, 2020 at 01:56:32PM +0200, Vincent Lefevre wrote:
On 2020-04-23 09:47:08 +0200, Claus Assmann wrote:
On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
> I think I would prefer to make "exact address" deprecated in 1.14 and remove
> it for 1.15.
Then I would not upgrade to 1.15 (not
On 2020-04-23 09:47:08 +0200, Claus Assmann wrote:
> On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
>
> > I think I would prefer to make "exact address" deprecated in 1.14 and remove
> > it for 1.15.
>
> Then I would not upgrade to 1.15 (not that anyone would care...)
>
> I hate it if a program
On 2020-04-23 09:07:32 +0200, Gero Treuner wrote:
> In general I suggest to consider distributions, giving them an
> opportunity to not miss the deprecated message to users within their
> next release cycle before execution. That leads to 2-3 years resp. more
> than 1 release of Mutt (for cases wit
On Wed, Apr 22, 2020, Kevin J. McCarthy wrote:
> I think I would prefer to make "exact address" deprecated in 1.14 and remove
> it for 1.15.
Then I would not upgrade to 1.15 (not that anyone would care...)
I hate it if a program "hides" the actual data and instead presents
some form its authors
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 cas
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 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:
Ar
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, inclu
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 fil
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 a
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 =?utf-8?B?V8OkY2g/IDxzZW5kZXJAZX
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 encodin
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 encod
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 p
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 it
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 =?utf-8?B?V8OkY2g/IDxzZW5kZXJAZXhhbXBsZS5jb20+?
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/?=
T
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/?=
which then caused an error when "Sender" replied back to me...
21 matches
Mail list logo
