661510 - Yahoo IMAP server intermittently doesn't allow any login types

Status: RESOLVED INVALID

(MailNews Core :: Networking: IMAP, defect)

Description

[Ben Bucksch (:BenB)]

Copied from bug 614826 Comment 9, posted by al_9x:

There is currently an intermittent problem logging into imap.mail.yahoo.com:
server does not support the selected authentication method

https://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/d2d94d68dfc09970

Here are a couple of snippets from the imap log, when it works and not:

784[476e600]: try to log in
784[476e600]: IMAP auth: server caps 0x7227, pref 0x1006, failed 0x0, avail caps 0x1006
784[476e600]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN =  0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4)
784[476e600]: trying auth method 0x1000
784[476e600]: got new password
784[476e600]: IMAP: trying auth method 0x1000
784[476e600]: PLAIN auth

3396[476d0c0]: try to log in
3396[476d0c0]: IMAP auth: server caps 0x6221, pref 0x1006, failed 0x0, avail caps 0x0
3396[476d0c0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN =  0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4)
3396[476d0c0]: no remaining auth method
3396[476d0c0]: login failed entirely

Can tb imap devs comment on this?  It appears that the server is intermittently returning caps that do not support any login, is that right?  Is this entirely the server's fault?  Is this their way of managing server load?  Can anything be done about this on the client?  Is TB perhaps logging in too frequently?  I notice that selecting a folder after a few minutes of inactivity, performs a login.  Is that normal or should a session/connection be kept alive?

Comment 1

[Ben Bucksch (:BenB)]

al_9x, thanks for the log, that's very helpful. Yes, indeed, the server seems to return no login schemes at all in the CAPs.
To proof, an IMAP log (in addition to the above, interleaved) might be helpful, see <https://wiki.mozilla.org/MailNews:Logging>.

What's more important, though: Could you discern any reason? Any pattern on when it works and when it fails?

Yes, it looks like this is entirely the server's fault, not Thunderbird's. Please note that Yahoo IMAP is still in beta, on their side. Normal users are supposed to use POP, and even that is new.

Comment 2

[al_9x]

Yahoo imap has been working for a long time and seems to be officially supported:
http://mobile.yahoo.com/mail#imap

It's targeted for mobile, but there is no such thing as mobile imap, imap is imap.

I have not discerned any pattern.  It should be possible for you to repro, you just need a yahoo mail account and eventually you should see this error.

Comment 3

[Ben Bucksch (:BenB)]

> seems to be officially supported:

Only for mobile. The difference is the server load. They simply don't have enough servers to cover all desktop users. That may also explain the intermittent problems.
I'm not making this up, see bug 493064 comment 35.

FWIW, I saw this myself today, on a machine not owned by me, I couldn't debug there. After waiting for 30 mins, it worked.

Comment 4

[al_9x]

(In reply to comment #3)
> FWIW, I saw this myself today, on a machine not owned by me, I couldn't
> debug there. After waiting for 30 mins, it worked.

The problem has lately become more consistent, it's always failing for the last ~4-5 hours.

The same account, while failing consistently in TB, is working consistently through WLM.  I suppose WLM could be attempting a login despite the CAPS, which succeeds.  Can TB have an option to do the same?

Comment 5

[Ben Bucksch (:BenB)]

> I suppose WLM could be attempting a login despite the CAPS

We'd have more clarity, if we had logs, for both apps.

If we don't have any login mech, that should happen only if the server explicitly says LOGINDISABLED in the caps. I don't think we should ignore that.

Comment 6

[al_9x]

(In reply to comment #5)
> > I suppose WLM could be attempting a login despite the CAPS
> 
> We'd have more clarity, if we had logs, for both apps.
> 
> If we don't have any login mech, that should happen only if the server
> explicitly says LOGINDISABLED in the caps. I don't think we should ignore
> that.

If the server really wants to deny login it will fail on the LOGIN command, the only reason for LOGINDISABLED is to prevent sending of plain text credentials in pre TLS negotiated, clear text IMAP sessions.  If the connection is already over SSL, then ignoring LOGINDISABLED as WLM is doing seems to only have an upside.  There can be no harm in trying to LOGIN over SSL, the worst thing that happens is if the server is serious, LOGIN will fail, but in this case LOGIN would succeed and this bug would not exist.
________________________________________________________________________________
[20:16:17.60] 0c64                 Mail:                    IMAP [tx] aey8 CAPABILITY
[20:16:17.62] 0c64                 Mail:                    IMAP [rx] * CAPABILITY IMAP4rev1 ID NAMESPACE X-ID-ACLID UIDPLUS LITERAL+ CHILDREN XAPPLEPUSHSERVICE XYMHIGHESTMODSEQ LOGINDISABLED AUTH=XYMCOOKIE AUTH=XYMECOOKIE AUTH=XYMCOOKIEB64 AUTH=XYMPKI
[20:16:17.62] 0c64                 Mail:                    IMAP [rx] aey8 OK completed
[20:16:17.62] 0c64                 Mail:                    IMAP [tx] LOGIN command sent with tag q68w
[20:16:17.85] 0c64                 Mail:                    IMAP [rx] q68w OK AUTHENTICATE completed
________________________________________________________________________________

Comment 7

[Ben Bucksch (:BenB)]

> * CAPABILITY IMAP4rev1 ID NAMESPACE X-ID-ACLID UIDPLUS LITERAL+ CHILDREN XAPPLEPUSHSERVICE XYMHIGHESTMODSEQ LOGINDISABLED AUTH=XYMCOOKIE AUTH=XYMECOOKIE AUTH=XYMCOOKIEB64 AUTH=XYMPKI

So, TB reacts correctly.

I don't think we should ignore the explicit LOGINDISABLED. Esp. given that Yahoo IMAP is explicitly not supported for desktop clients *yet*, but they are working on it. Building a server farm costs time and money.

I think this is INVALID (not a bug) / WONTFIX, but I am leaving this open, for the record, until Yahoo resolves it on the server side.

Comment 8

[Ben Bucksch (:BenB)]

Dear hcwang, PM (Product Manager?) for Yahoo Mail Platform,

could you please investigate this from your (server) side? The server is doing something nonsensical here, it's saying that no login mechanisms are possible. Could you check why that happens?

Unlike al_9x, I do *not* think that the server should refuse login after giving the password, because that will cause Thunderbird to think that the password was wrong. This will cause *massive* confusion with users. If you are intentionally refusing connections, the current solution of providing no login mechcanisms is better. However, there could be even better options, for example returning an error message in response to CAPABILITY command (not to LOGIN command, see above), or simply refusing the TCP connection altogether.

Without actually knowing for sure why this happens, we can't propose or find a proper solution though. Thus, we need your input and investigation.

We do understand that IMAP for desktop is not officially supported. However, a number of users are using that.

Comment 9

[al_9x]

> Esp. given that Yahoo IMAP is explicitly not supported for desktop clients *yet*

You keep referring to mobile IMAP and IMAP for desktop.  There is no such distinction, there is just IMAP, for anything that speaks it.  Yahoo is publicly advertising an IMAP server http://mobile.yahoo.com/mail#imap that's open to any IMAP client.  So this should have nothing to do with whether or not it makes sense to ignore LOGINDISABLED on an SSL connection.  I think that at least optionally it does.  Right now, it's working, but if this problem persists, I'll have to use WLM, I'd rather have a pref to ignore LOGINDISABLED for SSL.

Comment 10

[Wayne Mery (:wsmwk)]

Respecting LOGINDISABLED was done in bug 60377. It has no regressions marked against it, nor other problem mentioned in the bug.  https://mzl.la/2bODAOx bug query doesn't list any useful yahoo issues that I can see, al_9x hasn't commented in 5 years, and I'm not aware of any significant reports on SUMO. So taking into account comment 5 I think it's time to do as benb suggests in comment 7 => invalid.

cc: Mattau (support)