Beiträge von tbc233

    Danke Dir. Möglicherweise haben sich jetzt unsere Postings überschnitten. Konnte inzwischen einiges eingrenzen.


    Zusammengefasst die Erkenntnis:

    Die Weiterleitungsdatei wird angelegt wie geplant. Sobald ich die erste Zeile (...forward_filter) entferne, funktioniert die Weiterleitung.
    Mit dieser Zeile funktioniert sie wie beschrieben nicht.

    Ich wurde grad nochmal schlauer. Wenn ich die erste Zeile (die mit dem filter) aus so einer Weiterleitungsdatei entferne, funktioniert es perfekt. Inklusive umschreiben des Headers auf SRS


    Code
    1. |/opt/pdadmin/bin/srs_forward.pl zieladresse@beispiel.com

    Funktioniert.


    Code
    1. |/opt/pdadmin/bin/forward_filter
    2. |/opt/pdadmin/bin/srs_forward.pl zieladresse@beispiel.com

    Funktioniert NICHT.

    Es muss etwas mit dem SRS Mechanismus zu tun haben (für den ich sonst ja recht dankbar bin, erspart er uns doch eine Menge Probleme bei Weiterleitungen in Zusammenhang mit SPF).


    Der eigentliche Inhalt von einer .qmail-blablabla Weiterleitungsdatei sieht ja zum Beispiel so aus


    Code
    1. |/opt/pdadmin/bin/forward_filter
    2. |/opt/pdadmin/bin/srs_forward.pl zieladresse@beispiel.com


    Wenn ich nun aber mal testweise die beiden Zeilen wegschmeisse, und nur die Zieladresse eingebe, dann funktioniert die Weiterleitung.

    Danke Dir, den Fehler können wir vermutlich streichen, der ist nicht wieder aufgetaucht, auch nicht nach einem Reboot. Das File ist auch bei mir vorhanden und die INC Pfade stimmen.


    Allerdings verzweifle ich langsam. Die Mailqueue füllt sich mit lokalen und externen Weiterleitungen. Und ich bin immer noch nicht schlauer.

    Danke. Ist BTW ebenfalls ein Centos 7.


    Keine Hinweise in den Logs, Was mir noch aufgefallen ist in /var/log/messages taucht anscheinend nach jedem Boot auf:


    Code
    1. Jan 14 13:15:06 nemo smtpd: 1547468106.020902 PLEASE SEE THE PERL2EXE USER MANUAL UNDER "Can't locate somemodule.pm in @INC"
    2. Jan 14 13:15:06 nemo smtpd: 1547468106.020936 Can't locate Net/DNS/RR/AAAA.pm in @INC (@INC contains: /opt/pdadmin/lib PERL2EXE_STORAGE /opt/pdadmin/bin /opt/pdadmin/lib) at (eval 10) line 3.

    Ich weiß aber leider nicht ob hier ein Zusammenhang besteht.

    Das einzige was das log hergibt:


    Code
    1. Jan 14 14:25:34 servername qmail: 1547472334.891281 starting delivery 23: msg 638174 to local sebaxabh-domain.com-karl@domain.com
    2. Jan 14 14:25:34 servername qmail: 1547472334.891294 status: local 2/10 remote 0/20
    3. Jan 14 14:25:34 servername qmail: 1547472334.897592 delivery 23: deferral:
    4. Jan 14 14:25:34 servername qmail: 1547472334.897615 status: local 1/10 remote 0/20


    Das Problem besteht ebenfalls bei lokalen Weiterleitungen, habe ich gerade bemerkt. Also nicht nur bei externen.

    Hab eben einen neuen Server aufgesetzt mit pd-admin v4.60 und Serverumgebung 4-0.325.


    Soweit funktioniert alles, aber ein sonst harmloses Thema bereitet mir Kopfverbrechen: Eingerichtete Mail Weiterleitungen an externe Adresse tun nicht.


    anonymisiertes Beispiel: eingerichtete Weiterleitung karl@domain.com an die externe Adresse karl-irgendwer@gmail.com

    - Mail wird angenommen, ich sehe im Log den lokalen Zustellversuch

    - Das wars, mehr ist in den Logs nicht zu sehen.


    Mail bleibt in der Queue, sehe es auch zum Beispiel mit /var/qmail/bin/qmail-qread. Es gibt auch immer wieder weitere Zustellversuche. Aber die Weiterleitung erfolgt nicht, Logs geben keine weitere Infos her, auch keine Fehlermeldungen.


    Ich glaube es könnte hier irgendwas mti dem SRS Mechanismus nicht stimmen, aber mir gehen den Ideen aus, wo ich noch suchen könnte.


    Jemand eine Idee?

    Soweit ich der netstat Ausgabe entnehmen kann, läuft lediglich der Webserver nicht. Die restlichen Dienste offenbar schon. Das wird einen Grund haben, warum der nicht hoch kommt.


    Schau mal in die Prozessliste mittels "ps aux" ob da httpd Prozesse laufen. Vermutlich nicht.


    Dann würde ich an Deiner Stelle mal händisch den apache neu starten. Deinen Ausgaben entnehme ich, dass Du apache2.4 einsetzt, also probier folgendes:


    zuerst sicherheitshalber:

    /usr/local/pd-admin2/httpd-2.4/bin/apachectl stop


    Anschließend

    /usr/local/pd-admin2/httpd-2.4/bin/apachectl start


    Achte darauf ob es hier irgendwelche Ausgaben gibt und check danach nochmal /usr/local/pd-admin2/logs/error_log

    Ich würde vorschlagen, das "X-Powered-By: PHP/version" generell standardmäßig abzudrehen. Ich mach das momentan immer händisch in den php.ini's (expose_php auf off)


    Es bringt nicht wirklich was und ladet nur Kiddies oder Schwachstellen-Scanner zum rumspielen ein, insbesondere bei älterern Legacy Versionen.

    Was mir grad noch einfällt und vermutlich wichtiger für den Threadstarter ist:

    Ich empfehle NICHT einfach so zu kündigen, es sei denn die Domain ist Dir nicht so wichtig. Lass Dir lieber den Auth-Code der Domain geben, damit kannst Du ausfallslos und relativ unbürokratisch mit der Domain zu einem anderen Anbieter wechseln. Und das ganze sicherheitshalber VOR der Kündigung.


    Wenn Du kündigst und die Domain aufgelassen wird, dann kann einerseits je nach Registry die Domain möglicherweise einige Wochen nicht neu registriert werden. Und wenn sie wieder registrierbar ist, ist die Chance immens hoch dass sich ein Domaingrabber drauf wirft.

    Bei Angabe von Hostnamen im DNS muss am Ende ein Punkt gesetzt werden. Das DNS ist Hierarchisch aufgebaut und der letzte Punkt zeigt das root Level an.

    Das stimmt natürlich vollinhaltlich. Die Tatsache, dass es aber bei vielen Webinterfaces / Kundenbereichen etc. nicht nötig ist, den Punkt einzugeben (oder schlimmstenfalls sogar zu einem Fehler führt, weil der Punkt ohnehin intern angehängt wird), ist für Neulinge oft verwirrend und hält mich davon ab, dies als generelle Regel zu kommunzieren wenn mich wer fragt.

    Korrekt. Wobei Cloudns (oder externe DNS Anbieter allgemein) hier nur ein Vorschlag am Rande war. Ich bin immer noch der Meinung, dass bei Strato eigentlich Wildcard * Einträge möglich sein sollten.

    Wenn man am Server frei über Subdomains verfügen will, ohne jedes Mal einen DNS Eintrag machen zu müssen, ist es nicht unvernünftig einen wildcard Eintrag zu machen. Also


    *.domain.tld. IN A ip-adresse


    Damit zeigt jede beliebige Subdomain auf die IP. Die genaue Schreibweise kann sich hier je DNS Interface unterscheiden, sollte sich aber erschließen wie man das einträgt.


    Blöd wirds allerdings, sollte Strato solche Wildcard Einträge nicht erlauben. Dann würde ich mit der Domain umziehen.


    Ergänzung:

    Oder Du besorgst Dir eine externe DNS Verwaltung und trägst andere DNS Server in die Domain ein. Ich erlebe cloudns.net als sehr empfehlenswert. Da sind dann auch die Einträge nicht limitiert.