Plesk controlled signature/disclaimer management

1)per user
2)per URL
3)server wide

plesk or email in drop down and in the text field

1. signature at user-level (user@sld.tld) | eg: Regards Mr. Abc
2. signature at domain-level (*@sld.tld) | eg: Company xyz, Address
3. signature at server-level | eg: "Nessage was tested against spam by xyz-freemail.com"

Every "snippet" should be added from level | in this example:
"regards
Mr. Abc
Company xyz
Address
Message was tested against spam by xyz-freemail.com"

A client approached me with exactly this request
what I could get working was the following:
https://www.howtoforge.com/add-disclaimers-to-outgoing-emails-with-altermime-postfix-debian-etch
Unfortunately it places all send email in the Inbox folder - so I had to cancel it.

Similar even more detailed / diverse is this approach.
Where one could have a general line added to every outbound email and a per URL defined version
https://www.gypthecat.com/how-to-add-different-disclaimers-using-altermime-and-postfix-based-on-domain

Unfortunately my postfix knowledge is not good enough to get it all working! :( But the idea is good.

Hello, I'm using Plesk Onyx and I've also bumped into problems with not being able to set correct NGINX Directives.

Regarding nginx and nginx configuration for various CMS, Web Apps etc, I see that a lot of directives need to be set and there are a lot of scattered issues around in the web.
For example most CMS will require a
location / { ... }
or for google's pagespeed test we need to add expire headers e.g.
location ~* .*.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 14d;
}

I think the Model to building the final vhost conf file should be revised instead of focusing on specific use cases like "Duplicate Location / {} directives".

If we simplify it, the current model works like that:
The Plesk vhost template for NGINX reads some database values and then appends specific directives using variables regarding the domain.
Afterwards it includes the custom vhost_nginx.conf file at each server {...} directive declaration.

So since some records are already defined, the originals match before our own directives so our directives are ignored or our directives turn out as duplicates.

I can think of 3 different suggestions instead in this case.
1. Add the ability to set a custom base vhost template for each vhost separately
In this case:
- The vhost is created by PLESK using the default template.
- The user would then be able to clone the original template and modify to their needs
- The modified template would be saved either to the db or to a separate file
- If a modified template exists -> the system would use that one instead of the PLESK default one to build the final last_nginx.conf file.

1. Keep only minimal required vhost configuration information in the base template and add the rest to db so that people can then easily override for their custom vhost configuration. In this case:
2. Separate Location / {} directives from the rest, including location / { proxypass https://{IP}:{PORT}; proxysetheader Host $host; proxysetheader X-Real-IP $remoteaddr; proxysetheader X-Forwarded-For $proxyaddxforwardedfor; access_log off; } etc ...
3. The vhost is created by PLESK using the default template which does not include any location directives.
4. When the user chooses to use nginx the additional nginx directives field is populated by what would be generated by the template on save with some comment that removing this could result in his site not working.

5. Add a reset button to reset to initial configuration if the user messes up.

6. Similar to 2 but use 2 fields to store the information.

7. One field is a checkbox to enable or disable plesk's directives with a warning that the site might not load correctly.

8. A field to add custom directives so that the user can input his own configuration.

9. There should be a box or button to display the recommended configuration for the vhost

10. A reset button to the recommended configuration would be nice.

Let me know if you think something like this is achievable or why it can't be done. Thanks in advance for your efforts.