Recent content by iainh

Many thanks @Kaspar for your time, thoughts and advice :) Yes, I get that fail2ban is dynamic and have that locked down (maxretry = 3) to help limit things, but there is also the fail2ban 'plesk-permanent-ban' jail, although that is an all ports, TCP and UDP total ban, but you could create...

I am looking to remove some of the noise and brute force attempt from the maillog and would appreciate people's thoughts and experience. There seem to be three options: 1. The Plesk firewall 2. Fail2ban 3. AbuseIPDB Plesk firewall The firewall (iptables) allows me to be specific and so I...

@TorbHo, set your DMARC policy to none or quarantine, then send a message to another mail service (which should be delivered with a DMARC policy of 'none') and inspect the header. As @Sebahat.hadzhi said, you likly have a domain conformance failure, probably due to you setting the 5322.From...

Ah ... I knoew it. As soon as I post, I'll find the fix... I recall in the rapid migration, SpamAssin is no longer availe and I presume has been incorporated into Plesk Email security. I therefore looked at Warden Anti-spam and Virus Protection, but didn't go through with licensing it. All has...

Mail stopped being delivered on our Plesk server in the early hours of this morning with: Looking through KB articles, I have... Restarted Dovecot and Postfix milter and SMTP via Tools & Settings > Services Management and requeued all mail ... failed Restarting amavisd and postfix and...

I can confirm, cert rotation with wildcard deselected now goes not only without challenge, but oh so quickly. You have just saved me a bunch of time. Thank you so much @Kaspar :cool:

Hi @Kaspar ... so it is the wildcard option that triggers the _acme.challenge update at every cert rotation? If that's the case, it will save me a lot of hassle. Plesk/SSL It! like to 'encourage' including the wildcard option, but if ignoring this removes the need for TXT record update each...

I have been trying all manner of things @mow :) What's more, I have some interesting findings and questions for Plesk... I have indeed set CAA for the various domains, however, and yes as a CISO I recognise you 'best practice' point, CAA are not required and both these 'problem subscriptions'...

This issue is back and looking for anyone reporting this issue I find my own post :rolleyes: What I notice is that I mention two subscriptions having this 'checking CAA' error ... both for domains that have no CAA and never have. I also see I said... Well, the same 1+5 subscription is back to...

This is maybe relevant... Type: urn:ietf:params:acme:error:caa Status: 403 Detail: Error finalizing order :: Rechecking CAA for "www.sprakekingsley.org.uk" and 14 more identifiers failed. Refer to sub-problems for more information Why relevant? Well, the request is for the root and wildcard...

Just to add to the thread, but not expecting a magic answer, other subscriptions on the same host all update okay, even now, one that was suffering the same 'urn:ietf:params:acme:error:caa' 403 error. Trying to work out what is the key issue, although I cannot see why one that was failing, is...

Many thanks Peter. Yes, I understand a 403, but it's not just "can't access", but is being forbidden .. it's a 403, not a 404. I'll have a look at the logs and maybe put a tail on while an attempt to reissue is running in the hope of seeing what it is that's being attempted and denied.

Hi Peter, no, nothing in front and Nginx disabled just to rule that out. No, DNS is not managed by the Plesk service and yes I know where the autorotative DNS are and it all been working for years. Yes I have checked the DNS for all names and one idea I followed was a misreading of an wildcard...

Just to add to my own thread... I took the smaller 1 + 5 domain subscription I de-selected all the additional domains and tried again ... it still failed I then de-selected wildcard and when to domain and www.domain options only ... it worked! ... however... While the 'domain + www only' v...

There seems to be numerous items about: Details Invalid response from https://acme-v02.api.letsencrypt.org/acme/finalize/356300830/211673632166. Details: Type: urn:ietf:params:acme:error:caa Status: 403 Detail: Error finalizing order :: Rechecking CAA for "example.com" and 18 more identifiers...