MBOX-Line: From tss at iki.fi  Tue Jan 14 13:32:15 2014
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:51 2018
Subject: [Imap-protocol] Login referrals resurrection?
Message-ID: <FF6E4621-3C20-4C20-AE79-9E62CC9322CC@iki.fi>

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?


