Open Bug 647761 Opened 14 years ago Updated 3 years ago

[autoconfig] when servers cannot be verified, cannot create any accounts with Manual Config, "Advanced" and "Create" options remain disabled

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Platform:
x86
Windows 7
Type:
defect

Tracking

(Not tracked)

People

(Reporter: adrien, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: See comment 82 for workaround)

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C) Build Identifier: 3.3a3 like the title says, account creation fails. All details are correct, server logs show connections from TB, but no protocol which could enable TB to actually validate anything other than the servername (no auth protocol). Therefore validation is failing. Even though I selected Manual config, it still disables the Create Account button, I presume I have to pass the Re-test before it will allow me to create an account? I tried servername as my local IP, and a fully qualified domain name of another server (also known correct). Failed on all accounts. Reproducible: Always Steps to Reproduce: 1. try to create an account 2. Click manual configuration to stop it from testing 3. Actual Results: always fails tests, and keeps the button that creates the account disabled. Expected Results: allow creation of the account, no matter what garbage I put in there. The philosophy of banning account creation until some test is passed is fundamentally flawed. There are numerous reasons why validation of details may fail, such as: * server currently off line * validation heuristics incorrect * something else no-one thought of to deny account creation because of this is at best annoying, and a waste of time, since one is forced to go fix other problems (maybe?) before being able to proceed with account creation even with details that are known to be correct, or even if they weren't could be modified later once the account was created.
Severity: normal → blocker
Version: unspecified → Trunk
Adrien, while I realize that this issue is personally bugging you a lot, the "blocker" severity is only intended for cases where, let's say, the program does no longer compile. The next level "critical" is mainly for crashes and hang situations, so I'll give you a "major" severity on this bug.
Severity: blocker → major
Summary: [Account creation] cannot create any accounts → [autoconfig] cannot create any accounts with Manual Config, "Advanced" and "Create" options remain disabled
I'm unable to set up an IP-numerical server with Manual Config either, which worked in the old Account Wizard implementation before bug 549045 by clicking on the "Advanced Configuration" instead, then filling in the right parameters using the conventional Account Settings dialogs. So that's a regression and should be made possible again for those cases where you need it. The main issue is that the "Advanced" button is grayed out as well thus there is no chance to finalize the account setup in the Settings dialog. It may be on purpose that "Create Account" is only active once re-testing was performed successfully, thus adding the people who should know. But even if the re-test fails, the "Advanced" settings should be made available as a fallback.
Status: UNCONFIRMED → NEW
Depends on: 549045
Ever confirmed: true
Keywords: regression
I can't create any account. numerical or otherwise. My main concern is that this is the result of major re-work of the account creation UI, and when I see valid account creation blocked for any reason, I have to conclude that development is going in the wrong direction. I think it will bring problems to others if account creation is blocked for a user based on a policy made by a developer. Unless the developer is omnipotent and can foresee all things, then failure to auto-detect settings should not block creation. Blocking account creation renders the product completely unusable. It's possible there may be scenarios where account creation could succeed (I haven't let the auto discovery process complete / timeout / fail yet). I've repro'd this on 2 systems now though. I haven't managed to create an account yet, and I'm hardly a novice user.
(In reply to comment #1) > Adrien, while I realize that this issue is personally bugging you a lot, the > "blocker" severity is only intended for cases where, let's say, the program > does no longer compile. The next level "critical" is mainly for crashes and > hang situations, so I'll give you a "major" severity on this bug. OK, thanks will keep in mind for next time.
> I can't create any account. numerical or otherwise. You'll have to be more precise than that, because it's obviously possible to create accounts. > (I haven't let the auto discovery process complete / timeout / fail yet) Well...
Do users really have to wait for the discovery to time out? The manual config button seems to stop it. I did another test, where I waited (and waited). Finally it came up with some settings I didn't want, but importantly enabled the Create Account button. It also then seemed to behave properly. So the bug is: if you hit the manual config button during discovery, the system gets hosed: a) never enables the Create account button b) never does anything useful if you hit Re-Test (connects but never tries to auth) So, steps to reproduce: 1. New account 2. Enter name, email and password 3. Click continue 4. Before discovery completes, hit "Manual config".
(In reply to comment #2) > I'm unable to set up an IP-numerical server with Manual Config either, which > worked in the old Account Wizard implementation before bug 549045 by clicking > on the "Advanced Configuration" instead, then filling in the right parameters > using the conventional Account Settings dialogs. For the sake of completeness, I've indeed waited for the discovery to fail on my provided @127.0.0.1 address, then tried to use that IP address in the manual config dialog. At no time (including re-testing) I saw "Advanced Config" or "Create Account" enabled, in contrast to the old wizard. But then, I'm not running an IMAP server on localhost, so that wasn't quite a perfect test.
I've said this before in another bug, but I'll say it again. I think it would be wise to offer an option to avoid discovery and go straight to manual config. E.g. a manual config button on the first page of the wizard. It's conceivable that the discovery process could cause unforeseen problems in some environments. Apart from the time it takes and this problem it does a bunch of things: * DNS lookups * connections to servers it generates the name for itself based on common extensions of the email domain (e.g. imap.*, smtp.* etc). In some environments this could set off all manner of firewall alarms etc, and create issues for people to deal with (Bob, why were you trying to connect to x.y.z) Creating accounts is not (thankfully) something done every day (unless you're like me and develop mail servers and need to set up test accounts all the time). The delay would be nice to avoid for me, but you could argue that an adequate fix for general public user is to just disable the manual config button until discovery is completed.
I just tried it, with my own local server (Cyrus and Postfix) on my LAN, and it works fine. Reproduction: 1. Enter "foo@foobar.com" as email address, and random real name, and your real, working password for the IMAP server 2. Click Continue 3. Click Stop (or wait for the detection to fail) 4. You end up in the Manual Config mode with fields for the server hostname 5. Enter the IP address of the server in both fields 6. Enter your real, working IMAP/SMTP username in the username field. 7. Click [Re-Test] ([Create] and [Advanced Config] are disabled, you need to test first) 8. It connects to the IMAP and SMTP servers, correctly detects their settings (ports, SSL, authentication methods), and displays them. 9. Click [Create] 10. Click on the new account 11. See your mail WORKSFORME
> The manual config button seems to stop [autodetection] Yes, it does. Clicking that is fine, you did that right. Sorry, I misunderstood you. > where I waited (and waited) (FYI: You will not wait more than ~15 seconds, unless your server or network setup is bad, e.g. servers deliberately do not respond at all or DNS server is extremely slow. I explicitly tried to make it very fast and fail quickly.) > b) never does anything useful if you hit Re-Test > (connects but never tries to auth) That works as expected for me. It's not supposed to auth, but only test server capabilities. If the server is implemented properly, that works fine. I guess that your server is just broken.
Please read and follow <https://developer.mozilla.org/en/Thunderbird/Autoconfiguration/FileFormat/HowTo#How_to_probe_mail_servers> and post the output of your manual probing with netcat / telnet. One way to counter these problems is to just set up autoconfig for your domain. See <https://developer.mozilla.org/en/Thunderbird/Autoconfiguration#Small_company>
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Hi If I hit the stop button, it goes back to first page, and I have to hit Continue, which then starts discovery again. The only thing for me that lets the wizard move onwards is if I hit the "Manual config" button. Then it's in the problem condition. Do you have a later build than me? Mine only says 3.3a3, doesn't give a build no or date or anything.
> One way to counter these problems Correction: If your server doesn't properly respond to CAPABILITIES check, that won't help either. That CAP has to work.
> If I hit the stop button, it goes back to first page > The only thing for me that lets the wizard move onwards is if > I hit the "Manual config" button. You're right, sorry.
(In reply to comment #13) > Correction: If your server doesn't properly respond to CAPABILITIES check, that > won't help either. That CAP has to work. Ok, so the conclusion of this is that you need a working server on both POP/IMAP and SMTP side to set up account. Meaning, if one of the servers is currently unavailable for whatever reason, you won't be able to set up a respective account. That would explain why my testing failed.
> you need a working server on both POP/IMAP and SMTP side to set up account. > Meaning, if one of the servers is currently unavailable for whatever reason, > you won't be able to set up a respective account. eh... Yes :-)
(Note that you should be able to select an existing SMTP server from the drop-down, too.)
I see it do the CAPABILITY, and it gets the response fine. So server not broken (the account is actually usable and used by Miramar). So the probing code must behave differently to the code that actually uses the account. S:=> * OK WinGate IMAP4rev1 service ready C:<= 1 CAPABILITY S:=> * CAPABILITY IMAP4 IMAP4rev1 UNSELECT LITERAL+ ID UIDPLUS ENABLE MOVE CONDSTORE IDLE AUTH=NTLM LOGIN S:=> 1 OK CAPABILITY command completed C:<= 2 LOGOUT S:=> * BYE WinGate IMAP4rev1 server closing connection S:=> 2 OK LOGOUT command completed I tried with different IPs, and hostnames. Always Advanced config and Create Account buttons remain disabled
(In reply to comment #16) > > you need a working server on both POP/IMAP and SMTP side to set up account. > > Meaning, if one of the servers is currently unavailable for whatever reason, > > you won't be able to set up a respective account. > eh... Yes :-) so what happens if hypothetically I'm at a customer site trying to set up their email client, but the server (100 miles away, no remote access) is unavailable... I have to get in my car, go fix the server? Drive back and set up the account? How about we just let the account setup proceed?
(In reply to comment #18) > CONDSTORE IDLE AUTH=NTLM LOGIN Shouldn't the last token be AUTH=LOGIN to be correct? Also, if the verification code checks NTLM and it fails, the entire verification fails? This may also be subject to bug 635628 if NTLM is treated similar to GSSAPI.
> Shouldn't the last token be AUTH=LOGIN to be correct? Yes, WinGate is pathologically broken, IIRC. Bad server implementation. Try Cyrus or Dovecot or Currier and Postfix, on Linux, for a proper server, if you are the admin. > I see it do the CAPABILITY, and it gets the response fine. > So server not broken But you said one of the servers was not available. That would be the reason why it failed for you. It should fail, that's what it's supposed to do. If only the IMAP server is available, see comment 17. Sorry, but the point of the wizard is to ensure that the user ends up with a working account. Yes, better make sure your server is actually working. > if hypothetically I'm at a customer site trying to set up their > email client, but the server (100 miles away, no remote access) is > unavailable... > I have to get in my car, go fix the server? Drive back and set > up the account? In that hypothetical, rare case, you would set up the account with another, working server, then, after creation, go into Account Settings and change the hostname and settings. You can also always hack about:config / prefs.js manually, FWIW.
Keywords: regression
LOGIN is not an SASL mechanism, it's inbuilt to IMAP, so isn't advertised as AUTH= NTLM isn't even tried - as Ben said, it only does the CAPABILITY command, it doesn't try to actually auth. NTLM works fine to that server with the creds I supplied.
(In reply to comment #21) > > Shouldn't the last token be AUTH=LOGIN to be correct? > Yes, WinGate is pathologically broken, IIRC. Bad server implementation. Oh really? you should look who you're talking to.
p.s. I'd be happy to discuss any concrete issues with WinGate IMAP
> > Shouldn't the last token be AUTH=LOGIN to be correct? > Yes Note that this shouldn't be fatal, because there's no LOGINDISABLED, so we have the old IMAP login available. That means unencrypted password is available, no need for NTLM. > you should look who you're talking to. Why? Are you the author of WinGate? > LOGIN is not an SASL mechanism, it's inbuilt to IMAP, so isn't > advertised as AUTH= No. There is a SASL AUTH LOGIN mechanism. That's NOT the same as the LOGIN command of IMAP (RFC 3501 Sec 6.2.3). For SASL LOGIN, see http://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/draft-murchison-sasl-login-xx.txt http://mxr.mozilla.org/comm-central/source/mailnews/test/fakeserver/auth.js#88 http://www.postfix.org/SASL_README.html An IMAP capability "LOGIN" does not exist, it's invalid. The IMAP command LOGIN is always available, unless you have capability LOGINDISABLED (which the server must implement, because the IMAP LOGIN command is deprecated, but the admin can chose not to set it and allow old-style LOGIN command).
(In reply to comment #21) > > I see it do the CAPABILITY, and it gets the response fine. > > So server not broken > But you said one of the servers was not available. I don't recall saying that. In my test cases, all servers are available. How else could I post a protocol transcript. > it failed for you. It should fail, that's what it's supposed to do. > If only the IMAP server is available, see comment 17. yep. I'm not complaining about the SMTP, it is using correct info. Although it shouldn't prevent account creation there either. It's perfectly valid to have an email client that can read only. > Sorry, but the point of the wizard is to ensure that the user ends up with a > working account. > Yes, better make sure your server is actually working. That's a _really_bad_idea_. I'd recommend you check with Mozilla superiors before implementing policy like this. I'm just trying to help. > > if hypothetically I'm at a customer site trying to set up their > > email client, but the server (100 miles away, no remote access) is > > unavailable... > > I have to get in my car, go fix the server? Drive back and set > > up the account? > In that hypothetical, rare case, you would set up the account with another, > working server, then, after creation, go into Account Settings and change the > hostname and settings. Still need to go back there to change it. You're forcing people to do things in your sequence. This is software. Up until now, you've not mandated people march to your tune. See how your customers like it. My guess is they wont. > You can also always hack about:config / prefs.js manually, FWIW. OK, thanks I'll look more into this.
(In reply to comment #25) > > > Shouldn't the last token be AUTH=LOGIN to be correct? > > Yes > Note that this shouldn't be fatal, because there's no LOGINDISABLED, so we have > the old IMAP login available. That means unencrypted password is available, no > need for NTLM. > > you should look who you're talking to. > Why? Are you the author of WinGate? for my sins. > > LOGIN is not an SASL mechanism, it's inbuilt to IMAP, so isn't > > advertised as AUTH= > No. There is a SASL AUTH LOGIN mechanism. That's NOT the same as the LOGIN > command of IMAP (RFC 3501 Sec 6.2.3). ok, you're correct. The LOGIN in IMAP is not the SASL LOGIN. It's the inbuild plaintext login. It's not advertised as AUTH=LOGIN, but there are requirements around availability of plaintext authentication methods based on whether a TLS connection has been set up, and you may see LOGINDISABLED if the server is so configured. > For SASL LOGIN, see > http://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/draft-murchison-sasl-login-xx.txt > http://mxr.mozilla.org/comm-central/source/mailnews/test/fakeserver/auth.js#88 > http://www.postfix.org/SASL_README.html > An IMAP capability "LOGIN" does not exist, it's invalid. The IMAP command LOGIN > is always available, unless you have capability LOGINDISABLED (which the server > must implement, because the IMAP LOGIN command is deprecated, but the admin can > chose not to set it and allow old-style LOGIN command). OK, I wonder where I got the idea to advertise LOGIN from... I'll have to do some more digging. It could have been an extension RFC. I can't find it in 3501 any more.
> Are you the author of WinGate? Checked, and yes. Sorry, it wasn't my intention to insult you personally. I do not remember the concrete problems (thus IIRC). Thanks for the offer for bug reports. If I encounter a concrete problem, I'll mail you. For now: - remove "LOGIN" capability - implement LOGINDISABLED, if you didn't already - implement AUTH PLAIN and AUTH CRAM-MD5 You'll find example implementations in the above fakeserver link - it took me just a few days to implement them, IIRC. - By default, set LOGINDISABLED AUTH=PLAIN AUTH=CRAM-MD5 Esp. CRAM-MD5 is important to protect the user's password when the user has no SSL.
> - By default, set LOGINDISABLED AUTH=PLAIN AUTH=CRAM-MD5 Correction: - By default, set AUTH=PLAIN AUTH=CRAM-MD5
hey no problem :) I didn't take it personally. What are the chances hey? You're right about advertising LOGIN. It should have been advertised as AUTH=PLAIN, which is a requirement in 3501 (although can be overridden by LOGINDISABLED). We support LOGINDISABLED, but it wasn't turned on on our server. if(m_bCanUseLogin) strResponse += " LOGIN"; else strResponse += " LOGINDISABLED"; There's the puppy. We support CRAM-MD5 where the user database we are using offers plaintext passwords, (which Windows normally does not). So normally NTLM is the only "secure" option for users. I don't know if there was a DIGEST or Kerberos option for IMAP, but all the MD5 and other hash-based ones are no good without PT password. I still reckon it is asking for trouble to deny the user ability to create the account though. I also timed my setup (i7 nehalem, GB-connected servers) 18s. 18s isn't long, but Joe Average doesn't know how long he's likely to have to wait.
p.s. in 6 years never had a problem before advertising LOGIN, which is why it was still there. thanks for pointing that out.
Thanks for not taking offense :) I'll mail you with the server issues right now.
thanks. If you need a test account here (so you can hit our latest server code - it's quite different now), let me know.
> You're right about advertising LOGIN. It should have been advertised as > AUTH=PLAIN, which is a requirement in 3501 Please note that AUTH=PLAIN is SASL AUTH PLAIN defined in RFC 4616 and again not the same as IMAP LOGIN command. Please do not send capability AUTH=PLAIN unless RFC 4616 is working, otherwise it would be invalid and break us.
OK. I did a bunch more testing and can report. 1. server advertising LOGIN has no bearing on result. Client behaviour is the same. I fixed our server anyway, and it now advertises AUTH=PLAIN (SASL PLAIN = NUL user NUL pass) or LOGINDISABLED if configured to disallow PLAIN in our UI. 2. Problem of disabled Create account button only occurs if Manual config button clicked while TB is discovering settings. So this needs to be fixed, either by disabling the manual config button during discovery, or fixing it so it works (my preference). 3. Final stage of verifying password is problematic. Unless you click "advanced config", it doesn't give you any opportunity to enter a username, and instead derives this from the email address. This will fail more often than not on an AD for example, where usernames are fully qualified with the AD domain name. If the user part of the email address is not the account login, then this check fails, hitting Create Account just recycles this. This is a problematic user experience. I don't think the timid user will want to hit "Advanced Config". That button bypasses all checking and creates the account (does what one would expect the Create Account button to do). In fact, one would expect re-test to do the testing, including verifying password. Failure to verify password should prompt for username and password. Create account should only create the account. I think Mozilla will have support issues with this wizard the way it is. If people are allowed to edit accounts with bad data, they should be able to create them also. the human should always have the last say - ask any airline pilot.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
> 2. Problem of disabled Create account button only occurs if Manual config > button clicked while TB is discovering settings. As said, it's intentionally disabled when the server hostname hasn't been verified. (It may be that you can modify the hostname and Create stays enabled, but that's a bug, not a feature.) Do the steps in comment 9 (Correction: in Step 3 clicking [Manual Config] instead of [Stop]) work, assuming the server works? In that hypothetical, rare case, you could set up the account with another, working server, then, after creation, go into Account Settings and change the hostname and settings. > Unless you click "advanced config", it doesn't give you any opportunity to > enter a username I have a Username field underneath the hostname fields. > 3. Final stage of verifying password is problematic. This happens after clicking [Create]. You can bypass that password check (not the server host check) using [Advanced Config].
For SMTP, see comment 17.
(In reply to comment #36) > > 2. Problem of disabled Create account button only occurs if Manual config > > button clicked while TB is discovering settings. > As said, it's intentionally disabled when the server hostname hasn't been > verified. (It may be that you can modify the hostname and Create stays enabled, > but that's a bug, not a feature.) can edit everything on that page, just that Create Account and Advanced config buttons remain disabled. Have to cancel and start over, and not interrupt. > Do the steps in comment 9 (Correction: in Step 3 clicking [Manual Config] > instead of [Stop]) work, assuming the server works? nope, as soon as I hit that manual config button if it was still discovering, it's hosed. If I let it finish, all is fine. > In that hypothetical, rare case, you could set up the account with another, > working server, then, after creation, go into Account Settings and change the > hostname and settings. > > Unless you click "advanced config", it doesn't give you any opportunity to > > enter a username > I have a Username field underneath the hostname fields. just saw that - I must be going blind or something. Ok, so setting username isn't a problem. > > 3. Final stage of verifying password is problematic. > This happens after clicking [Create]. You can bypass that password check (not > the server host check) using [Advanced Config]. I think this will be counter-intuitive for many people. What happens when you hit the button is not what is advertised on the button. It says it will create the mailbox, but instead it tries to verify your password. If that succeeds, all good, and it creates the account, but if it fails, it's not a great experience. You already have a test button... shouldn't we just use that?
> What happens when you hit the [Create] button is not what is advertised on the button. It says it will create the mailbox, but instead it tries to verify your password. Yeah, that doesn't really make sense. Would you file a new bug for this (and add me to the Cc list), and we can hash out the wording there? Thanks, Blake.
> > Do the steps in comment 9 (Correction: in Step 3 clicking [Manual Config] > > instead of [Stop]) work, assuming the server works? > nope Well, they do work for me... Clicking [Re-Test] (and that test succeeding, i.e. the server working) is necessary, though.
Ben, I emailed you a video showing clearly the problem. Regards Adrien
Thanks, Adrien, that was useful. You are not entering any SMTP server, your SMTP server hostname is ".qbik.com", that's why it says the server is not correct.
so you mean you need to have working IMAP _and_ SMTP to set up an account? What about the fact the Advanced config button was disabled?
> so you mean you need to have working IMAP _and_ SMTP to set up an account? Yes (See comment 9 step 5) > What about the fact the Advanced config button was disabled? Comment 36. We intentionally ensure that the servers are working and the settings are correct before letting you proceed. We're tuning for average users who just want a working account. If we allow them to set up a broken account, chances are that a good portion of users does so, even if they didn't really mean to, and then have a hard time to correct it. I provided workarounds for cases where you absolutely want to set up an account for a server that doesn't work. Sorry, but I don't see a bug here.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
Summary: [autoconfig] cannot create any accounts with Manual Config, "Advanced" and "Create" options remain disabled → [autoconfig] when server is broken, cannot create any accounts with Manual Config, "Advanced" and "Create" options remain disabled
(In reply to comment #44) > > so you mean you need to have working IMAP _and_ SMTP to set up an account? > Yes OK, I guess we will continue to disagree on that, and we'll see what the users think when it's put to them. > (See comment 9 step 5) > > What about the fact the Advanced config button was disabled? > Comment 36. > We intentionally ensure that the servers are working and the settings are > correct before letting you proceed. We're tuning for average users who just > want a working account. If we allow them to set up a broken account, chances > are that a good portion of users does so, even if they didn't really mean to, > and then have a hard time to correct it. > I provided workarounds for cases where you absolutely want to set up an account > for a server that doesn't work. OK. I can't get this workaround to work if I interrupt the discovery process. By workaround do you mean the advanced config button or something else? If you mean that button, it needs to be enabled. Otherwise you need to post a warning during discovery "don't press the manual config button"
also, if you're going to fail a process on lack of a working SMTP server, you need to make the error text refer to that. I think expectations could be managed a lot better during the process.
(In reply to comment #45) > > We intentionally ensure that the servers are working and the settings are > > correct before letting you proceed. We're tuning for average users who just > > want a working account. If we allow them to set up a broken account, chances > > are that a good portion of users does so, even if they didn't really mean to, > > and then have a hard time to correct it. Just for the record: 1. I'm fine with there being a mechanism to verify / validate settings. This should be a tool to assist however, not a shackle we must all wear. Computers are still thought of as tools to assist aren't they? 2. I'm fine with a mechanism to automatically try and find account details based on whatever (e.g. domain part of email address). I think there are numerous improvements that could be made to how this is communicated to the user while it's happening. 3. If the workaround is "hack about:config / prefs.js " that's not good enough. Not when there is an Advanced settings button and a create account button sitting there disabled/lying to me. Buttons should a) work b) do what they say regards Adrien
This is mostly a UX question, thus I think that Bryan should make this decision given that bug 549045 doesn't explicitly state that the user shall be actively prevented from setting up a broken account (the end of bug 549045 comment #81 actually implies that this "power" should still be given to the user). -> REOPENING (as a minimum, this should be a valid RFE) (In reply to comment #47) > 1. I'm fine with there being a mechanism to verify / validate settings. This > should be a tool to assist however, not a shackle we must all wear. Computers > are still thought of as tools to assist aren't they? I agree with that. Yes, the first step is to use the settings that are known for a provider, or can be guessed from the domain, and verify that they work before accepting them. The second step is to let the user enter manual mode and provide the entries, then re-test if it works. But, there may be still cases where even that doesn't proceed, being that some detail is missing or the server is indeed just down. So, after re-testing fails, there sure should be some notification about "Hey, you may be creating a broken account now!" but the user should be permitted to either create the account anyway as specified on his or her own risk, be it by using the "Create" button of through the "Advanced Settings". One can always delete a non-functional account afterwards. (In reply to comment #44) > I provided workarounds for cases where you absolutely want to set up an account > for a server that doesn't work. It's a workaround, but a rather bumpy one and requires that you set up another account correctly first which must have working servers. Asking a user to manually hack the rather complex server/account/identity settings in prefs.js was hopefully a joke, as it is highly unlikely that even an experienced user will be successful doing that on a first attempt. If everything was done that Thunderbird can do to ensure that the account was set up correctly, it's ok to say "Sorry, but you are on your own - do you still want me to create that account?" and then just let the user make the final decision so that a chance is given to figure it out in the Account Settings...
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
> 3. If the workaround is "hack about:config / prefs.js " that's not good enough. The workaround is to create an account with a working server, then change it to the broken server in "Account Settings".
(In reply to comment #49) > > 3. If the workaround is "hack about:config / prefs.js " that's not good enough. > The workaround is to create an account with a working server, then change it to > the broken server in "Account Settings". OK. Firstly. The server was not broken, it was available. The validation was broken. Secondly, most people don't have another account lying around they can use. So your workaround is not good enough. What would be good enough is to simply fix the bug that is preventing the Advanced button from being enabled.
> Firstly. The server was not broken, it was available. The validation was > broken. You haven't shown that. In all cases I saw, you either didn't enter IMAP *and* SMTP hostname, or the server was down. > most people don't have another account lying around they can use. *Most people* do not want to set up accounts for servers which are not working. This is why it works it does. Admins typically do have more than one account. > What would be good enough is to simply fix the bug that is preventing the > Advanced button from being enabled. Again: It's not a bug. It's intentional. This is a change request, not a bug report. (Which is fine, but please don't call it a bug.)
(In reply to comment #51) > > Firstly. The server was not broken, it was available. The validation was > > broken. > You haven't shown that. In all cases I saw, you either didn't enter IMAP *and* > SMTP hostname, or the server was down. OK, so you're saying when I see Outgoing: [SMTP] .qbik.com Then I'm not supposed to read that as smtp.qbik.com, and in fact I need to enter smtp.qbik.com? That's confusing. smtp.qbik.com has been available through all these tests. in fact mail.qbik.com has also been available through all these tests. So lets consider the case where someone is trying to manually set it up. If there's a working IMAP server specified, but no working SMTP server, there's no indication from the dialog which is failing validation. My assumption was that it was the IMAP. I probably won't be the only one to assume that. I knew smtp.qbik.com wouldn't be failing, and as far as I was concerned it was displaying that it was using smtp.qbik.com. So out of all this I would propose: 1. Change "Outgoing: SMTP" to "Outgoing (SMTP):" to make it clear that the SMTP label is an indication of the protocol only, and does not form part of the name being tested. 2. don't bother automatically putting any domain name into the edit fields that starts with a '.'. It implies something before it in the dialog is pre-pended. 3. display more specific progress and results from the tests than "Miramar failed to find the settings for your email account". E.g display * verifying IMAP account, looking up imap.qbik.com - failed * verifying IMAP account, looking up mail.qbik.com - succeeded * verifying IMAP account, connecting to mail.qbik.com - succeeded * verifying IMAP account, probing mail.qbik.com - succeeded * verifying SMTP, looking up smtp.qbik.com - succeeded * verifying SMTP, connecting to smtp.qbik.com - succeeded * verifying SMTP, probing smtp.qbik.com - succeeded if these flicked past, and stuck on the one that failed, it would be much more clear what remedial action was needed. You might need to put in a log button to bring up the test history so if it happens too quick you can go back and see what it did. > > most people don't have another account lying around they can use. > *Most people* do not want to set up accounts for servers which are not working. There's a difference between "not working NOW and will never work", and "not working NOW, but will be working in 1hr when I get back to the office and enable the client IP on my firewall". You need to keep in mind the timing. > This is why it works it does. Admins typically do have more than one account. > > What would be good enough is to simply fix the bug that is preventing the > > Advanced button from being enabled. > Again: It's not a bug. It's intentional. This is a change request, not a bug > report. (Which is fine, but please don't call it a bug.) I guess you're right this part is a change request. Now that I've figured out what is going on, there are 2 issues. 1. communication and confusion during discovery and retesting, arguably mis-labelled buttons. 2. policy issue about intentionally preventing creation of accounts where TB cannot validate them NOW. I think we can probably call 1 a bug at some level. As for 2, it's only my opinion, but I believe it's really foolhardy not to allow for a possibility that TB's ability to validate account details may not be perfect. There are lots of problem cases that could prevent validation (and therefore account creation) with valid data. This is a really serious message you're sending. TB hasn't done this in the past. TB 3.1 would allow account creation with any garbage that might work later when required. It puts users to some inconvenience to force them to fix other problems (possibly outside their realm of capability or administration) before they can set up an email account in a mail client. It's the closest thing to flipping the user the bird I can think of in software. Allowing the creation of the account gives the user flexibility about the order in which things are done. The support tech who has to do a 200 mile round trip to enable the mail to work because of this is NOT going to recommend TB to his next customer. In fact faced with a 200 mile round trip, I would most likely install Outlook Express instead. We have customers who support clients who don't have remote access to systems, or even enough nouse to edit account settings afterwards. We've had irate customers who have had to make such trips. It happens. It would not be good PR for TB. In the end, what's the first thing a new user of TB does once they download and install it - they set up an account. If they can't do that, what chance do you think TB has of remaining installed on their computer? This is where first impressions are made. After the installer itself, this part needs to be ultra-slick to cement in the user's mind that they made a good choice with this one. To my knowledge, no email software has ever prevented creation of an account simply because it was incapable _at_that_moment_ of verifying the details. It's a very bold and extremely unusual step. Regards Adrien
Sorry - probably scratch my comments about 200 mile round trips - I didn't understand where the workaround was headed. I see now that you meant entering some other valid servers in there so that the test would succeed then creating the account, then editing it to the real values. Which of course doesn't require any road miles.... as long as the tech thinks of it and has access to some servers that will validate (which he should, except SMTP could be a problem). It begs the question why put the user to that pain though. thanks for all your patience.
Ok, so let's keep this bug open for the question whether or not the redesigned account wizard should allow setup of a non-verifiable configuration if the user wishes to do so and all other options are exhausted (IMO after the user has entered Manual Config and re-tested it after editing). Some other issues Adrien mentions in comment #52 should be worth covering in separate bugs: > 1. Change "Outgoing: SMTP" to "Outgoing (SMTP):" to make it clear that the SMTP > label is an indication of the protocol only, and does not form part of the name > being tested. > 2. don't bother automatically putting any domain name into the edit fields that > starts with a '.'. It implies something before it in the dialog is pre-pended. Item #2 appears to be the main problem for the confusion. Manual Config starts off with a leading '.' if a configuration couldn't be established, which would be an invalid host name anyway. That looks clearly like a bug, and an "smtp", "imap", or "pop" could be prepended even if the server couldn't be verified. Making that unambiguous would also solve item #1. > 3. display more specific progress and results from the tests than "Miramar > failed to find the settings for your email account". E.g display > > * verifying IMAP account, looking up imap.qbik.com - failed > * verifying IMAP account, looking up mail.qbik.com - succeeded > * verifying IMAP account, connecting to mail.qbik.com - succeeded > * verifying IMAP account, probing mail.qbik.com - succeeded > * verifying SMTP, looking up smtp.qbik.com - succeeded > * verifying SMTP, connecting to smtp.qbik.com - succeeded > * verifying SMTP, probing smtp.qbik.com - succeeded Yes, if would be good to see those at least listed in the Activity Manager (maybe there is some debug information available already, but either would need a hidden preference being set or may be disabled in non-debug builds). Also, such an output would greatly benefit support to see how far the autoconfig process gets before an error occurs that leads it to fail. Adrien, if you want to file those two suggestions as new bugs I'll be happy to confirm them, or I can file them on your behalf.
Status: REOPENED → NEW
> 3. display more specific progress and results from the tests than "Miramar > failed to find the settings for your email account" We can't show progress, because we try all hosts *in parallel* now. Showing the all the "failed" results would be too technical, and wouldn't help. We don't want the user to guess, we want him to *get* the right config from his ISP or admin and enter that. > Manual Config starts off with a leading '.' if a configuration > couldn't be established, which would be an invalid host name anyway That's precisely the point. I prefill the domain, to save the user the typing. I add the dot in front, specifically to avoid catching a valid host "foo.com". The point is to *force* the user to enter something valid, but still help him maximally. I see that Adrian misunderstood 1) the label of the field 2) that he has to fill out both servers, but I believe that's obvious for most people. > "imap", or "pop" could be prepended even if the server couldn't be verified. We already try pop.foo.com. If that was working, it would be prefilled.
FWIW, the reason why I force the user to enter a valid server *before* he can click "Advanced config" is that the servername and -type that is entered here in the wizard will stay in the Thunderbird config forever, even if changed later in the Account Settings that open after "Advanced Config" opens. This has been the source of lots of confusion and *very* angry users before, that they didn't understand that clicking "Advanced Config" *creates* an account with these values. The server name and username can be changed, but they stay as internal values (e.g. directory name in profile). So, if we fix this, we must fix bug 636016 first (better communicate implication of "advanced config" button to user).
Depends on: 636016
Severity: major → enhancement
Severity: enhancement → normal
To summarize, *if* we fix this bug (I am still think that "Set up a server that's not working" is an edge case not worth considering), we should: - enable "advanced config" button as soon as we go into manual mode - fix bug 636016 to make the implication clear to the user Alternatively, we can treat this as DUP of bug 599173 - wizard should work when offline.
(In reply to comment #55) > We can't show progress, because we try all hosts *in parallel* now. > Showing the all the "failed" results would be too technical, and wouldn't help. I had the Activity Manager in mind, which is well capable of handling parallel processes. The main reason here would be for someone seeking support to direct him or her to the Activity Manager output, which would be better to pinpoint the possible cause than just the information "if went to Manual Config and now I have no clue how to continue" or to probe the servers manually from potentially a different location as the user with different conditions. Anyway, this would be another bug...
(In reply to comment #57) > - fix bug 636016 to make the implication clear to the user I'm fine with that part. If we allow the user to screw up, he or she should be sufficiently informed about this. Then it's no longer Thunderbird's fault. ;-) > Alternatively, we can treat this as DUP of bug 599173 - wizard should work when > offline. No, that one was duped against bug 583602 which was mainly about offline mode throwing an exception. That behavior is valid on branch where the old wizard is still there and may be solved independently, so these are two different issues.
(In reply to comment #55) > > 3. display more specific progress and results from the tests than "Miramar > > failed to find the settings for your email account" > We can't show progress, because we try all hosts *in parallel* now. OK. > Showing the all the "failed" results would be too technical, and wouldn't help. In the end though, the overall failure is based on being unable to verify both IMAP/POP3 _and_ SMTP. This isn't explicit stated anywhere. Even if you just said like "couldn't validate your SMTP server (tried x, y, z)" or something. Like I said, nowhere does it state that TB will a) attempt to verify all your settings b) block account creation unless all servers are currently accessible b is not the sort of thing I believe users will expect, since it's the first mail client I know of to take that (fairly outrageous) step. I certainly didn't expect TB to say to me "I know better than you so get lost". In fact I had to infer it from the actual message. I guess I was still stunned from having some piece of software effectively tell me I was too dumb to use it. > We don't want the user to guess, we want him to *get* the right config from his > ISP or admin and enter that. Sure. > > Manual Config starts off with a leading '.' if a configuration > > couldn't be established, which would be an invalid host name anyway > That's precisely the point. I prefill the domain, to save the user the typing. > I add the dot in front, specifically to avoid catching a valid host "foo.com". > The point is to *force* the user to enter something valid, but still help him > maximally. I think you'd actually be better off leaving something in there that didn't validate than try to help people without telling them what's going on. leaving smtp.qbik.com in there even if it failed validation (you don't necessarily know whether it's good or not, since you don't know when discovery may have been interrupted) is better. Or even bogusreplaceme.qbik.com > I see that Adrian misunderstood 1) the label of the field 2) that he has to > fill out both servers, but I believe that's obvious for most people. It's possible. Most people won't even get to this dialog. It's also possible I wouldn't be the only one confused by this. It's also possible there are so few of us that will be confused by this that it's not worth doing anything. But based on my experience of users, I doubt it. Whether in the end this creates more problems than it solves is something only history will tell us I think. At least you won't be bothered by support requests for all those people who couldn't create an account and instead just uninstalled. > > "imap", or "pop" could be prepended even if the server couldn't be verified. > We already try pop.foo.com. If that was working, it would be prefilled. If it had been tried at that stage.
(In reply to comment #57) > To summarize, *if* we fix this bug (I am still think that "Set up a server > that's not working" please consider instead "Set up a server that's not currently verifiable" that is the real edge case. TB's ability to verify something and a server's validity are two independent things that should not be confused. > is an edge case not worth considering), we should: > - enable "advanced config" button as soon as we go into manual mode > - fix bug 636016 to make the implication clear to the user > Alternatively, we can treat this as DUP of bug 599173 - wizard should work when > offline. I've got some ideas how the buttons etc could go, but I'd also want a skip button in there :) I think basically that the advanced config button could be removed, and that job could be done by the [Create account] button. If the CA button did just that, and the validation button could either be a next button (traditional wizard style) or an explicit [Validate] button. Could even separate out validation of mailbox from validation of ability to send (e.g. on different pages). I still think telling customers that don't want their users to use SMTP for whatever reason that they don't have a valid reason to exist is fairly problematic.
(In reply to comment #56) > FWIW, the reason why I force the user to enter a valid server *before* he can > click "Advanced config" is that the servername and -type that is entered here > in the wizard will stay in the Thunderbird config forever, even if changed > later in the Account Settings that open after "Advanced Config" opens. This has > been the source of lots of confusion and *very* angry users before, sounds like a bug to fix? I understand about not changing type (although some other clients did it I think - Eudora?). But not changing servername I can't think of any reason why that would not just be changed... or is it used in too many places? Maybe that job (e.g. folder paths etc) should be replaced by a name/label of the mailbox, instead of using the servername. that they > didn't understand that clicking "Advanced Config" *creates* an account with > these values. The server name and username can be changed, but they stay as > internal values (e.g. directory name in profile). > So, if we fix this, we must fix bug 636016 first (better communicate > implication of "advanced config" button to user). When I clicked advanced config, I expected to see an advanced config dialog, I certainly didn't expect it to create the account. I expected that job would have been done by the Create Account button.
Summary: [autoconfig] when server is broken, cannot create any accounts with Manual Config, "Advanced" and "Create" options remain disabled → [autoconfig] when servers cannot be verified, cannot create any accounts with Manual Config, "Advanced" and "Create" options remain disabled
(In reply to comment #55) > > 3. display more specific progress and results from the tests than "Miramar > > failed to find the settings for your email account" > > We can't show progress, because we try all hosts *in parallel* now. > Showing the all the "failed" results would be too technical, and wouldn't help. As a quick follow-up on that, there are two hidden preferences for logging, mail.wizard.logging.console (writes output into Tools > Error Console), and mail.wizard.logging.dump (when run from the command line on that terminal), so that part appears to be covered already though indeed rather technical, sufficiently covering database lookup as well as hosts and ports tried.
(In reply to comment #63) > mail.wizard.logging.console (writes output into Tools > Error Console), and > mail.wizard.logging.dump (when run from the command line on that terminal), Forgot to mention, change those from "None" to "All" to activate the logging.
Will it ever be fixed? I had to switch to foxmail because of that.
(In reply to comment #65) > Will it ever be fixed? I had to switch to foxmail because of that. Patches are always welcomed. And we will help you drive your patch in.
(In reply to Ben Bucksch (:BenB) from comment #51) > > The server was not broken, it was available. The validation was broken. > You haven't shown that. That might be true here, but there are other cases where the validation currently doesn't work, as bug 538809 demonstrates. The wizard shouldn't assume that the detection is infallible.
Detection != validation. You can override our detection by using Manual Config. The validation happens in the same way as Thunderbird tries to get mail. If the validation fails, the directly following login in main Thunderbird will also fail, and you'll get the "your login is wrong" dialog, and then everything goes down from there. We need to catch these problems during setup.
Here's what I ran into. I did the online setup and my previous personal message filter would no longer work (I have tons of entries that would be a pain to rebuild). It said that it couldn't find the "Junk" folder. I examined the prefs.js file and found that when TB imported my account, it added %40 into my account pref strings. This rendered my filter file unusable until I edited every line to the new string settings in my prefs.js file. An option to manually setup a profile account (if desired by the user) would be greatly appreciated.
Reading through the comments I've found that the problem of the original bugreport can be worked around by simply not clicking the "Manual config" button while the automatic discovery is in progress. Once the auto discovery fails, you'll be able to click "Create account" (or click "Manual config" and click "Advanced config"). However, if you do click the "Manual config" button while the auto discovery is taking place and you find yourself in the manual config UI but the "Advanced config" and "Create account" buttons are disabled, there's still a way out: set all fields with a value of "Auto" or "Autodetect" to something specific (leave no field empty or at an auto* setting). The actual values don't matter, you just have to alter all autodetect settings to something else and fill in empty fields. Voala: the "Advanced config" and "Create account" buttons became active! :-) I've verified this both in TB 11.0.1 (using Ubuntu) and TB 12.0.1 (using Mac OS X). P.S.: sorry if this was already discovered/published (I did not find it in the comments of this ticket/bugreport).
Hi Guys! Although it has been extensively discussed, I still have the problem. Tried waiting, tried to do everything I can do as a client. I do not have access to the server. I have other mail clients installed and working: Outlook, Live Mail, my android 2.3 corporate mail app, a web app (roundcube php postfix client), and so on. Can anyone help me with this? My create account button and advanced config are still disabled. Thank you.
Well I managed to create an account after all. Well, I created a real account using my gmail. Then after creating my account, went to the account settings in options, changed everything to my settings, created a new smtp server and it seems to be working, although my sent mails are not being saved into sent folder. (In reply to julianopolito from comment #71) > Hi Guys! > > Although it has been extensively discussed, I still have the problem. Tried > waiting, tried to do everything I can do as a client. I do not have access > to the server. I have other mail clients installed and working: Outlook, > Live Mail, my android 2.3 corporate mail app, a web app (roundcube php > postfix client), and so on. > > Can anyone help me with this? My create account button and advanced config > are still disabled. > > > Thank you.
bit2@freemail's comment 70 is puzzling. Could you tell us which domain you tried, and which *exact* steps you used (each mouse click you made)? Please try to reproduce it yourself with a current Thunderbird. julianopolito, which domain did you use? As for your Sent folder, and Trash and others, you can set them in the "Account setttings...".
Ok, I just realized about the folder setup after I wrote my reply. That's fine now. I used this 200.98.237.170 for IMAP with SSL port 993. My steps were: 1 - File>New>Existing Mail Account 2 - Filled Form with Info 3 - Pressed Continue 4 - Waited for the thunderbird failed to find the settings for your email account 5 - Filled everything and hit retest Advanced config nor create account got enabled. (In reply to Ben Bucksch (:BenB) from comment #73) > bit2@freemail's comment 70 is puzzling. Could you tell us which domain you > tried, and which *exact* steps you used (each mouse click you made)? Please > try to reproduce it yourself with a current Thunderbird. > > julianopolito, which domain did you use? > As for your Sent folder, and Trash and others, you can set them in the > "Account setttings...".
julianopolito, I guess you used SMTP SSL port 465. This is bug 755988.
Add x64 Windows 7 to the list of platforms, and given its parent bug 549045, it's probably cross-platform, if anyone can confirm this.
Hello, I have tried to setup a new IMAP account. The account existed and could be accessed via a web interface. The only problem was the server had a self-signed ssl certificate, witch i had to confirm in Thunderbird or any other Mozilla product. It seems that this is not a Thunderbird issue, but instead this is a problem caused by an outside program like Avast. From Avast user interface go to Settings -> Active Protection -> Click on the gear icon right to Mail Shield, then click on SSL Scanning and un-check the "Scan SSL Connections" from the right. Hope this will help somebody. :)
(In reply to bit2 from comment #70) > However, if you do click the "Manual config" button while the auto discovery > is taking place and you find yourself in the manual config UI but the > "Advanced config" and "Create account" buttons are disabled, there's still a > way out: set all fields with a value of "Auto" or "Autodetect" to something > specific (leave no field empty or at an auto* setting). May I propose a little, but very helpful improvement? The dialog should show an error message that explains why "create account" is disabled - for example "You need to select the SMTP port (instead of 'auto') before you can create the account".
As Christian pointed out, turning off the "autodetect" on the authentication method enables the ability to just accept the settings.
I can't believe this is so old and still a problem cross-platform. My workaround was to put in a fake gmail address and finish configuring it, then go into settings and completely change all the details of the existing account. I don't know why they have to be so forceful about making people use this wizard that clearly doesn't work.
Got bitten by this as well. I have my own email server that for now has an invalid certificate and likely this caused the auto-config not to work. There was not a meaningful error message either. My workaround: Use google mail to set up the account, then change the server settings for the account and accept the invalid certificate for IMAP. I tried clicking on manual too, but this tries to validate which fails. The Advanced option always stayed grayed out. As the setup is done now, there is no way to add a new account if it has some issues (could also be server temporarily down, invalid certificate, ...). Basic UI principle: One should always be able to set up and edit an account and then be given the option (a courtesy option, not mandatory base functionality) to validate the account and trouble shoot if something is not working. Validation and refusal to add/change settings should never be the default and/or only option.
> Expected Results: > allow creation of the account, no matter what garbage I put in there. That's *not* the expected result. We decidedly do *not* want normal (!) users to put garbage in there and create accounts that will not work. For people who know what they are doing, we added the [Advanced Config]. ----- If you are an expert and you know it will work, even though the dialog thinks that it will not, then you can use the [Advanced Config] button. Solution steps: 1. Enter you@example.com and your name 2. Press [Continue] 3. Press [Manual Config] (or the dialog will do that automatically, if it can't find a server, like for example.com) 4. Enter the correct config. You need to enter a *full* config that's required for an account, i.e. * syntactically valid hostnames * port numbers, * SSL * authentication methods You cannot continue until you do that, because we need all that information to create the account. 5. Press [Advanced Config] 6. Edit everything. This works, I just tried it.
Whiteboard: See comment 82 for workaround

(In reply to Ben Bucksch (:BenB) from comment #82)

  1. Press [Advanced Config]
  2. Edit everything.

This works, I just tried it.

Thanks for the post Ben!!!
It works !

One more thing, if you click "retest" then "advanced config" will be grayed out, so making a dummy change to one of the settings will then re-enable the "advanced config" button.

But if you don't click the "retest", and follow Ben's instructions it will allow you to click on the "advanced config", else you will have to do a dummy edit to re-enable the "advanced config" button.

Now if thunderbird would just sop greying out that button so that we don't have to go though all this trouble searching the net to find out how to get around this problem.

Wayne Sallee
Wayne@WayneSallee.com

Thunderbird was not able to connect to my account. I tried the MUA evolution, and that worked.

This is a bug and it still exists. I have 100% entered the correct information, and Thunderbird authenticates correctly on IMAP. The same information is used for SMTP, and Thunderbird fails. The error shown in the Postfix log is 'improper command pipelining after EHLO from'.

This is not a Postfix problem. It is a Thunderbird problem. My email works with Apple Mail, it works with Claws. It works on my Android phone. I thought I would try Thunderbird again after a hiatus of several years. My experience today is one of scratching my head. It doesn't work. so what am I doing wrong? Well the answer is nothing. How could I possibly recommend Thunderbird to anyone when I can't even use it myself?

Why do I need to add in a DNS record for something unrelated to SMTP/IMAP/POP3 to get Thunderbird to work? Following that faulty logic, I should put some NTP servers in too. You are creating a false and unnecessary dependency.

The 'solution' given by Ben Bucksch three years ago is not a solution. It may work for him, but it will not work 'in general' without relying on something else.

This is very unimpressive. So my latest experience with Thunderbird has lasted < 2 minutes.

(In reply to Why bother? from comment #87)

This is a bug and it still exists. I have 100% entered the correct information, and Thunderbird authenticates correctly on IMAP. The same information is used for SMTP, and Thunderbird fails. The error shown in the Postfix log is 'improper command pipelining after EHLO from'.

This is not a Postfix problem. It is a Thunderbird problem. My email works with Apple Mail, it works with Claws. It works on my Android phone. I thought I would try Thunderbird again after a hiatus of several years. My experience today is one of scratching my head. It doesn't work. so what am I doing wrong? Well the answer is nothing. How could I possibly recommend Thunderbird to anyone when I can't even use it myself?

Why do I need to add in a DNS record for something unrelated to SMTP/IMAP/POP3 to get Thunderbird to work? Following that faulty logic, I should put some NTP servers in too. You are creating a false and unnecessary dependency.

The 'solution' given by Ben Bucksch three years ago is not a solution. It may work for him, but it will not work 'in general' without relying on something else.

This is very unimpressive. So my latest experience with Thunderbird has lasted < 2 minutes.

I have stopped upgrading at version 60.9.1
You might want to roll back to version 60.9.1
The bug still exists, but maybe it will work with the above advice.

Wayne Sallee
Wayne@WayneSallee.com

The error shown in the Postfix log is 'improper command pipelining after EHLO from'.

That's bug 538809.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.