Search results

Okay, I think I know what happened: Starting with the upgrade to 18.0.49, plesk explicitly pins the pgp key for the plesk repositories: add line 'deb [signed-by=/etc/apt/keyrings/plesk.gpg] http://autoinstall.plesk.com/pool/PSA_18.0.49_10759/ bullseye all' to temporary source list...

Does the request even reach apache or does the pagespeed module in nginx deliver this?

well, taking that literally, I'd remove support for unencrypted POP3/IMAP and keep POP3S/IMAPS. Sending passwords over unencrypted connections is a huge security risk anyway, so the insurance companies aren't exactly wrong about this, they just could have worded that better ...

And btw, plesk still doesn't show dist-upgrades. /admin/pum/updates-list says All packages are up-to-date Checked on Mar 30, 2023 10:47 AM but apt-get upgrade says The following packages have been kept back: linux-image-amd64

Well, it doesn't. It supports x86_64. There seems to be some confusion about arch vs. os_arch. This is not a debian key issue however, but a plesk pgp key issue, as all the repositories involved are plesk's. Maybe a leftover from the botched grafana key update? It seems plesk itself messed...

This is a problem with mxtoolbox. They expect mail to be on a subdomain even though there is nothing in the relevant RFCs that would support such an requirement.

Just curious, what are you expecting to access at https://mail.example.com/?

Putting the relevant name(s) like webmail.domainA.com into the client's /etc/hosts or %WINDIR%\System32\drivers\etc\hosts works too.

Could it be that you have an automatic backup configured on the target that started during the migration?

Same here. Plesk seems to have updated normally at 6:35 as usual, but a manual Recheck now resulted in "The System Updates tool is already installing updates in automatic mode. Please try later." which is at least misleading. apt-get update shows a message similar to OP's but with the 1298 on...

I thought it uses rsync?

Clients will refuse to connect to imaps or pop3s when the certificate does not match or doesn't even exist, and you shouldn't ever connect without SSL because your password WILL be stolen that way.

If you don't have domain.tld on the plesk server (and you can't use workarounds like using sshfs to mount .well-known on the webserver), you'd have to create webmail.domain.tld as a domain in plesk to get it to set up Let's Encrypt. But that has all kinds of other problems ... The easiest way is...

How?

Well they would try to access subpages under that default page which do not exist, and get a 403. I have no idea why HEAD on / throws a 405, though. No, the HTTP protocol version is independent from SSL.

If you really want to speed things up, use varnish. However that is hard to integrate with plesk.

maybe the version without the extra headers is still cached somewhere?

Then, that default landing page is also what you (or the bots) get with HTTP/1.0.

Part of this looks like double-bounce spam: The spammer sends a mail to an intentionally malformed address The receiving server does not reject the mail outright like it should, but only figures out it is bad / should be discarded after the message was already accepted, therefore that server...

And what site did you set as default? (the site you get when you access the IP)