Search results

Have you tried just setting that CAA record? It's best practice anyway.

They wrote they have the backups on the server. Are they in /var/lib/psa/dumps/ on CentOS 7 too?

JFTR: Not necessarily. We had an email abuse incident when one of our users didn't have their mail client set to SSL only (shame on outlook for not having that as default). Some WLAN AP must have stolen the unencrypted login data.

However, nginx is rather fast doing that. Also keep in mind that a bot might retry if it doesn't get a 4xx error. This would really be a lot easier if plesk had a way to easily integrate varnish. We moved our main site to another server without plesk just so we could add varnish to our site and...

What does the log say?

Are you sure this will help? IMHO limiting the database server memory will only ensure that it definitely fails, which is not really helpful.

Keep in mind that proxying does not change the request. Which means, what 192.168.1.2 sees is still GET https://test.com/test.

How did you set that up? location blocks with proxy_pass?

Maybe for variables that can be set from the mariadb cli. Everything that would require a restart of the db server would have a risk of prolonged downtime for a rather small benefit.

The read access time on a hash table grows sublinear with size, but still grows. Write access - to insert new values - is significantly worse. Especially when you have many workers, which you do when every site connects to the same redis. And you usually want persistence for the session cache...

Do I see that right that you have just one redis? You should have a separate redis for each dataset. Especially if the cache is persistent, as redis will block while the cache is saved to disk.

After a plesk user is created by the mail setup, it shows up in "Users" on the left side. You would delete the plesk user there.

Could you try to send a mail to a domain that is on the relaying server? In that case, it would have to check DKIM, and it'd be very interesting how that turns out.

An extra Received: is normal. Are you sure that's everything that's changed? Any encoding issues, CR/LF conversions? Are you sure it doesn't replace the signature? Do the postfix logs say anything about DKIM? By the way, your plesk is ancient and it seems you don't have reverse DNS properly...

plesk does not change the way your linux distribution configures ip addresses, so you'd really need to look up your distribution's networking documentation.

What IP does google report, then? Does it belong to your vserver provider? Does your provider force smtp connections through a proxy?

Does the customer use a browser that has link prefetch enabled? (this is a big security risk when it prefetches links from 3rd party hosts)

Could you try to pick a mail from the exchange outgoing queue and compare to what it looks like after it went through postfix? Is plesk set up to use dkim for that domain?

That won't survive a reboot and therefore is just asking for trouble.

which view are you using? dynamic or active?