70 lines
3.4 KiB
Plaintext
70 lines
3.4 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Jan 14 14:06:56 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Login referrals resurrection?
|
|
In-Reply-To: <1389735787.25987.70781289.30514553@webmail.messagingengine.com>
|
|
References: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>
|
|
<1389735787.25987.70781289.30514553@webmail.messagingengine.com>
|
|
Message-ID: <CABa8R6tRLa5K=t9dKzWJyS0r0-+SZhoFYSJJAFXpLDLsb25r9w@mail.gmail.com>
|
|
|
|
On Tue, Jan 14, 2014 at 1:43 PM, Bron Gondwana <brong@fastmail.fm> wrote:
|
|
|
|
> On Wed, Jan 15, 2014, at 08:32 AM, Timo Sirainen wrote:
|
|
> > I started wondering today if it would be a good idea to bring back the
|
|
> login referrals, only a little bit changed from their original behavior. I
|
|
> guess originally they didn't really get used because few clients supported
|
|
> them and proxying works for everyone. But nowadays many larger
|
|
> installations have IMAP proxies and backends in multiple data centers and
|
|
> even though everything works, doing unnecessary proxying between data
|
|
> centers increases latency and often also costs money. Using DNS to give the
|
|
> correct data center IP based on the source IP might work for some users,
|
|
> but that's somewhat difficult to set up and likely won't work very well for
|
|
> the increasing number of mobile users. So what if we got the most popular
|
|
> clients to implement support for login referrals and use them?
|
|
> >
|
|
> > Problem 1: LOGIN tagged OK [REFERRAL] reply conflicts between
|
|
> Lemonade-required OK [CAPABILITY] reply.
|
|
> >
|
|
> > So either one of them needs to be moved to an untagged OK reply. RFC
|
|
> 2221 only talks about tagged OK reply, while RFC 5550 makes it possible to
|
|
> use untagged OK reply. But I'm a bit worried about changing this now, there
|
|
> may well be clients that handle only the tagged OK [CAPABILITY] while there
|
|
> are almost no clients that handle [REFERRAL] anywhere. So my preferred
|
|
> server reply would be:
|
|
> >
|
|
> > * OK [REFERRAL imap://user;AUTH=*;us1.imap.example.com/] Use this
|
|
> server for decreased latency
|
|
> > a OK [CAPABILITY ...] Logged in.
|
|
> >
|
|
> > Problem 2: RFC 2221 specified OK [REFERRAL] to mean that user's
|
|
> mailboxes aren't on this server, but some shared mailboxes are.
|
|
> >
|
|
> > Instead now the OK [REFERRAL] should simply be a suggestion to the
|
|
> client to connect to the specified server to get better latency, but it
|
|
> would work just as well to just ignore it and keep using the current
|
|
> server. In fact the client likely shouldn't reconnect at all, but just
|
|
> create all future connections using the referral's server. If the referral
|
|
> server ever fails, the client should connect back to the original server.
|
|
> >
|
|
> > Does anyone else think this would be worth maybe writing a new updated
|
|
> RFC2221bis and trying to convince client developers to implement it?
|
|
>
|
|
> Any particular reason to reuse the same name with an altered meaning
|
|
> rather than coming up with a new name for this? e.g.
|
|
>
|
|
> * OK [CANONICAL imaps://user;AUTH=*;us1.imap.example.com/] home server is
|
|
> us1
|
|
>
|
|
> Bron ( I can't believe you're sending the user to a non-ssl URL in this
|
|
> day and age! )
|
|
>
|
|
|
|
I'm sure he implied STARTTLS, that is, after all, the preferred way for
|
|
IETF protocols to work. Or is that the difference between simap and imaps?
|
|
|
|
Brandon
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140114/3a6e9728/attachment.html>
|