Mail Weiterleitungen funktionieren nicht

  • Hallo Leute,


    ich habe meine Domain gestern zu Netcup umgezogen (normales Webhosting-Paket). Jetzt habe ich aber bereits Probleme bei Mail-Weiterleitungen nach extern.

    Beispiel:

    Ich lege die Adresse test@meinedomain.de an. Deaktiviere in der Konfig "Zugriff auf Kunden-Panel" und deaktiviere außerdem "E-Mail-Postfach". Im Reiter Weiterleitung trage ich meine externe xyz@gmail.com/web.de/gmx.de Adresse ein und aktive "E-Mail-Weiterleitung einschalten". Danach 20 Minunten warten. Leider kommt keine Mail an :(

    Ich habe es auch mal mit aktiviertem "E-Mail-Postfach" versucht - hier landet die Mail im Netcup Posteingang, die Weiterleitung an die externe Adresse wird aber nicht ausgeführt.

    Außerdem habe ich auch mal eine interne Weiterleitung (innerhalb des Webhosting-Pakets) versucht - das funktioniert.


    Was habe ich falsch gemacht?


    Danke vorab für einen Tipp :)

  • Also abgesehen vom üblichen Hinweis, dass DNS-Änderungen schon mal bis 48 Stunden dauern können ... (die hier aber wohl nicht angebracht sein wird, weil die Mail bei aktiviertem Postfach auch in diesem Postfach aufgeschlagen ist) wüsste ich jetzt auch nicht. Ich habs gerade bei einem meiner Webhostings probiert wie oben von dir beschrieben. Ich habe keine 20 Minuten gewartet, eher zwei, danach wurde eine Mail von extern an die neue Mailadresse wie gewünscht zu GMX weitergeleitet und kam dort auch an. Mag aber auch serverspezifisch sein, vielleicht steht deiner gerade mal wieder auf einer öffentlichen oder GMX/GMail/web.de Blacklist.

  • ich würde hier meinen, dass etwas versucht wird, was eigentlich nicht vorgesehen ist;

    von welcher E-mail-Adresse versendest Du denn die Mail an die relaying Mailadresse?

    und ist der Mailserver von netcup überhaupt dazu befugt im Namen des eigentlichen Absenders zu senden?

    (SPF läßt grüßen)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • ich würde hier meinen, dass etwas versucht wird, was eigentlich nicht vorgesehen ist;

    von welcher E-mail-Adresse versendest Du denn die Mail an die relaying Mailadresse?

    und ist der Mailserver von netcup überhaupt dazu befugt im Namen des eigentlichen Absenders zu senden?

    (SPF läßt grüßen)

    Naja, das ist doch eine ganz einfache Mail-Weiterleitung, ist ja sogar explizit vorgesehen, dass man eingehende Mails an beliebig viele (ok, mehr als 100 würde ich aus anderen Gründen nicht versuchen ;)) E-Mail-Adressen weiterleiten kann.

  • Naja, das ist doch eine ganz einfache Mail-Weiterleitung

    genau das ist ja das Problem, wäre sie nämlich in der Art:


    man empfangt die Mail, generiert eine neue Mail und hängt die so empfangene Mail als Anhang dran, dann wärs wirklich kein Problem;


    nur das denke ich mal, dass nicht passiert;


    konkret: Du hast eine Mailadresse bei Gmail: z.B. moritz@gmail.com

    Du hast bei netcup eine Domain: z.B. moritz.de, und hast definiert dass

    alles was an moritz@moritz.de gesendet wird, an moritz@gmail.com weitergeleitet wird;

    und jetzt schicke ich von z.B. max@max.de an moritz@moritz.de


    wenn eine neue Mail generiert wird, dann ist diese tatsächlich von moritz@moritz.de an moritz@gmail.com

    und alles ist in Ordnung, dass aber der Mailserver von netcup im Namen von max@max.desenden darf glaube ich weniger ...

    sonst dürftest Du ja ohne Probleme Mails mit meiner Domain absehnden ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Keine Ahnung, wie das netcup - und alle anderen Webhoster, die ich kenne - machen. Es funktioniert jedenfalls. Meine Absenderadresse (nicht bei netcup) hat einen SPF-Record gesetzt, der den Mailserver des netcup Webhostings nicht abdeckt. Meine Weiterleitungsadresse bei GMX bekommt die weitergeleitete Mail trotzdem, mit einem Spam-Score von -0,65.

  • Weiterleitung heisst nicht, dass der weiterleitende Mailserver einfach die Mail nimmt und unverändert 1:1 an einen anderen Mailserver/E-Mail-Adresse schickt.

    Ich kann ja mal interessehalber meinen SP-Record entsprechend verschärfen, glaube aber kaum, dass das etwas ändern wird.

  • Hallo Leute,


    erstmal vielen Dank für die zahlreichen Rückmeldungen. Eine Mail-Weiterleitung ist im Prinzip ja nichts Kompliziertes. Die MX Einträge bleiben auf dem Netcup Server (keine Änderung an der Grundkonfiguration), die Verarbeitung/Weiterleitung soll ja vom Netcup-System durchgeführt werden. Jeder Freemail-Dienst unterstützt das.

    Auch der spf-Record des Absenders sollte egal sein. Der Mailserver des Absenders stellt zunächst an die Zieladresse zu. Ob die Mail dort im Storage landet oder an weitere Postfächer oder externe Adressen weitergeleitet wird ist ja für den Absender technisch egal.


    Bei den bisherigen Hosting-Anbietern hatte ich auch noch nie Probleme damit. Ich habe heute nochmals intensiv probiert. Größtenteils hat es nach etwas Wartezeit funktioniert, teilweise gibt es aber Verzögerungen von bis zu 30 Minuten bei der Weiterleitung. Ist der Empfängerserver ein Exchange Server hat es meistens nicht funktioniert.


    Da ich eine schnelle, zuverlässige Lösung gebraucht habe, habe ich die betroffene Domain kurzfristig wieder zu einem anderen Anbieter umgezogen. Dort haben die Weiterleitungen sofort nach Einrichtung funktioniert, die Zustellung an die Zieladresse erfolgt dort innerhalb von 2-3 Sekunden. Auch am Exchange kommen die Mails nun wieder zuverlässig an.


    Werde das die Tage mit einer Neben-Domain bei Netcup nochmals in Ruhe testen.

  • wenn eine neue Mail generiert wird, dann ist diese tatsächlich von moritz@moritz.de an moritz@gmail.com

    und alles ist in Ordnung, dass aber der Mailserver von netcup im Namen von max@max.desenden darf glaube ich weniger ...

    sonst dürftest Du ja ohne Probleme Mails mit meiner Domain absehnden ...

    Doch, ist aber tatsächlich so, dass der Endempfänger die Mailadresse des ursprünlichen Absenders sieht.


    In deinem Beispiel sieht moritz@gmail.com, dass er eine Mail vom max@max.de bekommen hat obwohl max@max.de die Mail eigentlich an moritz@moritz.de geschickt hat. Gerade nochmals getestet.

    Dementsprechend ist das auch als FROM: / TO: im Mail-Header zu finden. Die Weiterleitung wird aber im Abschnitt Received: angehängt/ersichtlich, ähnlich einem trace. Bei Netcup relayed dort das System "yourmailgateway.de", bei 1&1 z.B. "kundenserver.de". Vermutlich dürfte dort wohl auch das Problem bei Netcup liegen.

  • Also bei mir funktioniert es immer noch, trotz -all. Muss ja auch, ich kann doch als Hoster keine Mailweiterleitung zur Verfügung stellen, die nur funktioniert, wenn die Absenderdomain - auf die ich im Normalfall eher wenig Einfluss habe - nicht sicher konfiguriert ist. Falls doch, dann wäre die Funktion praktisch nutzlos. Ich sehe auch im Quelltext, dass die Headerzeilen sich deutlich von einer direkt empfangenen Nachricht unterscheiden. Bin da allerdings nicht tief genug drin, um das alles nachzuvollziehen. Trotzdem schicke ich morgen nochmal eine Mail per Weiterleitung, falls sich die Änderung im DNS jetzt noch nicht weit genug verbreitet hat. Die Zeit für die Weiterleitung liegt hier auch bei wenigen Sekunden zu GMX.


    Das ist auch meine einzige Adresse bei einem der größeren Anbieter und das auch nur aus historischen Gründen, weil es halt meine erste private E-Mail-Adresse war. Damals (tm) noch @eplus-online.de, wurde dann irgendwann zu @imail.de. E-Plus hat die ganze Mailgeschichte für seine Kunden aber relativ schnell wieder abgestossen und komplett an GMX übergeben, die haben dann Freemail-Adressen daraus gemacht, allerdings mit IMAP und anderen Dingen, die es zumindest damals bei GMX-Freemail nicht gab.

  • Also bei mir funktioniert es immer noch, trotz -all.

    Das wundert mich jetzt allerdings.

    Du hast das -all auch in den Records des ursprünglichen Versenders gesetzt?

    Denn eigentlich sollte -all genau das verbieten. Keine andere domain, als die Ausgangsdomain darf diese eMail verschicken. (Der Absender bestimmt mit dem spf-Record , wie mit der Mail zu verfahren ist) Ich weiß auch, dass das z.B. bei gmx mal eine Zeitlang der Fall war und es große Probleme gab gmx-Mails weiterzuleiten.

    Aber vielleicht beachten das einige Relays einfach nicht mehr oder schreiben die Header komplett um und leiten gar nicht mehr die ursprüngliche eMail weiter.

  • Das wundert mich jetzt allerdings.

    Du hast das -all auch in den Records des ursprünglichen Versenders gesetzt?

    Denn eigentlich sollte -all genau das verbieten. Keine andere domain, als die Ausgangsdomain darf diese eMail verschicken. (Der Absender bestimmt mit dem spf-Record , wie mit der Mail zu verfahren ist) Ich weiß auch, dass das z.B. bei gmx mal eine Zeitlang der Fall war und es große Probleme gab gmx-Mails weiterzuleiten.

    Aber vielleicht beachten das einige Relays einfach nicht mehr oder schreiben die Header komplett um und leiten gar nicht mehr die ursprüngliche eMail weiter.

    Ja, im DNS des ursprünglichen Versenders. Machen wir es mal anders, ich mach mir mal die Mühe die offensichtlichen Adressdaten unkenntlich zu machen und poste den relevanten Teil des Nachrichtenquelltexts


  • Das Stichwort ist Sender Rewrite Scheme (SRS) mit dem ein Weiterleitungsdienst die Mail umschreibt. Man muss auch beachten, dass From: und To: in Emails wie aus SPAMs bekannt auch nicht die verlässliche Information ist, von wem die Mail an wen geschickt wurde. Relevant dafür sind lediglich die im SMTP-Protokoll verwendeten Kommandos

    Code
    MAIL FROM:<absender@example.com>
    RCPT TO:<empfaenger@example.net>

    Die beiden Befehle spiegeln sich im Header von Emails als Envelope-From und Envelope-To wieder.


    Vergleichbar ist dies mit einem Brief (A4-Papier), auf dem schön von max@max.de an moritz@moritz.de steht und in einen Umschlag gepackt und zur Post gebracht wird, auf dem ebenfalls von max@max.de an moritz@mortiz.de steht. Dann sind hier der Umschlag und der Brief gleich adressiert.


    Wenn der Brief dann im Postzentrum von @moritz.de ankommt, packt ihn die Poststelle aus, schaut noch wo es im Hause hin muss und stellt fest, muss extern weiter geschickt werden. Ohne den A4 Brief zu verändern packt sie ihn so einfach wieder in den neuen Umschlag, den sie an moritz@gmail.com adressiert.


    Und jetzt kommt es eben darauf an, was die Poststelle auf den Umschlag schreibt, den sie zum Weitersenden verwendet. Wenn sie da wieder das From: aus dem A4 Brief nimmt hat sie ein Problem, denn jetzt kann der SPF von @max.de ja nicht wissen, dass die Poststelle von @moritz.de eine Mail mit einer Absender-Adresse @max.de versenden will, weil es ja im Original tatsächlich von @max.de kommt. Die finale Poststelle @gmail.com könnte also die Annahme der Mail nach Prüfung des max.de-SPF verweigern.


    Bedient sich hingegen die Poststelle von @moritz.de SRS, verwendet sie im MAIL FROM eine Adresse @moritz.de, für die sie sicher im SPF ja auch befugt ist. Es geht sogar noch einen Schritt weiter. Mit dem Rewrite wird zudem noch gewährleistet, dass wenn z.B. ein Zustellungsfehler auf dem weiteren Weg passiert, die Fehlermeldung auch an den original Absender wieder geht. Eine Envelope-From Adresse wäre deshalb z.B. SRS0=lvEZ=76=max.de=max@moritz.de, sie bewahrt den ursprünglichen "local part" (das vor dem @) und schickt mit der eigenen @moritz.de Domain. Bei einem Fehler schickt gmail.com an diese Adresse zurück, der Poststellen-Server von @moritz.de stellt denn ursprünglichen Absender wieder her und schickt dorthin die Fehlermeldung.


    In Deinen Headers sieht man an oberster Stelle im Return-Path eine SRS Adresse, dass also der Pfad zurück über die AdressederWeiterleitung geht. Somit alles in Ordnung. Aber das ist ja eine Email, die durch kam, also nicht das Problem darstellt.


    Warum klinke ich mich hier überhaupt ein: ich bin am Wochenende mit meinen Mails auch zu netcup und habe ein ähnliches Problem, aber leider nicht grundsätzlich sondern nur für eine Weiterleitung. Zumindest ist es bei der mir aufgefallen. Andere Weiterleitungen funktionieren nachweislich problemlos. Es ist auch so, dass die Weiterleitungsadresse in der eine Weiterleitung immer funktioniert, in der anderen nie. Es ist auch so, dass eine Weiterleitung (GruppeA@meinedomain) an Weiterleitung (meinefrau+ich@meinedomain) funktioniert, aber in der letzten dann nur meine Frau die Mail bekommt, meine Adresse wird nicht bedient, obwohl ich diese Adresse wie gesagt in anderen Weiterleitungen kein Problem hat. Und ob jetzt mehr als die eine Weiterleitung nicht funktioniert weiß ich nicht, ich kann ja nicht für jede Adresse in Weiterleitungen prüfen, ob sie eine Mail weitergeleitet bekommen hat.


    Hier wäre es sehr hilfreich zu wissen, was auf dem Server passiert, denn weder Warnings über eine delayed delivery noch Fehler kamen bisher von meinen Tests am Sonntag zurück. Eine entsprechende Support-Anfrage habe ich Montag Morgen bereits detailliert verfasst (inkl. Message-Ids), aber keinerlei Rückmeldung bekommen.

  • jni ich gebe Dir ein Lob f. die doch sehr gute Erklärung; einen Pferdefuß hat die aber;

    mit der richtigen klassischen Briefpost darf man was, was im digitalen mit Mailservern nicht geht,

    und es gibt hier Beschränkungen, welche es im digitalen mit Mailservern auch nicht gibt;


    die Postkästen, von welchen die Post die Briefe und anderen Plunder einsammelt um sie dann zu verteilen od. zu befördern (relayen)

    haben keine Einschränkung was den Absender anbelangt, lediglich was die Briefmarke angeht;

    in Postkästen der Deutschen Post dürfen nur Briefe eingeworfen werden, welche auch eine Briefmarke der Dt. Post

    kleben haben; aber Absender darf sogar einer aus Djibouti sein;


    Deine Problematik mit dem Weiterleiten ist quasi die gleiche wie sie auch die sogenannten Mailing-Listen haben;

    und das ist ehrlich gesagt die Königsdisziplin, denn von meinen abonierten Listen ist gerade mal eine in der Lage

    die Mail ohne sie zu Zerhäckseln bzw. die S/MIME-Signatur zu brechen weiterzuleiten;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • tab Danke für den Hinweis/die Idee, daran habe ich gar nicht gedacht, dass der Parser der Weiterleitungsadresse ein Problem haben könnte. Ist es aber nicht. Meine Weiterleitung heißt anna+martin@meinenetcupdomain.tld und die leitet an zwei Adressen weiter: anna.meinenetcupdomain@mailanbieter.tld und martin.meinenetcupdomain@mailanbieter.tld. Meine andere Weiterleitung ist verteilerliste@meinenetcupdomain.tld und die leitet an viele plus auch anna+martin@meinenetcupdomain.tld weiter. Weder Mails direkt an anna+martin@meinenetcupdomain.tld noch an verteilerliste@meinenetcupdomain.tld kommen bei martin.meinenetcupdomain@mailanbieter.tld an, nur bei anna.meinenetcupdomain@mailanbieter.tld. Eine andere verteilerliste2@meinenetcupdomain.tld sendet an ich@firma.tld und martin.meinenetcupdomain@mailanbieter.tld und hier kommen die Mails an beide Adressen an. Somit hat sich die Vermutung, dass nur der hinter Teil hinter dem + als localpart interpretiert wird nicht bewahrheitet.


    mainziman Ich verstehe ja, dass Du sagen willst, Weiterleitungen sind grundsätzlich ein schwieriges Thema, aber deshalb zu analysieren, wo ein grundsätzlicher smail/email Vergleich hinkt, ist doch nur das Haar in der Suppe zu suchen. Mein Erklärung sagt ja nicht, dass smail und email alles gleich machen, ich habe explizit eine Analogie aus der smail Welt gewählt, um die Funktionsweise von SRS und Weiterleitungen anschaulich zu erklären. Warum ich in diesem Thread überhaupt gelandet bin hat ja ganz andere Gründe, weil ich eben ein sich wohl wiederholendes Problem bzgl. Weiterleitungen bei netcup sehe, das nicht mit den grundsätzlichen Problemen von Weiterleitungen zu tun hat.


    Da ich selbst einen Weiterleitungs-Dienst für ein Forschungsnetzwerk betreibe, weiß ich sehr wohl, wovon Du schreibst. Und auch die neben meinem internen gegen Bezahlung gekauften Mailingslisten-Dienste für Externe sind nicht in der Lage, ohne Probleme an alle weiterzuleiten. Ich war schon im Netz unterwegs, da war das hier eine Newsgruppe und das Wettrüsten zwischen Missbrauch und sinnvoller, geschützter Nutzung bei Emails noch in den Kinderschuhen. Da konnte man mailman noch ohne Probleme auf jedem x-beliebigen Rechner am Internet betreiben, weil es keine Prüfung der Absender-Adresse gab. Es war wie in Deinem DP-Bsp. möglich einfach Djibouti als Absender zu verwenden.


    Und bzgl. Briefmarke: um im Internet Post verteilen zu lassen muss ich auch Wegezoll bezahlen. In Zeiten von UUCP war die Briefmarke erst dann gelöst, wenn man sich mit dem Internet kostenpflichtig verbunden hat. Und in Zeiten von Mailboxen gab es umgekehrt mehrere Anbieter für digitale Post und man musste die Briefmarke/Wegzoll richtig wählen, dass eine Nachricht zum richtigen Adressat kam. Aber jetzt zwischen den OSI Schichten zu springen wirst Du vermutlich auch nicht passend finden. Übrigens, in Zeiten meiner Jugend (auch wenn ich jetzt nicht super alt bin) mit FidoNet oder Maus oder Z-Netz war es übrigens umgekehrt und die DP der einzige nicht digitale Postverteiler in meinem Ort.


    Vergleiche/Analogien um etwas anschaulich erklären zu können lassen sich viele finden, aber ein Apfel (smail) ist ein Apfel und eine Birne (email) ist eben kein Apfel und man wird sagen können, "aber in dem und dem Punkt hinkt der Vergleich".

  • Bug für Weiterleitungen im Webhosting 2000 SE de a1 gefunden: hat man eine Mailadresse abc@example.com und eine weitere Mailadresse, die genauso beginnt und deren erstes Zeichen danach ein + ist, also z.B. abc+efg@example.com, dann wird zwar im Mail Header vermerkt


    X-Original-To: abc+efg@example.com

    Delivered-To: abc+efg@example.com


    aber tatsächlich wird die Mail an die Weiterleitung von abc@examplecom geschickt. Ich habe weiter Spielarten ausprobiert...


    1. Wählt man als Email-Adresse abcefg@example.com und definiert einen Alias abc+efg@example.com, dann funktioniert es korrekt.

    2. Es spielt keine Rolle, ob abc+efg@example.com eine Weiterleitung oder eine Mailbox ist, in beiden Fällen landet die Mail bei abc@example.com

    3. Der . (abc.efg) oder ein - (abc-efg) oder ein _ (abc_efg) als erstes Zeichen nach dem gemeinsame Teil des local parts führen zu einem korrekt zuordnendem Verhalten.


    Ich behelfe mir jetzt mal vorerst mit abcefg und abc-efg als Alias, aber das ist ein handfester Bug, der gehört eigentlich behoben.