> Especially as the preferred way to connect to ms mail services in other clients than Outlook is through IMAP/POP3. Other means are really not supported in any official manner. > I don't think we want to have a per-hostname exception. * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem. It also limits the effects of this patch. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself calls "legacy protocols" in other documents. It doesn't mean that the others are not supported. Quite the opposite, Microsoft itself wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. Just while I was testing this patch, Microsoft blocked my outlook.com test account access, simply because I logged in from IMAP (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
Bug 1592258 Comment 43 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> I don't think we want to have a per-hostname exception. * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem. It also limits the effects of this patch. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself calls "legacy protocols" in other documents. It doesn't mean that the others are not supported. Quite the opposite, Microsoft itself wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. Just while I was testing this patch, Microsoft blocked my outlook.com test account access, simply because I logged in from IMAP (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem. It also limits the effects of this patch. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself calls "legacy protocols" in other documents. It doesn't mean that the others are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, Microsoft blocked my outlook.com test account access, simply because I logged in from IMAP (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem. It also limits the effects of this patch. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself calls "legacy protocols" in other documents. It doesn't mean that the others are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem. It also limits the effects of this patch. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself calls "legacy protocols" in other documents. It doesn't mean that the others are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to your idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself calls "legacy protocols" in other documents. It doesn't mean that the others are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to your idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only configs that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to your idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only configs (as default) that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to your idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only the configs (as default) that are known to work. * The user approval before contacting an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to your idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only the configs (as default) that are known to work. * The user approval before logging in to an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to your idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only the configs (as default) that are known to work. * The user approval before logging in with password to an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to your idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only the configs (as default) that are known to work. * The user approval before logging in with password to an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to Magnus' idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only the configs (as default) that are known to work. * The user approval before logging in with password to an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to Magnus' idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean Hotmail, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.
> I don't think we want to have a per-hostname exception. This dialog has as basic requirements, among others: * We must not show a config to the user that will eventually fail. To the user, we must propose only the configs (as default) that are known to work. * The user approval before logging in with password to an unknown IMAP server was a security measure, because we don't trust the network sources for configs. Making the fix specific to the Microsoft server gets us out of this problem, and also adheres to Magnus' idea of checking whether the IMAP server works. It also avoids that the patch has unintended side effects. > I see you went and made Exchange the first (==default) for the Microsoft domains in ISPDB (I assume you mean outlook.com = Hotmail, what Microsoft calls "Personal accounts".) > Given the official documentation from Microsoft, that's just wrong. [Exchange is] not a supported option: https://support.office.com/en-us/article/pop-imap-and-smtp-settings-for-outlook-com-d088b986-291d-42b8-9564-9c414e2aa040 I don't know how you infer that from this document. The document only shows how to configure IMAP and POP3, which Microsoft itself in other documents calls "legacy protocols". It doesn't mean that other protocols are not supported. Quite the opposite, Microsoft wants people to use their own protocols, not IMAP. Microsoft does advocacy to discourage IMAP. And not just advocacy: Just while I was testing this patch, **Microsoft blocked my @outlook.com account access, simply because I logged in from IMAP** (they said "new device", but that's a false claim). > other clients are also using ISPDB and if they were not careful, they are now broken since exchange is listed as default. The config file is defined so that we can add new types and new authentication mechanisms, and the client must ignore unknown types. If they are broken, they were broken from the start, and they've likely also been broken by earlier additions we made in the last few years.