On Tue, Jun 02, 2020 at 01:00:55AM +0200, Oswald Buddenhagen wrote:
> On Mon, Jun 01, 2020 at 06:55:36PM +0200, ashelia1...@gmail.com wrote:
> > Starting from the UTF7 module in the glibc and modifying it for
> > UTF7 IMAP does not seem too hard.
> >
> i'd do that, but i wouldn't bother trying to
On Mon, Jun 01, 2020 at 06:55:36PM +0200, ashelia1...@gmail.com wrote:
Starting from the UTF7 module in the glibc and modifying it for
UTF7 IMAP does not seem too hard.
i'd do that, but i wouldn't bother trying to make it an actual iconv
module - just produce utf-16 or wchar_t strings (or whate
On Sun, May 31, 2020 at 02:14:39PM +0200, Oswald Buddenhagen wrote:
> - utf-7 support is required by the imap standard, so mbsync is actually
> buggy and this needs fixing anyway.
I see, that was too easy ^.
I thought of an alternative solution to the previous patches I sent :
use a custom gconv
On Sat, May 30, 2020 at 02:52:17PM +0200, Max Gautier wrote:
But I think there is an easier solution to the problem, which involves
fewer hoops and less code.
yeah. a bit *too* easy, though:
- utf-7 support is required by the imap standard, so mbsync is actually
buggy and this needs fixing a
Hi again,
I had some troubles simplifying the UTF-7 transcoding in an elegant way
and without code duplication.
But I think there is an easier solution to the problem, which involves
fewer hoops and less code.
The [RFC 6855][1] specifies the UTF8=ACCEPT and UTF8=ONLY IMAP server
capabilities, wh
