(In reply to Magnus Melin [:mkmelin] from comment #84) > Yes, like I wrote in comment 71, not too much left to do in this bug. The patch ensures we do not show exchange for on premise exchange when IMAP and/or POP are available. I think that detail is really not needed. We don't need to preach IMAP to people who are already on the M$ boat heading to their on-premise Exchange server. Why be even more hardlined then we've ever been? > IMAP is always *available*. If it's working or not is a secondary issue - and verifying that is the *next* step in the wizard. OK, so what does the wizzard do if IMAP fails in the next step? Anything useful that would allow the user to create a working account setup? Funny that we're arguing about "available" vs. "working" now. > I would be interested in numbers. I'm sure Ben can supply numbers. > Either way, it's irrelevant for what the council decision was: to get back to square one. There is a new Council motion on the way. Even if we implemented the one you're referring to, removal from the ISPDB is sufficient. > Eh, the very patch proposed by Ben *hardcodes* a outlook.office365.com into the source code. Basically unprecedented! Really? How about: https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mail/extensions/openpgp/content/modules/wkdLookup.jsm#28 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/imap/src/nsImapProtocol.cpp#7340 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/mailnews.js#546 https://searchfox.org/comm-central/search?q=Gmail&case=true®exp=false&path= Office365 is becoming a global mail provider like Gmail, so I don't have a problem with hardcoding the domain where relevant. > Implementing client specific behaviour in ispdb is certainty against the philosophy behind that code: it's not meant to be Thunderbird only (though yes, catering for Thunderbird's needs), and in fact, sadly, Thunderbird only accounts for a fraction of the traffic. The ISPDB was invented for Thunderbird account setup and has been so successful that other clients are using it to, for example my Android app FairEmail. IMHO there's nothing wrong adding certain attribution to certain entries that a client may or may not process.
Bug 1592258 Comment 85 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Magnus Melin [:mkmelin] from comment #84) > Yes, like I wrote in comment 71, not too much left to do in this bug. The patch ensures we do not show exchange for on premise exchange when IMAP and/or POP are available. I think that detail is really not needed. We don't need to preach IMAP to people who are already on the M$ boat heading to their on-premise Exchange server. Why be even more hardlined then we've ever been? > IMAP is always *available*. If it's working or not is a secondary issue - and verifying that is the *next* step in the wizard. OK, so what does the wizzard do if IMAP fails in the next step? Anything useful that would allow the user to create a working account setup? Funny that we're arguing about "available" vs. "working" now. > I would be interested in numbers. I'm sure Ben can supply numbers. > Either way, it's irrelevant for what the council decision was: to get back to square one. There is a new Council motion on the way. Even if we implemented the one you're referring to, removal from the ISPDB would be sufficient. > Eh, the very patch proposed by Ben *hardcodes* a outlook.office365.com into the source code. Basically unprecedented! Really? How about: https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mail/extensions/openpgp/content/modules/wkdLookup.jsm#28 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/imap/src/nsImapProtocol.cpp#7340 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/mailnews.js#546 https://searchfox.org/comm-central/search?q=Gmail&case=true®exp=false&path= Office365 is becoming a global mail provider like Gmail, so I don't have a problem with hardcoding the domain where relevant. > Implementing client specific behaviour in ispdb is certainty against the philosophy behind that code: it's not meant to be Thunderbird only (though yes, catering for Thunderbird's needs), and in fact, sadly, Thunderbird only accounts for a fraction of the traffic. The ISPDB was invented for Thunderbird account setup and has been so successful that other clients are using it to, for example my Android app FairEmail. IMHO there's nothing wrong adding certain attribution to certain entries that a client may or may not process.
(In reply to Magnus Melin [:mkmelin] from comment #84) > Yes, like I wrote in comment 71, not too much left to do in this bug. The patch ensures we do not show exchange for on premise exchange when IMAP and/or POP are available. I think that detail is really not needed. We don't need to preach IMAP to people who are already on the M$ boat heading to their on-premise Exchange server. Why be even more hardlined then we've ever been? > IMAP is always *available*. If it's working or not is a secondary issue - and verifying that is the *next* step in the wizard. OK, so what does the wizzard do if IMAP fails in the next step? Anything useful that would allow the user to create a working account setup? Funny that we're arguing about "available" vs. "working" now. > I would be interested in numbers. I'm sure Ben can supply numbers. > Either way, it's irrelevant for what the council decision was: to get back to square one. There is a new Council motion on the way. Even if we implemented the one you're referring to, removal from the ISPDB would be sufficient. > Eh, the very patch proposed by Ben *hardcodes* a outlook.office365.com into the source code. Basically unprecedented! Really? How about: https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mail/extensions/openpgp/content/modules/wkdLookup.jsm#28 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/imap/src/nsImapProtocol.cpp#7340 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/mailnews.js#546 https://searchfox.org/comm-central/search?q=Gmail&case=true®exp=false&path= Office365 is becoming a global mail provider like Gmail, so I don't have a problem with hardcoding the domain where relevant. That said: We might want to move the string into a pref, like we've done for the Openwave thing I've referenced above. > Implementing client specific behaviour in ispdb is certainty against the philosophy behind that code: it's not meant to be Thunderbird only (though yes, catering for Thunderbird's needs), and in fact, sadly, Thunderbird only accounts for a fraction of the traffic. The ISPDB was invented for Thunderbird account setup and has been so successful that other clients are using it to, for example my Android app FairEmail. IMHO there's nothing wrong adding certain attribution to certain entries that a client may or may not process. Maybe we should consult the inventor of the ISPDB about its underlying philosophy.
(In reply to Magnus Melin [:mkmelin] from comment #84) > Yes, like I wrote in comment 71, not too much left to do in this bug. The patch ensures we do not show exchange for on premise exchange when IMAP and/or POP are available. I think that detail is really not needed. We don't need to preach IMAP to people who are already on the M$ boat heading to their on-premise Exchange server. Why be even more hardlined than we've ever been? > IMAP is always *available*. If it's working or not is a secondary issue - and verifying that is the *next* step in the wizard. OK, so what does the wizzard do if IMAP fails in the next step? Anything useful that would allow the user to create a working account setup? Funny that we're arguing about "available" vs. "working" now. > I would be interested in numbers. I'm sure Ben can supply numbers. > Either way, it's irrelevant for what the council decision was: to get back to square one. There is a new Council motion on the way. Even if we implemented the one you're referring to, removal from the ISPDB would be sufficient. > Eh, the very patch proposed by Ben *hardcodes* a outlook.office365.com into the source code. Basically unprecedented! Really? How about: https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mail/extensions/openpgp/content/modules/wkdLookup.jsm#28 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/imap/src/nsImapProtocol.cpp#7340 https://searchfox.org/comm-central/rev/f40fe7e4be1d5dc5bd90c831a0bf87d354f3e74b/mailnews/mailnews.js#546 https://searchfox.org/comm-central/search?q=Gmail&case=true®exp=false&path= Office365 is becoming a global mail provider like Gmail, so I don't have a problem with hardcoding the domain where relevant. That said: We might want to move the string into a pref, like we've done for the Openwave thing I've referenced above. > Implementing client specific behaviour in ispdb is certainty against the philosophy behind that code: it's not meant to be Thunderbird only (though yes, catering for Thunderbird's needs), and in fact, sadly, Thunderbird only accounts for a fraction of the traffic. The ISPDB was invented for Thunderbird account setup and has been so successful that other clients are using it to, for example my Android app FairEmail. IMHO there's nothing wrong adding certain attribution to certain entries that a client may or may not process. Maybe we should consult the inventor of the ISPDB about its underlying philosophy.