analyzer

My feedback

  1. 13 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    analyzer commented  · 

    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.

    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

  2. 160 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    open discussion  ·  32 comments  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    analyzer supported this idea  · 
  3. 881 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    open discussion  ·  172 comments  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    analyzer supported this idea  · 

Feedback and Knowledge Base