Search results

No problem there. Because I will never do anything "just in case" and I value the privacy of my customers very high. So even in Dutch cases they have got to have a good decent court order otherwise I won't do anything. And I won't do anything out of myself anyway either. I'm just a bit worried...

Yes but well.... problem is that emails are stored on the server so you can't say you don't have that. That is a wrong translation. It says "general data retention" and I know how governments work. So this means they can ask for specific data retention for example emails, just not general so...

Well I don't fully agree to that. You can see they can ask for content as shown in the quote in the first message. So I can't agree to the any extra, and as of yet I didn't find any "we don't have that info option" but I did see a "you are expected to provide that information by law once...

Well... I'm almost sure the csf=yes is added directly when they fully integrated it in DA. Before that, we had to install CSF manually and then you could have DA use custom scripts for example for the bruteforce integration. There was no csf= setting in DA at that time yet. That's the only...

Great, thank you for confirming, this will for sure help us and others if/when running in to the same issue. Thanks! (y)

Yes the hosters have to keep that in mind. It's warned 2 threads here about this situation could be a security risk. It's up to hosters to keep their 3rd party tools and configuration safe enough. The csf=no is a manual configuration setting, not a DA automated setting. So one should always be...

Well... you could try using the company phone number, that's also a means for fast contact, maybe they will accept that too.

As far as I understand it now, we only have to start working on this once we get a court order from some country. This order should provide the conservation time. Accessing content but not limited to customers email is a privacy violation for sure. So we can't do anything until we receive an...

Refresh the page or use another browser to be sure it's not browser cache. If not, then indeed somebody else is using the ip too and you have indeed to contact your data center.

I don't know, then you might have had it to csf=no for another reason. Anyway it's fixed now that's the most important.

So they both do DNS, Because multiserver mode is only kindlike a DNS backup, multiserver does not do anything else. But for sure this is a DNS issue somewhere. Doublecheck if all DNS records are correctly the same in the bind .db files of these domains on both servers. And if you're using...

Yes. It seems t-online.de changed their requirements again not too long ago. And now at this moment, they have the odd rule, that if you have an unwell configured mailserver (for example no correct PTR), have spammed, or even when you use an ip address which is not used to contact a t-online.de...

Probably you had this set to NO for some reason, maybe because you had SMTP_BLOCK=0 and had it that way to prevent this setting to be overwritten on a DA update. Da only updates CSF if the csf is set to yes in options.conf file.

Well the apache logs are not the most interesting as they are the easiest to save, that is not really a problem. It might also be the least interesting as this is visiting logs, not really something the user might be doing themselves. But the exim mainlog and maillog doe not contain any mails...

In the EU we have a new law called E-Evidence Regulation and Directive. The Regulation lays down the rules under which an authority of a Member State, in criminal proceedings, may issue a European Production Order or a European Preservation Order and thereby (directly) order a service provider...

Please use the "Like" button for thanking or acknowledging instead of upping an ancient post.

Yes one time, see answer above, next time please ask your hosting company as this forum is inteded for support to Directadmin license holders only, so admins and resellers. Not hosting customers. ;) Unless you're the license holder ofcourse. :)

Ah oke so if backtrace present than crash. So the stackdump line is not required. In that case only 2 of 4 servers had no issues because only 2 server I had no backtrace. Luckily I used the update, everything is running 4.98.2 now. I only see now from yesterday before I updated. Things look...

Maybe not all AlmaLinux versions or installations? I've got Alma 9 and do not have any stackdump lines or crashes when issueing that command. Not on any of our Alma 9 servers. Only have like this (if any) 2025-11-14 18:08:58 backtrace 2025-11-14 18:08:58 --- 2025-11-14 18:08:58...

This looks not good. Got error 'PHP message: PHP Strict Standards: Non-static method PEAR::setErrorHandling() should not be called statically in /home/homedir/domains/domain/public_html/webmail/program/include/iniset.php on line 122\n' [Fri Nov 14 02:23:07.668115 2025] [proxy_fcgi:error] [pid...