email support

Ask us about your TalkTalk email account and Webmail.

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Talktalk mailbox not working in email client or webmail, other mailboxes OK

Conversation Starter
Message 23 of 23

My main TalkTalk account (broadband and telephone) has 3 email mailboxes and addresses, two Tiscali ones dating back to when Tiscali first offered ADSL broadband in my area, and one TalkTalk address I added at the beginnning of July. I had always used POP3 up until then, but changed the two Tiscali addresses to IMAP and used IMAP from the get-go with the TalkTalk address.


Evening before last (Wednesday) I started getting authentication failure for the TalkTalk mailbox in my email client. Checking with Webmail, something is very wrong at the TalkTalk end. With webmail, it appears to accept my username and password, but the mailbox page only has content down to the grey bar across the screen that has the logout link in it. Below the line, therte is no column on the left with the Check New Mail, My Mail Folders, Manage Folders etc in it, and nothing in the rest where e.g. a mailbox's contents would be displayed. There is absolutely NOTHING below the grey bar with the logout link - just white space. It has been like this, authentication failure with the email client, accepted  login but totally blank webmail since Wednesday evening.


My two mailboxes, however, work fine both with the email client and via webmail, apart from about an hour last night (Thursday) when the email client logins failed but they were normal in webmail - and after an hour the email client login started working again. Same with a mailbox in a completely different account - fine apart from an hour last night in the email client.


So something has gone wrong just with my mailbox that (a) isn't my email client as the mailbox is not workng in webmail either, even though it accepts the webmail login, and (b) isn't a general problem as it isn't affecting my and mailboxes.


Message 1 of 23

Hi all, a fix was put in for this on Friday and all those affected should have seen return to normal service now. 

Please log in to My Account if you need to view or pay your bill, manage boosts and track your usage. From My Account you can also check your connection and test your line for any issues in the Service Centre.


Message 2 of 23


I have had this problem since Tuesday 31st. I have tried talktalk helpline explaining my Iphone was also affected and they blamed my setup even though I was recieving other emails in outlook 2016 via my address. I had not been on my computer to change anything around the 31st so it had to be talktalk. I have tried many things in order to sort the problem out to no avail however it has started working again this morning. I have spent hours on this problem, why do talktalk expect us to put up with this kind of service. If anyone can tell me what they did to correct the problem I would appreciate it.




Support Team
Message 3 of 23

Hi DavidB-E,


I'm sorry for any inconvenience caused by this issue, please check the Service Status Dashboard for updates





Message 4 of 23

Interestingly, I can make a direct comparison in customer support behaviour between TalkTalk and a far more urgent problem with which I was dealing simultaneously here (hence only dipping in and out of the TT issue instead of diving into it in depth).


Once again it was an issue where a change (an upgrade) at the other end had then caused further changes to have to be made by them which messed up the interface to our end. Having patched our systems to match theirs, I found things still didn't work but the error message reported back from their systems didn't make much sense. The person I was originally speaking to was trying to tell me it was my problem and giving me information which again was obviously not right but, unlike TalkTalk, they were very quick to recognise that it needed someone higher up the tech level to look at it. So various other staff from their side chipped in until they found the one amongst them who could work out that it was indeed an additional incompatibility which could only be fixed at their end and not ours at all. At which point the interface started working perfectly again.


So that was all accomplished within much less time - despite the difficulty of communicating through TalkTalk's webmail when it kept logging out on me. They're also far more likely to make notes for themselves to quickly recognise when a similar thing happens again. We've been through such situations before with them. Things go so much more smoothly for identifying and fixing faults when that true technical peer-to-peer level is permitted between organisations.

... computer programmer since the 70s.

Message 5 of 23

Exactly. As soon as the chat agent started talking obvious nonsense and the similar telephone support script-bunny was clearly not even understanding the difference between the mail types, I knew that both of them were a complete waste of space for technical issues beyond the "have you tried turning it off and on again" level. I did demand to speak to a supervisor (which took a ridiculous amount of time to arrange!) but even then, despite claiming they were going to take it further and get back to me, they never did. Instead, we've had all these extra days of nothing being done and clueless "support" staff lying to and blaming even more hapless victims and getting them to mess with their own settings to no avail.


TalkTalk (and so many other companies) are doing this all wrong. Engineers always need to be put in contact with other engineers ASAP; and any script-driven non-techie customer-support agent in these industries is merely getting in the way of that. They* need to be trained to recognise the difference between someone who only just about knows how to turn on a light switch (for whom their script is appropriate) and someone who knows much more than they do about programming their company's systems.


* Better yet, some sort of non-human AI intelligence / knowledge base test (like a captcha for techie-spotting) could be in place to rate how much the caller already knows and then divert the call up to the appropriate level immediately.

... computer programmer since the 70s.

Conversation Starter
Message 6 of 23

It is an unfortunate situation.


Most ISP customers have next to no technical knowledge, and most of their problems are indeed down to them ignorantly misconfiguring their software, even though they will mostly jump to the conclusion that the fault is the ISP, not them. This means (and has meant, at least as far back as the 90s) that mainstream ISPs' customer support is entirely geared towards ignorant customers whose problem reports come down to 'it's broke', with the first level customer support people also almost entirely ignorant of the real technicalities, and relying solely on scripts that deal with the most common ignorant customer mistaken configurations. And, usually, they are also actively discouraged from escalating problems up to the levels of their organization with more technical understanding


This unfortunately leads to huge frustration amongst the customers who ARE technically knowledgeable, know the POP3, SMTP and IMAP RFCs, know how to generate a connection log file and what it all means, and can even connect to the server via telnet and manually send the IMAP etc commands and view the server replies and see server problems and what they are. The first (and usually second and even third) line customer support mostly don't even know what an RFC is, and not only don't know enough about the technology to understand what such a customer is saying, they also don't know enough to recognize that this is a customer who DOES understand the tech and knows what they are talking about.


Back from around 1996 to 2002 I used a computer with a different, minority, British OS, and we used to have all sorts of problems with ISPs who'd never heard of the OS, let alone our internet software. I ended up learning all about the technicalities, the RFCs, could do a manual POP3 fetch or SMTP send without using an email client so I could see problems, typing the commands and seeing the server replies myself. And I then ended up (as a purely voluntary thing) spending many evenings for several years providing a technical support to other users of the OS over email issues. Most problems then, as now, were people misconfiguring their software. But I would always check - they could send me the configuration files so I could be sure -  and sometimes the problem was the client sending malformed commands, and I would contact the software author (always individuals or very small companies for that OS) and explain what they needed to correct. And sometimes it was an ISP with a misconfigured server or corrupted datafiles. With the  ISP most of us used, the first level customer support was hopeless - would just try to use their script, then just dismiss any of us users of that OS as our fault for using some strange OS or software that wasn't in their script. Twice I spent about 3 hours each time arguing my way up through levels of escalation they really didn't want to do until I managed to get up to their head server technical engineer, who was the first person who actually undertood what I was saying about the server not giving the correct responses to client-side commands as mandated in the POP3 and SMTP RFCs.


He then thanked me, fixed the problem, and after the second time gave me his direct contact details, as he understood I was knowledgeable enough and conscientious enough that if I was calling saying there was a server problem, then there WAS a server problem, I would have checked it out before reporting it, eliminated the possibility of a client side problem, have details to prove it, and would know exactly what the problem was as far as I could disgnose it remotely (down to identifying particular server misconfigurations in many cases).


That all ended when I moved to Windows in 2002, and I haven't had any problems like this to deal with in all the years since, but I see nothing's changed much. Sadly I've forgotten most of what I knew then, partly from lack of use, partly because the disability that's been with me since 2007 and side effects of the meds I'm on have had a very strong negative effect on my memory and my ability to think clearly. But I've recovered enough recollection to tell whether a problem - THIS problem - is client side or server side.


But have ended up back dealing with a tech support level who don't actually understand enough tech to see I know what I'm talking about and therefore escalate accordingly. 7 days and the issue finally appears to be with the actual tech people. Should have been on day 1.


And there is one important thing that most of the lower level support people do not understand:


IMAP (or POP3 or SMTP) sessions are very simple. They are defined in documents (the RFCs). There is a very limited, specific collection of commands, with very specific syntax that a client can send; there are very limted, very specific replies to those commands that a server is allowed to give. And it doesn't matter what client you use. The server never knows what client you are using (there is no command in the RFCs to specify the client even if you wanted to). The server doen't know whether it is connected to Thunderbird, Windows Mail, some Android email client, some Apple client, something (like Messenger Pro) you've never heard of, or someone sitting at a terminal typing in the IMAP (or POP3 or SMTP) commands on their keyboard. The server just listens for the allowed commands, and replies as specified in the RFCs and the circumstances (like supplying a list in a very specific format of whatever the contents are in reply to a LIST command).


And that means that if a customer knows enough to look at connection logs, he/she can see if the session connected to the server, and if the session connected and he/she can see that the commmands sent by the client are correct but the server replies are wrong given the commands sent by the client, IT DOES NOT MATTER WHAT CLIENT IS BEING USED. IT DOES NOT MATTER IF IT IS 'SUPPORTED' OR NOT (which just means whether the first line support have a script for it or not). An IMAP command is an IMAP command whatever client sent it or whoever typed it. If the session connected and the commands are correct but the server reaction is wrong, there's a problem at the server. Trying to tell that user to check this or that configuration is a waste of time if the user can see that the client is actually sending the correct command - that it is proves the configuration is correct even if the customer service person has no clue about configuring that client.


First level customer support really need something added to their scripts that if a customer mentions this or that, then escalate to a fully tech savvy level immediately because this is a customer that knows what he/she is talking about, and that customer support person should absolutely NOT tell the customer that it is their client at fault. There are very few things more guaranteed to infuriate a tech savvy customer.

Message 7 of 23

Impressive evidence!

The Service Status Dashboard is now at least showing localised issues, so at least they've recognised the problem - and hopefully have enough evidence to work out what's going on!


Conversation Starter
Message 8 of 23

OK, so yesterday I posted the address transfer log from one of my email clients, showing that it is connecting to the mail server, it is sending the login command with the correct username and password, and the mail server is refusing to authenticate it. I used the Messenger Pro Transfer log because (a) it runs all the time, (b) it keeps a separate log for each account, and (c) it just records the messages sent by the client and the server making it easy to read and copy. But none of you will have heard of intellegit's Messenger Pro, so I will add today some of the log from Thunderbird.


Now, Thunderbird can't be set to always log connections, it can just have logging turned on for a session. It produces a single log, with the fetches from all my 5 email accounts (4 Talktalk - two, one and one - plus Gmail) interleaved, plus all its own processes mixed in as well, and it's all in a verbose state. But extracting just the attempted fetch lines, trimming down to the server/client communications and related Thunderbird internal actions, and adding note references (in red), here's from the Thunderbird log of another attempt yesterday afternoon (after the mailbox repair, and after the MessengerPro attempt posted above):


2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: * OK [CAPABILITY IMAP4rev1 UIDPLUS NAMESPACE QUOTA AUTH=PLAIN] Ready (Note 1)


2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: try to log in (Note 2)


2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000) (Note 3)

2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: trying auth method 0x1000 (Note 4)

2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: got new password (Note 5)

2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: IMAP: trying auth method 0x1000

2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: PLAIN auth


2018-08-08 15:56:33.848000 UTC - 33532[1583d9b0]: SendData: 1 authenticate PLAIN

(Note 6)

2018-08-08 15:56:33.910000 UTC - 33532[1583d9b0]: SendData: Logging suppressed for this command (it probably contained authentication information) (Note 7)


2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: 1 NO [AUTHENTICATIONFAILED] Authentication failed. (Note 😎


2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: authlogin failed

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: marking auth method 0x1000 failed (Note 9)

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: IMAP auth: server caps 0x43225, pref 0x1006, failed 0x1000, avail caps 0x4

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000) (Note 10)

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: trying auth method 0x4 (Note 11)

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: got new password

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: IMAP: trying auth method 0x4

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: old-style auth

2018-08-08 15:56:41.971000 UTC - 33532[1583d9b0]: SendData: Logging suppressed for this command (it probably contained authentication information) (Note 12)


2018-08-08 15:56:50.047000 UTC - 33532[1583d9b0]:  3 NO [AUTHENTICATIONFAILED] Authentication failed. (Note 13)


2018-08-08 15:56:50.047000 UTC - 33532[1583d9b0]: authlogin failed

2018-08-08 15:56:50.047000 UTC - 33532[1583d9b0]: marking auth method 0x4 failed

2018-08-08 15:56:50.047000 UTC - 33532[1583d9b0]: IMAP auth: server caps 0x43225, pref 0x1006, failed 0x1004, avail caps 0x0

2018-08-08 15:56:50.047000 UTC - 33532[1583d9b0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)

2018-08-08 15:56:50.047000 UTC - 33532[1583d9b0]: no remaining auth method (Note 14)

2018-08-08 15:56:50.047000 UTC - 33532[1583d9b0]: IMAP: ask user what to do (after login failed): new passwort, retry, cancel (Note 15)




And to explain the above for those that need it:


Note 1: This is the reply from the mailserver, showing that Thunderbird did connect to the mail server, and that the problem is NOT a problem of internet connectivity. The 33532[1583d9b0] shows that the line is referring to the login - the two logins, and the and the Gmail logins are logged as well with their lines interleaved with these, but the lines correspoding to each have different unique number sequences so one can tell which lines go with which email account server connection.

Note 2: Thunderbird recording that it is about to start the login procedure.

Note 3: Thunderbird listing to itself all of the auth methods it supports for authenticating itself to the server.

Note 4: it selects the AUTH=PLAIN method, as that was the (only) one given in the mail server's CAPABILITY declaration in it's opening reply to the connection request in the first line.

Note 5: Thunderbird fetches the password from the password store

Note 6: Thunderbird prepares to send the login, confirming PLAIN

Note 7: Thunderbird sends the login command, but doesn't log the exact command sent as it includes the username and password in the clear (unlike in MessengerPro's log that I posted yesterday, which does record it, showing the correct username and password was sent). But I can assure yout that Thunderbird has been given the correct password.

Note 8: The server responds NO, adding AUTHENTICATIONFAILED. According to the IMAP RFC 3501, the server is only allowed to give one of 3 responses: OK (accepted, you are now logged in) usually with a further more detailed CAPABILITY statement appended; BAD (the server doesn't understand/support the command from the client, or the arguments added to the command do not fit the syntax); or NO (password and/or username are incorrect, so authentication refused). So the server has accpeted the type of login, but has rejected the username and/or password even though both are correct.

Note 9: Thunderbird marks the AUTH=PLAIN method as a failure, although that is the one we are told to use.

Note 10: Thunderbird relists all the auth/login methods it knows to see if another one might be compatible with the server's opening CAPABILITY statement.

Note 11: Tunderbird thinks that mabe the 'old-style IMAP login' might work.

Note 12: Thunderbird sends a new login command in the 'old-style IMAP login' format.

Note 13: The mail server responds with NO again, accepting this format of login as valid (if it wasn't, it would reply BAD, instead of NO), but rejecting the username and/or password again, even though they are correct.

Note 14: After going through all of the auth/login types it knows again, Thunderbird concludes that none of the others match the server's opening CAPABILITY statement of what it supports, so it has run out of options for ways to log in.

Note 15: Being out of options, Thunderbird goes into the routine of opening a dialogue box to announce its failure to login to the mail server and ask what it should do.


Note that the lines for the other Talktalk addresses - two and one, all on the mail server - show exactly the same things happening the same way, same commands, same replies up to the actual sending of the login command to the server, where they all get an OK instead of a NO.


Now - this shows exactly the same thing from Thunderbird as the extract from the Messenger Pro transfer log I posted yesterday. (I had got this log then; I just posted the Messenger Pro one because it was straightforward and didn't need lots of selecting, pasting and annotating. I'm disabled, using the computer costs me a lot of mounting pain, and I just wasn't up to writing this post yesterday.) The logs in both clients prove:


1 They are connecting to the server, it welcomes them, they send it commands, it replies, therefore this is NOT some connectivity problem.

2 They are using the correct authentication method (or the server would reply BAD, not NO, and the logs actually show the method used and that it is correct anyway).

3 The server is rejecting the logins specifically on the grounds of the username and/or password being wrong, despite the fact that the usernames and password are correct and exactly the same as the ones used to login via webmail.




And it is clear from the many, many other threads and posts added to the other threads by other people that it is not just me. Since August 1st this is affecting a lot of us.


Will somebody at Talktalk please get this sorted out. If you are somebody at Talktalk but don't have enough tech knowledge to understand what these logs mean about your server problem, then kindly escalate the issue however high it needs to go to get to somebody with that level of tech knowledge.




Message 9 of 23
Yes, the TalkTalk staff are being extremely incompetent or dishonest in continuing to indulge in victim-blaming with regard to people's varied choices of mail clients for downloading emails rather than acknowledging and fixing what is very clearly TalkTalk's own POP3/IMAP mail server fault(s).
... computer programmer since the 70s.

Message 10 of 23

I have had exactly the same problem as described here. Suddenly authentication failed when trying to login to the account, although Webmail works normally. There is clearly an issue with external client authentication. I have tried contacting the TalkTalk on-line help but got absolutely nowhere. They kept insisting it was a problem with the email client rather than their server - despite the fact that the problem occurs on several devices with different email clients.


Message 11 of 23

It is still rejecting my login, using both Thunderbird (my current email mail client) and intellegit's Messenger Pro (the email client I was using until a couple of weeks ago).


As Messenger Pro keeps continuous transfer logs in a more human friendly readable style than Thunderbird, here is the Messenger Pro transfer log for my email address fetch just now to check after trying with Thunderbird and it failing again.


Aug 08 11:47:37 (2) Resolving host

Aug 08 11:47:37 (2) Connecting to

Aug 08 11:47:37 (2) Connected

Aug 08 11:47:37 (2) Connected


Aug 08 11:47:37 (2) >>>> 0001 LOGIN "" "PPPPPPPPPPP"

Aug 08 11:47:37 (2) Logging in...

Aug 08 11:47:45 (2) <<<< 0001 NO [AUTHENTICATIONFAILED] Authentication failed.

Aug 08 11:47:45 Unexpected response received from account 'TalkTalk': 0001 NO [AUTHENTICATIONFAILED] Authentication failed.


where I have copied it and pasted it verbatim into this post but then replaced the first part of my email address with XXXXX.XXXXXXXXXXXX and replaced the password with PPPPPPPPPPP. >>>> in these logs marks what the client sent to the server, while <<<< marks what the client received from the server.


Turning on logging in Thunderbird, it is more convoluted to read, but it shows the same error: NO [AUTHENTICATIONFAILED] Authentication failed




1 The client DID connect to the server.

2 While the Thunderbird transfer logs do not actually record the username and password for security reasons, the Messenger Pro logs DO show the full LOGIN command including username and password, so while I know the correct name and password are configure in  both clients, in the case of Messenger Pro I can actually see that the correct name and password were sent - there is NOT some mysterious bug meaning the wrong password was sent.

3 The problem SPECIFICALLY is that the is rejecting the authentication. It is not an external internet problem stopping a connection being made. It is not the client sending the wrong username or password. It is not a problem of sync failure after logging in. It IS a problem that the sever is rejecting the correct IMAP login command with the right username and password.


It is now SEVEN DAYS since I have been able to log into the account. Luckily it is a new email address, created on 1st July, I haven't started using yet and giving out to anybody, so won't be getting email on it that I can't fetch. But this means that I have not been able to start using it for the use for which I created it.


I have two addresses, and one  address (with one alias for that address). On Wednesday 1st Aug, when this problem started in the evening, at the same time the address login failed, the 3 addresses on the server failed too in the same way. But in their case that only lasted for less than an hour, and since then they have been working fine. The address has remianed rejecting the login by both email clients ever since.


I did try changing the email address password in My Account, in case that would kick something into working again, and confirmed the new password was in effect with a webmail login, but it had no effect on the email clients being able to login. Same error - and with the Messenger Pro transfer log showing that it was correctly sending the new password.


I do not use webmail. I do not like webmail, I will not use webmail, so the fact that I can log in using webmail is of no significance to my ability to use the address other than any diagnostic value.



Message 12 of 23

Hi DavidB-E, I've run a repair on that mail account for you. Let me know how you get on. 

Please log in to My Account if you need to view or pay your bill, manage boosts and track your usage. From My Account you can also check your connection and test your line for any issues in the Service Centre.


Conversation Starter
Message 13 of 23



In a few hours it is going to be FIVE DAYS since started refusing to authenticate my email clients when they try to do IMAP connections to my address.


Note 1 The mail serve is giving no problem with my and email account fetches. It is specifically only the mail server with a address that is not working.


Note 2 I had made no changes whatsoever in either of my completely different email clients before the problem started, or after until I tried changing the password after several days of the problem. Didn't help.


Note 3 The additional problem of the addresss webmail not rendering anything below the grey line with the logout link in it in Firefox started at the same time, but resolved after 48 hours on Friday. However, as I don't use or wish to use Webmail, that doesn;t help.


Some indication that someone recognizes that there is a problem and that it is being looked into would be nice.


Conversation Starter
Message 14 of 23

Belated update (I'm disabled and only sometimes up to looking into things and typing messages):


Friday night, the mailbox started rendering in Webmail in Firefox again, having refused to do so since Wednesday evening. I'd done nothing, changed nothing either before the Wednesday refusal to show anything but a blank page, or before its starting to work again late Friday. Talktalk end problem, but now resolved.


However, I only consider using Webmail as an emergency backup (or, when I was using POP3 for many years, to log in with webmail every now and then to delete the odd email that had failed to delete after a POP3 fetch). So what is to me by far the most important problem still persists. IMAP fetches with either of my email clients from my address mailbox on fail to authenticate. I also decided to try changing the password for that email address in My Account, but it has made no differece - the email client attempts to fetch still have the authentication fail (now with the new password, obviously). Meanwhile, fetches from my 3 mailboxes continue to authenticate and work fine. There is some problem with external client authentication on that has been going on for FOUR DAYS now - is it ever going to be fixed?


It's a shame that I can't create a new email address (this is/was a account, and the other, long held email addresses on it are ones, including the account login address) to replace this useless talktalk one I can't fetch from with my email clients.


Message 15 of 23

Cool. I'm sure @Gondola and the other email experts can help with this. I was just advising on the Chrome password question.


Conversation Starter
Message 16 of 23

I'm not doing anything wrong (and I'm not sure how one pushes a button wrong anyway). It is, however, quite possible that my Chrome install has developed some problems as I never use it, other than to load it occasionally to check for and install updates; if it has gone flaky, I wouldn't have noticed because I don't use it.


But, I know it's my fault for mentioning something off my own topic, but I would appreciate dropping it, as I don't care what does or doesn't happen in Chrome, which I don't use. I would appreciate some help in fixing the things I DO use. Namely:


1  My mailbox suddenly stopped authenticating my email client part way through Wednesday evening (and, I've just checked, the same in my previous email client that I was using up until a few weeks ago).


2 As a generally unused but desired backup, the webmail page for the same mailbox, while apparently accepting the login (same username and password as in both email clients), is completely blank below the grey horizontal stripe that contains a logout link in Firefox.


Meanwhile, my and mailboxes are fine in both email client and Firefox webmail pages, barring a brief period on Wednesday evening when the client couldn't log in go them, but with a 'server temporarily unavailable' message in the log, rather than the 'Authentication failed' message the account gets, and which resolved in less than an hour, whereas the mailbox problem has been going on for nearly two days, now.


Message 17 of 23

Ah well you're doing it wrong. It does offer all other saved usernames/passwords. 


Conversation Starter
Message 18 of 23

Which does not produce what you picture above but rather pops open a panel showing me the already saved passwords for the site i.e my two tiscali and one ukgateway mailboxes which Chrome knows after importing them from firefox and offers to autofill with; and a button to go to Manage Passwords in Settings - which is no use as there is no facility to manually add a password to the manager. So I'm having to remember (or, rather, look up in Firefox's password manager) and type in the password to the TalkTalk address mailbox each time.


But this is very much a BTW. I do not usually use Chrome, and I do not usually use webmail. What I want is for the mail box to accept the email client login, the way it did up to Wednesday evening, and the way the and ones still do. And as a backup for the address webmail page to show up in Firefox the way it did until Wednesday night, and the way the and swebmail pages still do.


Message 19 of 23

@DavidB-E wrote:

Oh ... one thing that would annoy me if I did use Chrome and TalkTalk webmail regularly - Chrome is not offering to save the email login and password for the webmail, although Firefox does. That is a page design thing. (Chrome does have my two and one logins saved, but only because it imported them from Firefox).

Click on the key icon in the URL bar.


Screen Shot 2018-08-03 at 16.04.01.png


Conversation Starter
Message 20 of 23

Oh ... one thing that would annoy me if I did use Chrome and TalkTalk webmail regularly - Chrome is not offering to save the email login and password for the webmail, although Firefox does. That is a page design thing. (Chrome does have my two and one logins saved, but only because it imported them from Firefox).