> We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. We would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Bug 1592258 Comment 89 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. It's completely overboard. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. We would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
> We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. We would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
> We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended. The TB Council will decide on Office365. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. We would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
> We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. We would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. We would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations, all of them on Office365. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, in several different organizations, on Office365. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, on Office365, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show broken configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix an unintended regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, on Office365, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show non-working configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix a regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, on Office365, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literal rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show non-working configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix a regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, on Office365, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and literally rocket scientists, and it's getting increasibly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show non-working configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix a regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, on Office365, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers and not just proverbial, but literally rocket scientists, and it's getting increasingly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show non-working configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.
Magnus wrote: > We're talking about O365 now That's not what your patch does. > That was how it was before this bug: only show exchange if other protocols failed. That applied to on-premise exchange too. That is not true, and it's clear to anyone who understands what your patch does. As the first words in comment 0 show, we're trying to fix a regression caused by bug 1571772, which was on Office365 and Hotmail. The effects on Hotmail were completely unintended and already fixed by bug 1185366. This leaves Office365 here, and the TB Council is currently discussing that. Your patch removes options for on-premise Exchange that were there long before bug 1571772. And it's clear from your patch that it's deliberate. That's one reason why I called on the TB Council. Jörg wrote: > Why do we have bug bug 1528136 on file? Q3: Is that not a reason why IMAP is sometimes not available? FYI, that is a possible reason, but there are a number of other reasons why IMAP might be deactivated and not available. Microsoft offers so many different ways in so many different places and angles and reasons to disable IMAP. In effect, many users cannot use IMAP. > I know from first hand experience that whole organisations **force** users onto using the Outlook client (since the have a contract with Microsoft) and will under no circumstances enable IMAP. Ditto. I was in the same situation, on Office365, in several different organizations. Many other people are in the same situation, I read that in support emails, from novices to highly technical users like software engineers, and it's getting increasingly worse instead of better. Magnus wrote: > IMAP is always available. If it's working or not is a secondary issue Now you're down to just playing with words. Something that doesn't work isn't available, no. A technical device that's sitting in front of you physically and is broken and not working is not "available". This is especially true when that device was deliberately deactivated by someone. It's then exactly *not* available. Jörg wrote: > OK, so what does the wizzard do if IMAP fails in the next step? That's exactly the problem. Without my patch, we would show "wrong password", which makes the user try other passwords. That's a complete disaster. We can't have that. I'm not going to show non-working configs to the user and then tell him "password wrong". That's a complete no-go. That's why my patch is written the way it is.