Hi Arnt,
On Wed, Oct 21, 2015 at 03:41:55PM +0100, Arnt Gulbrandsen wrote:
> Sorry about the late reply. I started cleaning up the windows on my desktop,
> and there were many old windows behind the emacs. (There actually was
> another eamcs hidden behind emacs, which I suppose shows that "eventua
Sorry about the late reply. I started cleaning up the windows on my
desktop, and there were many old windows behind the emacs. (There actually
was another eamcs hidden behind emacs, which I suppose shows that
"eventually mallocs all computer storage" is no longer correct.)
Kevin J. McCarthy wr
Hi Arnt,
Thanks for the reply. This email is really helpful!
On Fri, Sep 04, 2015 at 10:44:50AM +0100, Arnt Gulbrandsen wrote:
> Kevin J. McCarthy writes:
> >* First, my understanding is the rfc653x series is not incompatible with
> > IDNA2008. The introduction to rfc6530 mentions rfc5890 for
I wrote:
Matter of opinion. Mine is that SMTPUTF8 is enough. Mutt
doesn't carry out a server compliance test, it just sends mail,
so it should check the extension it wants to use. Checking other
extensions that are/may be implicitly used is a digression.
Let me elaborate on that.
Mutt uses a
Kevin J. McCarthy writes:
* First, my understanding is the rfc653x series is not incompatible with
IDNA2008. The introduction to rfc6530 mentions rfc5890 for domain
encoding, and in fact rfc6531 section 3.2 even says
It MAY transmit the domain parts of mailbox names within SMTP
On Sun, Aug 30, 2015 at 10:56:34AM -0700, Kevin J. McCarthy wrote:
> >
> > Kevin J. McCarthy writes:
> > >- Added the unicode logic to the imap_unmunge_mbox_name() call. (I'm
> > > assuming we shouldn't be trying to utf7 decode strings from the server
> > > after we've enabled utf8. If this is
Hi Arnt,
On Sun, Aug 30, 2015 at 03:27:38PM +0100, Arnt Gulbrandsen wrote:
> I'm home, and now have a big-enough screen to see both what I'm typing and
> the message to which I reply.
Great! I have no idea how you were able to compose those emails on a
tiny screen in the first place. I have a t
I'm home, and now have a big-enough screen to see both what I'm typing and
the message to which I reply.
Kevin J. McCarthy writes:
- Added the unicode logic to the imap_unmunge_mbox_name() call. (I'm
assuming we shouldn't be trying to utf7 decode strings from the server
after we've enabled
a...@gulbrandsen.priv.no wrote:
> Suppose you receive mail from my Unicode address. When you compose your
> reply, you do not know whether my SMTP server accepts an a-label form of any
> domains in your reply
Not true. Please again see rfc6531 section 3.2, paragraph 2, sentence 3.
> , so when yo
a...@gulbrandsen.priv.no wrote:
> I will reply properly when I am back at my keyboard this weekend. Just one
> thing now: the two extensions are subtly but crucially incompatible.
>
> Nothing in 653x requires a receiver to support idna (or a-label encoding of
> local parts), or to treat them the s
Arnt Gulbrandsen wrote:
> At any rate, I added RFC6531/6855 support to mutt. Please pull:
>
> https://bitbucket.org/arnt/mutt/commits/a83a4387c35384eccd3a11d74b8db4ebbb185d30
>
> Some earlier changesets need to be reverted. mutt_idna.c may have been a
> fine idea, but using idna in mail didn't ge
Arnt Gulbrandsen wrote:
> At any rate, I added RFC6531/6855 support to mutt. Please pull:
>
> https://bitbucket.org/arnt/mutt/commits/a83a4387c35384eccd3a11d74b8db4ebbb185d30
>
> Some earlier changesets need to be reverted. mutt_idna.c may have been a
> fine idea, but using idna in mail didn't ge
On Friday, November 28, 2014 8:54:47 AM CEST, Brendan Cully wrote:
I'd like to commit it. It reads well, but I want to test it. I tried
it against my dovecot server but I guess it doesn't support it:
That's right. Not yet. That might change soonish, or might not.
I'd take a test account from
On Friday, 28 November 2014 at 08:30, Arnt Gulbrandsen wrote:
> Almost three months ago, I wrote:
> >Six weeks ago, Thomas Roessler wrote:
> >>mutt_idna.c is ancient and indeed should go away in favor of real eai
> >>support. Thanks!
> >
> >Bump.
> >
> >I hate to have code hanging in a void, neithe
Almost three months ago, I wrote:
Six weeks ago, Thomas Roessler wrote:
mutt_idna.c is ancient and indeed should go away in favor of
real eai support. Thanks!
Bump.
I hate to have code hanging in a void, neither rejected nor
merged. Could you or someone else with commit privilees please
mer
The patch is now two months old. Bump.
I wrote:
I hate to have code hanging in a void, neither rejected nor
merged. Could you or someone else with commit privilees please
merge this patch:
https://bitbucket.org/arnt/mutt/commits/a83a4387c35384eccd3a11d74b8db4ebbb185d30
Six weeks ago, Thomas Roessler wrote:
mutt_idna.c is ancient and indeed should go away in favor of
real eai support. Thanks!
Bump.
I hate to have code hanging in a void, neither rejected nor merged. Could
you or someone else with commit privilees please merge this patch:
https://bitbucket.o
On Thursday, July 24, 2014 2:15:04 PM CEST, Arnt Gulbrandsen wrote:
The code I wrote is real. So how to get it in and he IDNA code out?
Would it help if I were to write another patch to get rid of IDNA?
Arnt
On Thursday, July 24, 2014 2:04:45 PM CEST, Thomas Roessler wrote:
mutt_idna.c is ancient and indeed should go away in favor of
real eai support. Thanks!
I'm glad you say so. I was half afraid to get a stupid argument.
Compatibility must be preserved and so on.
The code I wrote is real. So h
19 matches
Mail list logo
