36 lines
2.9 KiB
Plaintext
36 lines
2.9 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Tue Jan 14 13:43:07 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Login referrals resurrection?
|
|
In-Reply-To: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>
|
|
References: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>
|
|
Message-ID: <1389735787.25987.70781289.30514553@webmail.messagingengine.com>
|
|
|
|
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! )
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|