Stefan Brauner
My feedback
30 results found
-
25 votes
One good reason why it is important to use own DKIM key is that for sending mail from different servers that service the same domain (e.g. during a migration) the key on the target needs to be the same as on the source.
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.
-- PD
-
22 votes
An error occurred while saving the comment -
32 votes
We will consider this functionality in upcoming releases if it will be popular. However, in part of integration with 3rd party, probably it will be faster if you create Plesk extension. Please refer to https://docs.plesk.com/en-US/17.0/extensions-guide/what-are-plesk-extensions%3F.76331/ to know how.
Everyone, please continue voting for this feature if you consider it important.
—
ET -
127 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.— rk
-
100 votes
Hi everyone,
This seems to be important, so we’ll address it in one of the upcoming Plesk releases.
Please continue to vote so we can accurately assess the popularity of this request.
— AK
-
48 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.
—
IG -
73 votes
The roles that you can set for additional user accounts can help achieve many of the aspects that are mentioned in this feature request. Please see the blog article https://www.plesk.com/blog/product-technology/how-to-grant-access-website-secure-way/ for getting started with roles.
-- PD
-
4 votes
Thank you for your input! We will consider this functionality in upcoming releases if it is popular. Everyone, please continue voting for this feature if you consider it important.
—
IG -
82 votes
-
30 votes
-
23 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.
—
IG -
4 votes
This is a valid request, so we'll look into it. There is no ETA at the moment, but we would really appreciate you voting for this request so that we can accurately assess its popularity relative to other features.
Thanks in advance!
--
IG
-
129 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.
—
IG -
55 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.— rk
-
126 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.
—
IG -
178 votes
-
583 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.
—
IG -
94 votes
-
357 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.
— AY
-
79 votes
We are considering this, yes. Feel free to share in comments your ideas on which specific scenarios you would like to see there.
It would be great to see that feature in the future. Currently I have to disable HSTS in the Plesk Panel, disable the prefered www and then set the HSTS header with preload and the redirection to www in the nginx for each domain manually, because otherwise there is no HSTS header for the non-www-Page.
It would be great if it would be possible to set the preload directive, max age 1 year (6 years is not enough for preloading and I want to avoid 2 years) and the header set before the redirection to the prefered choicee (www or not)