Anonymous

My feedback

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

    We’ll send you updates on this idea

    5 comments  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  2. 926 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    open discussion  ·  183 comments  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Anonymous commented  · 

    Looking at the fact that Plesk Email Security Pro now includes ClamAV, I assume from a change request point of view, Plesk will see this as solved.
    However, it is VERY DISAPPOINTING to see again that Plesk failed to follow the community demand having this as an unpaid extension.
    Also, from a security standpoint, I think it is socially not acceptable that they require us to pay for it, especially given the fact that they mainly employ open software for this feature.
    In addition, the extension has the drawback that greylisting needs to be disabled, which I think is a bad idea.

    Nevertheless, following https://www.lloyd-day.me/migrate-plesk-to-clamav/, there is quite a simple solution if you want to integrate ClamAV yourself.
    By not uninstalling DrWeb (free protection of 10 mailboxes), you can even run both in parallel by adapting the information in step 4 (settings for /etc/postfix/main.cf):

    With psa_remote and ClamAV, I use:
    smtpd_milters = {inet:127.0.0.1:12768, default_action=accept}, { inet:127.0.0.1:3381, protocol=6, default_action=tempfail }
    non_smtpd_milters = , inet:127.0.0.1:12768

    This setting also helps to avoid issues when DrWeb fails to scan e-mails (happens quite frequently)...

    Anonymous supported this idea  · 
  3. 17 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    open discussion  ·  5 comments  ·  Feature Suggestions » Migrations  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  4. 5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  5. 27 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    open discussion  ·  9 comments  ·  Feature Suggestions » Backup / Restore  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Anonymous commented  · 

    @Plesk Staff: The problem as we observe it quite frequently: The FTP upload fails for unknown reasons when run as a daily backup job. Thus, the backup is stored locally and consumes storage space on the server.

    In order to ensure that the FTP server has a backup of every day, the current situation means that you manually have to trigger the backup on the same day so that there is another backup on the FTP storage. Once this has been done successfully, you can then delete the local backup.

    If you had the opportunity to just move the local backup to the FTP storage, this would speed up the process and require less admin action. Ideally, you could even define how many times the server should try to upload the backup to the FTP storage. In addition, it could help if local backups would be stored as one single archive file (which I can easily move to the FTP storage), instead of having multiple files and directories for one backup task.

    Interestingly, the manually triggered backup so far always succeeded with uploading while the automated one fails on a regular basis. (Thus, it would be interesting to find out if there is some kind of bug in the automated backup scripts.)

    An error occurred while saving the comment
    Anonymous commented  · 

    As explained for instance at https://talk.plesk.com/threads/personal-ftp-repository-backup-failing-on-upload.335299/#post-804534 sometimes full server backups fail. In this case, the backups are stored locally on the server even though the backup was meant to be stored on the FTP server. Now you have two issues:
    a) The backup is stored locally, but not as a single file (compared to the FTP backup files). Thus you cannot simply move the file from local storage to the remote FTP server. In addition, it is unclear whether Backup Manager will recognize that the backup has been moved.
    b) The (broken) part of the uploaded file is still there and shown in the Backup Manager.

  6. 200 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    24 comments  ·  Feature Suggestions » Web / SSL  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Anonymous commented  · 

    I agree with H. Dolderer, this is a must for current systems - also given that in certain combinations of using SSL for Plesk and the corresponding website, it is otherwise impossible to access the admin interface right now!
    Also, looking at the implementation effort, this should almost be zero since the same has been done for the webmail system already. Thus, it is disappointing to read a statement like "we might eventually implement this at some point (> 10 years...?) in the future"...

    An error occurred while saving the comment
    Anonymous commented  · 

    You're right, it is currently not supported: https://support.plesk.com/hc/en-us/articles/115002810634

    However, given the comment from darkdragen, I agree that the service should be secured the same way as it has been done already for the webmail subdomains.

    Anonymous supported this idea  · 
  7. 581 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    open discussion  ·  68 comments  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Anonymous commented  · 

    Annoying that it is a premium extension only!

    Anonymous supported this idea  · 
  8. 10 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Feature Suggestions » Security  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous shared this idea  · 
  9. 273 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 » Plesk (general)  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  10. 395 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    open discussion  ·  19 comments  ·  Feature Suggestions » Panel/Mail  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  11. 183 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    14 comments  ·  Feature Suggestions » Mail  ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous supported this idea  · 
  12. 428 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    54 comments  ·  Feature Suggestions » Security  ·  Flag idea as inappropriate…  ·  Admin →

    We have serious doubts this function can really increase server security:
    1) Plesk has built-in protection against brute-force on login – it will lock the login form. So no one can try multiple attempts
    2) Arbitrary login name adds very little guess-complexity to a proper password. If you have concerns for your login brute-forced – add another 5-7 characters into your password and feel safe.

    As changed login name is still very likely to be some sort of vocabulary word or derived from your other account name – this function would only give a false sense of better security. Your security strength is in complex password, not in a complex login name. If you have one good password, you don’t need to treat login as your “second password” – one good password is enough.

    As for concerns that default password requirement is set in “weak”, that fail2ban module is not…

    Anonymous supported this idea  · 

Feedback and Knowledge Base