> DNS MX record ... is just as vulnerable as looking up DNS SRV records Yes, but we use MX only as fallback when we cannot get the config directly. If possible, we use HTTPS from the provider directly, or ISPDB, which is also HTTPS. But you're recommending to replace these secure mechanisms with the less secure DNS SRV: > by supporting RFC 6186, we could potentially remove at least 9 config files from the ISPDB In addition, DNS SRV does not provide a solution for reason 3 in comment 63. DNS SRV only provides hostname and port. It's simply lacking the majority of the information: username form, authentication method, OAuth2 server etc.pp.. Scrambling and guessing and try&error are not a solution, esp. when it comes to login - that's what we did 15 years ago, before AutoConfig, and it did not work, that's why I invented AutoConfig in the first place.
Bug 342242 Comment 81 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> DNS MX record ... is just as vulnerable as looking up DNS SRV records Yes, but we use MX only as fallback when we cannot get the config directly. If possible, we use HTTPS from the provider directly, or ISPDB, which is also HTTPS. But you're recommending to replace these secure mechanisms with the less secure DNS SRV: > by supporting RFC 6186, we could potentially remove at least 9 config files from the ISPDB In addition, DNS SRV does not provide a solution for reason 3 in comment 63. DNS SRV only provides hostname and port. It's simply lacking the majority of the information: username form, authentication method, OAuth2 server etc.pp.. Scrambling and guessing and try&error are not a solution, esp. when it comes to login, and esp. considering the multiplication of the factors - that's what we did 15 years ago, before AutoConfig, and it did not work, that's why I invented AutoConfig in the first place.
> DNS MX record ... is just as vulnerable as looking up DNS SRV records Yes, but we use MX only as fallback when we cannot get the config directly. If possible, we use HTTPS from the provider directly, or ISPDB, which is also HTTPS. But you're recommending to replace these secure mechanisms with the less secure DNS SRV: > by supporting RFC 6186, we could potentially remove at least 9 config files from the ISPDB In addition, DNS SRV does not provide a solution for reason 3 in comment 63. DNS SRV only provides hostname and port. It's simply lacking the majority of the information: username form, authentication method, OAuth2 server etc.pp.. Scrambling and guessing and try&error are not a solution, esp. when it comes to login, and considering the multiplication of the factors - that's what we did 15 years ago, before AutoConfig, and it did not work, that's why I invented AutoConfig in the first place.
> DNS MX record ... is just as vulnerable as looking up DNS SRV records Yes, but we use MX only as fallback when we cannot get the config directly. If possible, we use HTTPS from the provider directly, or ISPDB, which is also HTTPS. But you're recommending to replace these secure mechanisms with the less secure DNS SRV: > by supporting RFC 6186, we could potentially remove at least 9 config files from the ISPDB In addition, DNS SRV does not provide a solution for reason 3 in comment 63. DNS SRV only provides hostname and port. It's simply lacking the majority of the information: username form, authentication method, OAuth2 server etc.pp.. Scrambling and guessing and try&error are not a solution, esp. when it comes to login, and considering the multiplication of the various factors - that's what we did 15 years ago, before AutoConfig, and it did not work, that's why I invented AutoConfig in the first place.