Beiträge von antondollmaier

  • Postfix Whitelist smtpd_client_restrictions

    Zitat von kk

    Wir schauen uns die Postfix-Konfiguration mal an, mir schwebt da so was wie "/etc/postfix/blacklist-exceptions.db" vor, in die man dann (manuell) die auszunehmenden Mailserver eintragen kann.


    So ungern ich Ausnahmen pflegen und dadurch die Großen bevorzugen möchte (die definieren ja auch keine Ausnahmen für uns!) - auf das wird's rauslaufen müssen.

  • Postfix Whitelist smtpd_client_restrictions

    Zitat von kk

    [*]Ein Server, der auf einer Blacklist steht, wird grundsätzlich abgelehnt.
    Es ist nicht vorgesehen, einzelne Ausnahmen zu schaffen. Steht ein Server auf einer Blacklist, dann wird er auch an andere Mailserver nicht senden können - Ausnahmen verkomplizieren die Sache dann erheblich.


    Und genau hier sehe ich ... Diskussionsbedarf:


    - gerade die Mailserver der T-Online landen regelmäßig bei Spamcop auf der Liste. Ist ja auch legitim, wenn die Spam verschicken und damit automatisch gelistet werden.
    - Kunden beschweren sich dann aber, warum sie $Endkunde keine Mail an sie senden kann. "da kommt immer so ne komische Meldung!"
    - Die Erklärung "wenden Sie sich an T-Online, deren Server verschicken Spam" besänftigt die wenigsten, auch wenn das die einzig korrekte Antwort ist. Immerhin blockiert die T-Online ja auch rigoros alle Spamversender, und wenn es nur "ich will den Newsletter doch nicht haben"-"Spam" ist.



    Alles in allem keine leichte Abwägung.

  • Wishlist-Bug: ManageSieve

    Zusätzliches Flag am Postfach:


    (x) Autoresponder via LC
    ( ) eigene Sieve-Skripte


    Dementsprechend die Autoresponder-Funktionalität via LC steuern, respektive in Dovecot ManageSieve-Zugriff erlauben. Sollte ja über "deny.managesieve" lösbar sein.


    Die Einrichtung von ManageSieve an sich ist ja sowieso vollkommen schmerzfrei.

  • Kunde kann nicht gelöscht werden "Man möge erst alle Verträge löschen"

    Zitat von Internetsurfer

    Wenn ich nun den Kunden löschen will konnte der übliche Spruch: "Um diesen Kunden zu löschen müssen Sie erst alle ihm zugeordneten Verträge löschen."


    Bitte Logs prüfen.


    Der Fehler kann auftreten, wenn es Probleme bei der Verbindung zur Datenbank, dem Mailserver oder dem FTP-Server gibt. Dann bleiben nämlich Objekte zurück, so dass der Vertrag niemals gelöscht wird (sondern nur als gelöscht markiert war).

  • Possible bugs hostingplan, subscription, client account propagation

    Zitat von ñull

    Then I enabled the email in the hosting plan. This change did not propagate to the client account until I deleted the domain and recreated it. Now I don't know what is the expected behavior in this case. Should the change in the hosting plan propagate to the client domain? If so, then this could be considered another bug.


    IMHO, no: E-Mail can be disabled by the enduser on a per-domain basis, so in theory it would be possible to not have this activated.


    Instead, the user can then manually (or you) activate email for a certain domain under "domains".

  • PHP aktivieren, aber wie

    Zitat von RedDust

    Okay, aber wieso ist dann auf dem Webspace kein PHP aktiviert und wie aktiviere ich es :/


    FastCGI verwenden.


    Zitat

    /EDIT: apt-get install libapache2-mod-php7.0
    und es geht :D


    Ja, und damit gleich nen Haufen Sicherheitslücken - insbesondere kann Kunde A nun alle Daten von Kunde B lesen, die auch der Webserver lesen darf.


    Und nein, open_basedir nützt hier nichts.

  • Eu-dsgvo

    Zitat von kroerig

    aber im AWStats tauchen die vollständigen IP-Adressen auf. Da scheinen sich die Einstellungen nicht auszuwirken.


    Die Einstellung wirkt sich auf das Log-File ab Änderung aus. Vorher geschriebene Einträge sind natürlich nicht anonymisiert, weshalb dann auch AWStats nichts anonymisiert verarbeiten kann.

  • Emailversand zwischen den LC servern

    gut:


    Code
    Feb 21 17:26:05 web postfix/smtp[15172]: 8812365F98: to=<info@webaccount.de>, relay=none, delay=0.1, delays=0.05/0/0.05/0, dsn=5.4.6, status=bounced (mail for webaccount.de loops back to myself)


    Damit kann man arbeiten.


    Postfix kennt "webaccount.de" nicht, das passt also. Es wurde also in der Tat versucht, die Domain nach extern zuzustellen.



    Allerdings hat Postfix im DNS einen MX/A-Record gefunden, der wieder auf sich selbst verwiesen hat: bitte daher auf dem Server(!) die DNS-Resolv-Konfiguration prüfen und schauen, was für die Domain ("webaccount.de") tatsächlich als Antwort zurück kommt.

  • Emailversand zwischen den LC servern

    Zitat von Mogwais

    Ist das Verhalten generell ungewöhnlich?


    ja.


    Ich zitiere nochmal:


    Zitat

    Das Problem besteht darin wenn man per php (Konktaktformular uä), eine Mail vom Webserver an seine eigene Domain schickt verlässt die Mail nicht den Webserver sondern wird auf dem Webserver angelegt wo sie natürlich keiner abrufen kann.


    Ohne Logs kann man natürlich gar nichts prüfen, das ist hier also alles ganz allgemein gehalten.


    - server A hat Postfix. Keine virtual_domains. Hostname: servera.example.com
    - Server B dito (mit serverb.example.com), verwaltet aber auch virtuell die Mails der example.com.
    - PHP verschickt nun auf Server Amit mail() bzw. /usr/sbin/sendmail eine Mail. Empfänger: info@example.com.
    - wenn ServerA die "example.com" in mydestination hat, bleibt die Mail also lokal.
    - existiert "info" irgendwo als Postfach, so wird diese Mail lokal zugestellt.
    - existiert "info" nicht, so wird die Mail mit "unknown user" gebounced.



    Somit: Logs und konkrete Daten. Dann kann man genauer helfen.


    Wie gesagt: Postfix behält Mails nur dann für "sich", wenn es dafür konfiguriert wurde.

  • Emailversand zwischen den LC servern

    Zitat von Mogwais

    Postfix an sich musste ich aber installieren die Webaccounts dürfen ja Mails verschicken.


    Das Verhalten kann nur auftreten, wenn die Ziel-Domain auf Server B auch auf Server A im Postfix hinterlegt ist.


    Das kann viele Gründe haben - virtual_domains ist einer davon, myhostname/mydestination ein anderer.


    Welcher davon, können wir so weder erraten noch tatsächlich bestimmen.

  • cron.php.sh verwendet alte php.ini

    Um die Ausgangsfrage zu beantworten:


    Zitat von clickpress

    Ich muss mich auch mal hier reinhängen. Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.
    Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.


    Nein, tut es nicht.


    cron.php.sh macht nichts anderes, als die Session-Lifetime aus den vorhandenen php.inis auszulesen. Anhand dessen wird dann pro Kunde ein Find durchgeführt, um die Session-Dateien aufzuräumen.


    Ich sehe hier keinerlei Referenz in irgendeiner Art und Weise, die auch nur ansatzweise einen Zusammenhang zu IonCube oder Zend benötigen würde.


    Wenn ein Kunde(!) seine Cronjobs mit PHP-CLI benötigt, dann muss er so oder so den absoluten Pfad verwenden, der vom Provider vorgegeben wird. Diese Cronjobs, die der Kunde in der GUI konfigurieren kann, sind vollkommen unabhängig von einer Domain und somit auch unabhängig von der PHP-Version der CLI oder sonstwem.

  • cron.php.sh verwendet alte php.ini

    Zitat von clickpress

    Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.


    Es geht hier um die cron.php.sh von LiveConfig selbst, nicht um die Cronjobs der Verträge.


    Zitat

    Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.


    Die Cronjobs der Kunden/Nutzer müssen schon auch die richtige CLI-PHP-Version verwenden. LiveConfig ändert den Cron-Befehl nicht ab.


    Dieser ist auch unabhängig von jeglicher Domain-PHP-Konfiguration.