On 12/03/2015 01:46 PM, sb wrote:

From /opt/src/dovecot-2.2.19/doc/wiki/PasswordDatabase.ExtraFields.Host.txt

...

Login referrals are an IMAP extension specified by RFC 2221 [http://www.apps.ietf.org/rfc/rfc2221.html]. They're not supported by many clients, so you probably don't want to use them normally. Right. The following clients are known to support login referrals:

• Pine
• Outlook (but not Outlook Express) We use neither. Login referrals are used only if the proxy field isn't set. We want neither LOGIN-REFERRALS nor proxy.

Dovecot's configure includes the following by default:

...

capability_banner="IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE" If the extension is simply hidden from the banner, an attacker could still use the extension.

If the connection is SSL/TLS encrypted, the attacker can't add/modify login referrals. If it's not encrypted, the attacker could just as well insert the LOGIN-REFERRALS to the CAPABILITY reply if it didn't exist there.

If one removes the string from the banner above, one merely hides the extension name in the banner, or also disables the extension's engine?

As long as Dovecot doesn't return any login-referrals (which it doesn't by default), I don't see why having LOGIN-REFERRALS in the CAPABILITY reply would matter.

On 03 Dec 2015, at 15:17, sb <serbr@runbox.com> wrote:

On 12/3/15 1:32 PM, Timo Sirainen wrote:

...

As long as Dovecot doesn't return any login-referrals (which it doesn't by default), I don't see why having LOGIN-REFERRALS in the CAPABILITY reply would matter. Because a compatible client will use the capability as advertised by the server, and then fail because the server is not honouring its promise.

One can hide the capability in the banner, but also wants to disable its engine. You say that dovecot has it disabled by default, but I have no evidence of it, yet.

I think you need to read how LOGIN-REFERRALs actually work. There is no code that can be disabled on Dovecot side.

On 03 Dec 2015, at 17:20, sb <serbr@runbox.com> wrote:

On 12/3/15 2:49 PM, Timo Sirainen wrote:

...

There is no code that can be disabled on Dovecot side. I think you need to read how LOGIN-REFERRALs actually work.

This is an excerpt from the RFC:

...

A home server referral may be returned in response to an AUTHENTICATE or LOGIN command, or it may appear in the connection startup banner. If a server returns a home server referral in a tagged NO response, that server does not contain any mailboxes that are accessible to the user. If a server returns a home server referral in a tagged OK response, it indicates that the user's personal mailboxes are elsewhere, but the server contains public mailboxes which are readable by the user. After receiving a home server referral, the client can not make any assumptions as to whether this was a permanent or temporary move of the user. The client and the server exchange relevant messages.

Client doesn't send anything to Dovecot regarding the use of LOGIN-REFERRALS. It simply does a regular authentication and if Dovecot is configured to send a login-referral then Dovecot responds so to the LOGIN or AUTHENTICATE command. The client can't request a referral in any way.

If dovecot cannot disable the relevant code then either dovecot does not implement the RFC or it does it so well that it cannot be disabled without rewriting dovecot's code. In either case, we want to disable LOGIN-REFERRAL, and have evidence that it has been disabled. Removing the keyword from the banner is not sufficient, and the documentation PasswordDatabase.ExtraFields.Host.txt is far from useful.

Dovecot never sends a login referral unless you have explicitly configured passdb to send it. There are no commands, requests or anything related to LOGIN-REFERRALS that can be sent by IMAP client to Dovecot. If you haven't configured a passdb to return a host field, there is zero code that can ever be executed that is in any way related to LOGIN-REFERRALS.