analyzer
My feedback
3 results found
-
56 votes
Thank you for your input! We will consider this functionality in upcoming releases if it will be popular. Everyone, please continue voting for this feature if you consider it important.
The previous status update was done by mistake.
— AY
An error occurred while saving the comment An error occurred while saving the comment analyzer
commented
So would you agree about this max. configurability proposal to PLESK staff?
For admins:
- per each autodiscovery method (autoconfig / autodiscover / email.mobileconfig) :
-- SMTP: Hostname + Port + SocketType + Authentication
-- IMAP: return_boolean + Hostname + Port + SocketType + Authentication
-- POP: return_boolean + Hostname + Port + SocketType + Authentication.Remarks:
If return_boolean is false, then xml does not return the particular protocol option.Hostnames would accept the static format L3.L2.TLD. One could also consider if it's viable (with a possible certificate mess in mind) to accept a dynamic format L3.* (with * as a placeholder for subsribers' domains), too, serving your requirement number 2. However, on typical all-in-one systems I do not see an advantage of such distinction.
Port and SocketType input would NOT limit suport of alternative methods; e.g. if SMTP Port 587 with StartTLS is propagated over autodiscover, users could still change the setting manually to legacy ports 25/StartTLS or 465/SSL (and other way round).
For resellers:
The same options as for the admin?On service-plan level: none.
For Subscribers: none
For Mailaccounts: none
An error occurred while saving the comment analyzer
commented
1) perhaps I misread the template posted in https://talk.plesk.com/threads/how-can-i-change-the-default-mail-autodiscover-parameters.355252/
Or perhaps it's the clients that propagate IMAP, particularly since so many users access their boxes over their mobilephones, where local POP mass storage is almost a crime.
analyzer
supported this idea
·
An error occurred while saving the comment analyzer
commented
@GJ, +1, but:
1) POP-or-IMAP choice should not be preselected by the server. Is it not true that the returned xml contains values for both options simultaneously, leaving it to the client app to display both available options to the user (If the user has not declared his choice to the app already before)?
2) you mean for split systems?
3) respectively what we recommend to users
-
229 votesanalyzer
supported this idea
·
-
1,295 votesanalyzer
supported this idea
·
I understand that if a user decides to run the atodiscover/autoconfig routine of his clients, then he accepts recommendations by people with better insight.
There are enough reasons to navigate into full account settings, once the basic account creation is done, and adjust a handful of less-technical things that autodiscover/config can never anticipate for the individual user at the individual mailclient. Talking about imap-role-folders or pop-leave-message-on-server-settings etc etc etc etc
With this he can just as well adjust ports and sockettypes, e.g. if he trusts other ones more than the recommended ones, or if there are firewall restrictions in the networks he is typically connected to.
However, I don't see "justifying additional comfort" for the user by having the "ability" to "predefine" these values in the autoconfig/autodiscover XML interface (manually over PLESK's UI) compared to the "requirement" to create accounts as manually as possible over the clients' UIs.
Same with giving autoconfig/autodiscover preferences authority to subscribers. Their users may just prefer different settings again (if at all). Because you can never make it right to everyone, anyway, no matter whether you are subscriber or admin.
That said, I yet suggest reseller authority in favor of less irritation with transiting customers (both incoming and outgoing). If both the earlier and the successor provider set server names to be identical, e.g. <subscriberdomain> (as PLESK staff unfortunately seems to see as the one to be preferred) or even mail./smtp./imap./pop.<subscriberdomain>, then confusing situations could occur easily during the migration phase depending on DNS authority and values and cacheing etc. It's more transparent to all if you can tell the server's ID right by its name.