Webhosting : EMail an Web.de nicht zugestellt

  • Hallo


    Ich nutze als Webhostingkunde den Webmailer von Netcup um EMails zu versenden.

    Leider werden meine Emails an Empfänger bei web.de nicht in das adressierte web.de Postfach zugestellt.


    Die Rückfrage beim Support ergab

    Quote

    Laut Maillog werden die Nachrichten allerdings ordnungsgemäß an web.de zugestellt. Wieso diese dann dort nicht weiter verarbeitet werden können wir leider nicht sagen.

    Dieser Aussage will ich folgen, obwohl ich das Protokoll selbst nicht einsehen kann (warum eigentlich nicht).


    Ein Test ob meine Domain auf einer Blacklist steht habe ich mit @mail-tester.com geprüft. Es gab 9/10 Punkten. Also erst einmal in Ordnung.


    Nun komme ich nicht weiter :(


    Jemand eine Idee?

  • 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.

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

    Da ist leider nichts. Ausserdem habe ich unterschiedliche Adressaten ausprobiert. Unter anderem mit meinem eigenen Postfach.


    Wenn Du möchtest, sende ich Dir einmal eine Testnachricht von meinem vServer.

    Das können wir gerne machen. 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. Wir werden sehen.

  • 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.

  • Sodale… :)

    Code
    1. warning: hostname mxf9ba.netcup.net does not resolve to address 2a03:4000:0:27f:a405:66ff:fecc:b49b: No address associated with hostname
    2. 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.

  • Gerade wurde eine meiner Testmails zugestellt, mit 2,5 Stunden Verzögerung.?(


    Received: from forward-relay.netcup.net ([94.16.123.254]) by mx-ha.web.de (mxweb111 [212.227.17.8]) with ESMTPS (Nemesis) id 1M25r9-1gBeev3C81-002VqO for <........@web.de>; Fri, 19 Oct 2018 20:21:44 +0200 Received: from mxf9ba.netcup.net (mxf9ba.netcup.net [46.38.249.186]) by forward-relay.netcup.net (Postfix) with ESMTPS id 381287F6E4 for <........@web.de>; Fri, 19 Oct 2018 17:33:03 +0200 (CEST) Received: from webmail01.netcup.net (unknown [46.38.249.153]) by mxf9ba.netcup.net (Postfix) with ESMTPA id F31A81202DA for <........@web.de>; Fri, 19 Oct 2018 17:33:02 +0200 (CEST)


    Glaube ich nun der Aussage des Supports oder liegt das Problem doch eher bei Netcup. :/:/

  • 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.

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

  • 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.


    Ich kann aber mangels Webhosting gar nicht mitreden.

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

  • 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.

  • Update:

    Einige Testmails wurden im Laufe der gestrigen Nacht zugestellt, teilweise mit mehr als 5 Stunden verzögerung.

    Code
    1. Received: from forward-relay.netcup.net ([94.16.123.254]) by mx-ha.web.de
    2. (mxweb012 [212.227.15.17]) with ESMTPS (Nemesis) id 1N5WLW-1fXOB10oPa-016xmj
    3. for <........@web.de>; Fri, 19 Oct 2018 22:41:45 +0200
    4. Received: from mxf9ba.netcup.net (mxf9ba.netcup.net [46.38.249.186])
    5. by forward-relay.netcup.net (Postfix) with ESMTPS id B70847F5F9
    6. for <........@web.de>; Fri, 19 Oct 2018 15:43:06 +0200 (CEST)
    7. Received: from webmail01.netcup.net (unknown [46.38.249.153])
    8. by mxf9ba.netcup.net (Postfix) with ESMTPA id 818E61208C4
    9. for <........@web.de>; Fri, 19 Oct 2018 15:43:06 +0200 (CEST)


    Ein Test heute morgen ergab eine zeitnahe Zustellung

    Code
    1. Received: from forward-relay.netcup.net ([94.16.123.254]) by mx-ha.web.de
    2. (mxweb012 [212.227.15.17]) with ESMTPS (Nemesis) id 1MrRIp-1fsT1b0Ush-00oSnA
    3. for <........@web.de>; Sat, 20 Oct 2018 09:11:28 +0200
    4. Received: from mxf9ba.netcup.net (mxf9ba.netcup.net [46.38.249.186])
    5. by forward-relay.netcup.net (Postfix) with ESMTPS id E4F427E70B
    6. for <........@web.de>; Sat, 20 Oct 2018 09:11:27 +0200 (CEST)
    7. Received: from webmail01.netcup.net (unknown [46.38.249.153])
    8. by mxf9ba.netcup.net (Postfix) with ESMTPA id AC33E120381
    9. for <........@web.de>; Sat, 20 Oct 2018 09:11:27 +0200 (CEST)

    Allerdings werden meine EMails im Gegensatz zu killerbees19 über forward-relay.netcup.net geleitet.


    Es ist schön, dass die Zustellung heute wieder funktioniert, aber vertrauenserweckend ist dies nicht. Wer kann sagen, wann es wieder nicht funktioniert. Und die EMails vom Mittwoch scheinen entgültig verloren.:(


    Vielleicht erhalten wir ja eine schlüssige Erklärung vom Netcup-Support oder von [netcup] Felix P.  

  • Ich habe aktuell auch das Problem, dass Mails erst teils einige Stunden später ausgeliefert oder empfangen werden.

    Der Support hat mir geantwortet, dass Emails ja nun auch kein "Echtzeitmedium" seien... :cursing:

    ...und mir wurde heute vom Support mitgeteilt, dass mehrere gleichzeitige Zugriffe abgeblockt werden - was bei 100 Mailadressen lt. meinem Webhosting und >20 Geräten bei (versucht) intensiver Nutzung sich in Richtung "nur 1x pro Tag je Mailadresse abrufen" bewegt. Das sind dann Lichtjahre von "Echtzeitmedium" entfernt und wird von dr Briefpost fast überholt....||:cursing:

  • Und wieder Verzögerungen beim versand zu web.de :(


    Für mich ist schon klar daß EMail kein Echtzeitmedium ist. Es gibt aber auch MTAs die dem Absender Rückmeldung geben, wenn's mal länger dauert.


    Mir ist wichtig dass nicht's verloren geht. Die Laufzeiten aus den 1980'er (FidoNet) dürfen es allerdings nicht mehr sein.


  • Für mich ist schon klar daß EMail kein Echtzeitmedium ist. Es gibt aber auch MTAs die dem Absender Rückmeldung geben, wenn's mal länger dauert.



    netcup wird die Email innerhalb von wenigen Sekunden an web .de los. Wenn dann müsstest du von web .de informiert werden, dass eine potentielle Email auf dich wartet.


    Der Grund wieso web .de das so lange intern verzögert, ist offensichtlich. Das ist eine billige Maßnahme zur Spamerkennung auf Kosten derer Kunden. "Realtime"-Spamerkennung mit aktuellen Signaturen kosten einiges an Geld. Wenn man nur aller paar Stunden aktuelle Spam/Malware-Signaturen braucht, dann bekommt man die für lau.