Beiträge von KB19

    Was mir erst jetzt bewusst wird: Warum willst Du überhaupt Empfängerdomains ("recipient") sperren? :/


    Dein Mailserver sollte sowieso nur für bekannte Domains zuständig sein. Andernfalls wäre er ein Open Relay und Dein Ansatz völlig verkehrt. Und ausgehende Mails solltest Du nur von authentifizieren Usern annehmen, dort würde so eine Filterung nur in sehr seltenen Fällen Sinn ergeben.

    Du kannst Deine Map mit postmap testen, ob sie richtig arbeitet.


    Du kannst Postfix nicht einfach eine MySQL-Map hin werfen, ohne weitere Aktionen. Suchst Du nach check_recipient_access?


    Unabhängig davon ist Dein Query komplett falsch. Du hast nirgends einen Vergleich auf die Domain. Du brauchst etwas wie: `adresse` = '%d'


    Keine Ahnung, ob dieser Artikel was taugt, aber der behandelt genau Dein Thema und sieht als Einführung vielversprechend aus: https://kitt.hodsden.org/blog/…ck_recipient_access_mysql


    Für weitere Informationen empfehle ich die Postfix Dokumentation. Gerade solche Sachen sind dort extrem gut erklärt. Und nachher weiß man wenigstens, was, wo, wie und warum so arbeitet.

    Spekulation: Forward-relay könnte in der Tat für forwarding reserviert sein. Mit Forwarding landet man ja schnell auf einer Blacklist, wenn das gegenüber aggressiver filtert.

    Das wäre auch nachvollziehbar und sinnvoll.


    Wenn die normal versendeten Mails aber ebenfalls darüber ausgeliefert werden, würde es die Zustellungsprobleme von 8bit eventuell erklären.

    Ich kann aber mangels Webhosting gar nicht mitreden.

    Ich kann es leider auch nur aus Sicht meines Mailservers beurteilen. Ein aktuelles Webhosting Paket habe ich nicht.

    Für den anderen Mailserver außerhalb des netcup Netzes habe ich (noch) keinen Test parat.

    Sieht auch dort nicht anders aus. Kein forward-relay zu sehen:

    Code
    Received: from mxf9ba.netcup.net (mxf9ba.netcup.net [46.38.249.186])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        by example.com (Postfix) with ESMTPS id DEFE620009
        for <user@example.com>; Fri, 19 Oct 2018 21:39:37 +0200 (CEST)
    Received: from webmail01.netcup.net (unknown [46.38.249.153])
        by mxf9ba.netcup.net (Postfix) with ESMTPA id 3C8F512037A
        for <user@example.com>; Fri, 19 Oct 2018 21:39:37 +0200 (CEST)

    Es bleibt also bei meiner vorherigen Aussage: Warum nutzt netcup das "forward-relay" auch für reguläre ausgehende Mails?


    (Danach sieht es jedenfalls aus anhand der gezeigten Header von 8bit)

    vmk Was mich nur etwas wundert, dass eine normale Mail vom Webmailer über forward-relay.netcup.net geht. Siehe Received-Zeilen von vorhin. Meinem Verständnis nach hätte das doch nur bei Weiterleitungen sein sollen, oder habe ich das falsch interpretiert?


    Das dürfte allerdings nur bei web.de (u.ä.) so sein. An meinen netcup VPS ging es direkt:

    Code
    X-Greylist: delayed 579 seconds by postgrey-x.xx at example.org; Fri, 19 Oct 2018 20:49:15 CEST
    Received: from mxf9ba.netcup.net (mxf9ba.netcup.net [46.38.249.186])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        by example.org (Postfix) with ESMTPS id 73AD72022A
        for <user@example.org>; Fri, 19 Oct 2018 20:49:15 +0200 (CEST)
    Received: from webmail01.netcup.net (unknown [46.38.249.153])
        by mxf9ba.netcup.net (Postfix) with ESMTPA id 069F312037A
        for <user@example.org>; Fri, 19 Oct 2018 20:39:28 +0200 (CEST)

    Für den anderen Mailserver außerhalb des netcup Netzes habe ich (noch) keinen Test parat.

    Siehe auch mein vorheriger Beitrag. Irgendwas ist dort bei IPv6 suboptimal konfiguriert, soweit ich das beurteilen kann. Ob das etwas mit dem ursprünglichen Problem zu tun hat, weiß ich nicht.


    EDIT: Bezüglich dem forward-relay Teil: Offenbar verschickt netcup Nachrichten an web.de über einen anderen Ausgangsserver. Dieser Hop taucht bei Nachrichten an meinen Server nämlich nicht auf.

    Sodale… :)

    Code
    warning: hostname mxf9ba.netcup.net does not resolve to address 2a03:4000:0:27f:a405:66ff:fecc:b49b: No address associated with hostname
    
    NOQUEUE: reject: RCPT from unknown[2a03:4000:0:27f:a405:66ff:fecc:b49b]: 450 4.7.25 Client host rejected: cannot find your hostname, [2a03:4000:0:27f:a405:66ff:fecc:b49b]; from=<user@example.net> to=<user@example.org> proto=ESMTP helo=<mxf9ba.netcup.net>

    Das war der erste Versuch des Webhosting Servers über IPv6: Sieht so aus, als ob für mxf9ba.netcup.net kein passender AAAA-Record existiert. Das ist schon einmal gar nicht gut und höchstwahrscheinlich eine Sache für den netcup Support. Du kannst gerne den Link zu diesem Forenbeitrag einmal hinsenden.


    Über IPv4 ist Deine Testnachricht dann übrigens angekommen.

    Ich glaube aber dass dies funktionieren wird, da der Netcup Support ja auch in der Lage ist mir auf meine web.de Adresse zu antworten.

    Gutes Argument.


    Du solltest zwei Mails bekommen haben und kannst mir gerne auch mal vom Webhosting eine zurück senden. Der web.de Server hat sie zumindestens erfolgreich angenommen.

    Auch wenn es lächerlich klingt: Schon im Spamordner nachgesehen? (Sofern Du dort ein Postfach zum Testen hast.)


    Würde mich nicht wundern, wenn web.de mittlerweile auch Mails verschluckt. Stichwort Blackhole bei Microsoft und Gmail. Dort kommen die Nachrichten auch nachweislich an, nur nicht im Zielpostfach...


    Wenn Du möchtest, sende ich Dir einmal eine Testnachricht von meinem vServer. Einmal bei netcup und bei Bedarf einmal von woanders. Den dazugehörigen Logauszug übermittle ich Dir danach gerne. Bei Interesse bitte die Zieladresse von web.de als Private Nachricht senden. So könnte man wenigstens einmal generell abklären, was alles nicht ankommt oder wie sich der Zielserver verhält.

    Tritt das Verhalten auch bei simplen Hello-World-Scripten auf? Statische Sachen (ohne PHP) werden zügig ausgeliefert?


    Mit Konfiguration meinte ich alles, was nicht auf den Defaultwerten steht. Vor allem Dinge wie rDNS-Lookups und wie PHP im Detail angesprochen wird.

    […] oder geschwärzte Gesichter bei Kindergarten Gruppenfotos.

    Ohne direkten Bezug zu dem geschilderten Fall: Und ungefragt Klassenfotos inkl. Namen sogar im Internet zu verbreiten ist in Ordnung? Das war jahrelang Standard im schulischen Bereich und mMn höchst fragwürdig. Stayfriends usw. ist auch ein Paradebeispiel, wo Fotos von irgendwelchen Personen inkl. Namen landen.


    Ich finde die DSGVO in vielen Bereichen ebenfalls übertrieben, dennoch bringt sie endlich einmal frischen Wind in manche Diskussionen, die bisher nicht ernsthaft geführt wurden.

    Steht dort wirklich ein Rautezeichen am Anfang der ersten Zeile, die verschluckt wird? Dann wird es eventuell als Shebang interpretiert und dementsprechend heraus gefiltert: https://de.wikipedia.org/wiki/Shebang


    Bitte teste es nochmals mit einem anderen Inhalt. Das unterschiedliche Verhalten lässt sich eventuell dadurch erklären, dass PHP bei den getesteten Systemen anders eingebunden ist. (mod_php, CGI, FastCGI, FPM, …)