Posts by sutorinfo

    Es liegt im Verantwortungsbereich der Kunden, einen solche Vertrag vorliegen zu haben. Sie müssen ja auch beurteilen, ob du für diese Personenbezogene Daten verarbeitest. Es könnte durchaus passende Konstellationen geben, etwa wenn serverseitig keine pbD mitgeschrieben werden (IPs!!). Ich würde - falls dies dennoch geschieht (der Regelfall) - darauf hinweisen. Nimm Vergleiche anderer Provider aus dem Netz. Alle werden das anbieten. Denkbar ist auch, dass diese drei Kunden nur eigene Daten auf dem Rechner verursachen, etwa hinter einem geschützten Zugang.

    Hi @fulltilt


    interesting Application and good to have a community version of this opensource solution. In coming version (full rewrite!) it wants to be responsive. Roadmap for 2018 tells us improvements on version 6.x.


    Well, there are a lot of good webbased applications out there. Because its focus on security, privacy and federation I prefer nextcloud with may be far more options and features. But you are talking of an integration into i-mscp. Currently we have rainloop and roundcube as webmail solutions. Both with their advantages, well tested and sufficient as a fallback, if imap for any reasons fails.


    The developers team of i-mscp is very small. So I would be glad, if they can concentrate on the core of i-mscp. Lets have reliable and responsive software here. Or have an upgrade feature from within. Or present more system information. Anything else related to webadministration. Oh, yes, the multiserver thing :-)


    My suggestion for us as a community would be to fill a table telling us s. th. about the compatibility of these versions. Say Group-Office v6.3 is running on i-mscp 1.5.x without problems or some small tweaks or needs certain plugins.


    What do you think?

    Some thoughts of mine...


    The upcoming DSGVO (de) GDPR (en) will have implications on any website. And they are complex. Generally, in Germany we had a data protection law quite similar to the GDPR, but most small enterprises were very relaxed... With the new GDPR in most countries the law gets more strict and - more important - enforcement with high fines is intended.


    How are "we" doing now?


    First, GDPR affects as well B2C as B2B. In Germany most important is to fullfill those parts being detectable by robots first. That is the imprint and the declaration of data protection. Check any formula, control your data flows, SSL is mandatory for anyone!! So, the first steps to be taken are those by website owners. Just to mention: GDPR is not only valid for digital data procession, also your paper cards have to follow these paragraphs.


    Next part: Its for sure, that the IP belongs to the personal data. There are a lot others. There are few exemptions. E. g. those data necessary for the website to operate. IPs are such. Questions arise when going into the details. How long should an adress be saved? Can it be pseudnoymized/anonymized, is this allowed? To give you an impression: even soliciters have no common meaning, if saving for some days to allow fail2ban to work is allowed. There is already a great discussion on wordpress comments (but that's no imscp problem). As the whole intention of this law is data minimalism, everyone should ask himself: do I really need this data? For technical reasons (s. a.), for marketing reasons?


    For any data to be processed, you need the admission of the data owner. Another reason is to keep them for legal reasons. According to the law, we are no telecom providers, so we don't have to log access data.


    So, as the necessity for saving/deleting/anonymizing data derives from the client, opting in or out for such things should be implemented on a client level. Imagine there's a client providing a solution only for members having opted in for the logging of their IPs. This is defintively allowed, so this client should be able to log them via AWStats. Maybe a reseller/admin gets a switch for generally disabling this for all clients.


    Resellers: they should have a document signed with the admin called mandatory data processing (in de: Auftragsdatenverarbeitung). Also the clients mostly have to sign such a thing with resellers.


    Further on: Admins/Resellers should be able to answer the question, which personal data could be accessed by whome. By concept, the admin is able to see all client data of any reseller. For transparancy reasons the reseller has to tell this fact to his client or at least document this in his data processing list (in de: Verfahrensverzeichnis).


    Application related aspects: some developers already began to analyse their applications for GDPR-readiness. Even DNS: they discuss, which data should be requested from a domain registrant, which data should be presented for a whois request. We have bind on board. Access to the imscp panel, provided by a webserver: there is a limited number of clients who easily may opt in whereas a blog has outnumbered users, unwilling to have registered their visit.


    What could be a best solution:
    - document, where in imscp personal data are collected
    - who can see/change/delete them
    - which data originate from imscp purposes
    - which data originate from client applications / public website usage / standard server programs
    - which of these data are so open, that the user gets knowledge of them
    - which of these data are given because of technical reasons internally (e. g. apache log, mail log)
    - for which of the personal data is an anonymisation necessary, because there is no legal justification
    - where is there an interaction between imscp and other third party programs; which rules should be obtained in this case
    - ... some more?


    As said above: most important are all the data exposed to the public. Clients in the sense of impsp are public. Imagine a bad willing soliciter (they exist in Germany, because that's a profitable business model) will log in as client on an imscp administered system and is able to see personal data (visitors IPs)! This should be fixed first, even if we have to miss some functionality for some time. Data only visible for admins may be investigated and fixed later.


    In the long run this will be a subject for quite a long time. Heavy stuff? Just wait for E-Privacy next year which goes more into the details.


    Was this long comment helpful to you? Hope so :-)

    This is just a small report of my late experiences.


    After a long time I visited the demo site of i-MSCP, where you can log in as admin, reseller or user. Every 2nd or 3rd page couldn't be delivered. Cloudflare gave some information that s. th. went wrong, I should try a few minutes later. Then the page appeared. But still every now and than cloudflare came in between with its error message. The demo site itself seemed to operate correct.


    Just mention that, because I wanted to lead other people to i-MSCP and don't want them to drive away disappointed by reasons not in the responsibility of i-MSCP. Having a demo site is best to argument for our panel.


    Well, after all, this still could have been a regional/local problem or one of cloudflare not being connected good enough to my provider (vodafone).

    This "will follow..." was a bit too enthusiastic. Sorry for that. =O To investigate this behaviour I have to wait for an occurrence of this problem and examine three mail server logs. Something I currently have no time to do. Postponed into some future.


    Meanwhile I read this blogpost: https://www.heinlein-support.d…n-mail-rejects-durch-spf/


    This encoureged me to on first hand uninstall all SPF plugins, clear my DNS entries and stay with only DKIM and DMARC. If even myself on my own server can't ensure an overall working environment of SPF, I can't expect this from other admins. Only mailings between own servers where affected, not to think of bounced mails from other persons, which mostly remains unknown to me.


    A small niche for DNS entries remains. E. g. if there is an only internaly used subdomain where I don't want under any circumstances outgoing mail, I could add a "... -all". Also on a virtual server, where there is no domain at all affected with any of these SPF problems as e. g. mail forwarding, this may be activated.


    What's next?
    I will wait for some time and watch incoming mails. Are there any, which could have been bounced because of SPF usage? Are my own mails resent more and more often? Will other spam measurements keep their number small enough? If this will work, I will stay with this configuration.


    Hopefully my decision and the reasons to come to that one (part of my best practice) may help some of you :)