Requirements for this patch: * 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. Together with the previous requirement, that makes the fix difficult. Making the fix specific to the Microsoft server gets us out of this problem. * The code footprint should be low and preferably be confined to one place.
Bug 1592258 Comment 39 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Requirements for this patch: * 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. Together with the previous requirement, that makes the fix difficult. Making the fix specific to the Microsoft server gets us out of this problem. * The code footprint should preferably be confined to one place.
Requirements for this patch: * 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. Together with the previous requirement, that makes the fix difficult. Making the fix specific to the Microsoft server gets us out of this problem. * The code footprint should preferably be confined to one place and be follow the existing logic of the dialog.
Requirements for this patch: * 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. Together with the previous requirement, that makes the fix difficult. Making the fix specific to the Microsoft server gets us out of this problem. * The code footprint should preferably be confined to one place.
Requirements for this patch: * 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. Together with the previous requirement, that makes the fix difficult. Making the fix specific to the Microsoft server gets us out of this problem. * The code footprint should preferably be confined to one place, and be coherent with the rest.