Mail Weiterleitungen funktionieren nicht

  • Ich verstehe ja, was 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

    eigentlich nicht; man sollte diese beide Paradigmen grundsätzlich vollkommen getrennt voneinander betrachten;

    (sämtliche Mechanismen die im Laufe der Jahre eingeführt wurden, sind ja genau deswegen eingeführt worden,

    weil es eben keine Hemmschwelle, technischen Barrieren, ... gibt auf die Art kriminelles zu veranstalten;

    mein Beispiel mit dem Brief und der Deutschen Post Briefmarke aber einer Absenderadresse aus Djibouti wird es nicht geben¹)


    bei der Wtrltngs.-geschichte gibt es eben aus diesem Grund folgende Punkte zu beachten:

    - die DKIM-Signatur darf nicht gebrochen werden

    - eine etwaige S/MIME-Signatur darf nicht gebrochen werden

    - dem SRS sei Dank, dass damit zwar SPF und dgl. glücklich sind, aber SPAM-Filter sollten hier schon sensibilisert werden,

    sobald da keine explizit bestellten Mailing-Listen im Spiel sind;


    von daher macht man das üblicherweise auch nur in die Richtung, als das Ziel etwas ist, was man selbst betreibt;


    ist das Ziel etwas, das man nicht selbst betreibt, die Mglkt. von der anderen Richtung - regelmäßiges Abholen per POP3 - in Betracht ziehen ...


    ¹ wer bewegt schon deswegen seinen Kadaver nach Deutschland um derartiges zu veranstalten?

    bzw. welchen sinnvollen Use-case gibt es f. derartiges?


    Nachsatz: nur weil es technisch möglich ist, ist es noch lange nicht die Pflicht es auch zu machen;

    spätestens beim Reply-To scheiden sich die Geister;

    meine Meinung dazu: wenn Dich als Absender die Antwort - genau deswegen hast Du ja das Reply-To im Mail gesetzt - nicht interessiert

    juckt mich Deine Mail schon gar nicht => if ( Mail has Reply-To ) then Reject-Mail;

    Grüße / Greetings

    Walter H.


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

  • mainziman Wenn ich Dich richtig verstehe geht es Dir also v.a. darum zu argumentieren, dass man grundsätzlich keine Weiterleitung nach extern verwenden sollte und dass man für Erklärungen keine Analogien aus anderen Technologien verwenden sollte, wenn sie nicht die gleiche ist. Beide Einschätzungen kann ich nicht teilen.


    Zum Punkt anschauliche Erklärung von Dingen: Es ging ja in Deiner ersten Erklärung, in der Du von max@max/moritz@moritz/moritz@gmail geschrieben hast um SPF. Alle anderen danach haben sich weiterhin nur auf SPF bezogen und man wunderte sich, warum es trotz -all geht. Dann schreibe ich einen Beitrag und versuche anschaulich SRS und warum im From immer noch der original Absender steht zu erklären, nachdem den Thread hier wohl seit Wochen keiner mehr interessiert und weil ich zufällig bei der Suche nach Probleme mit Weiterleitungen darüber gestolpert bin. Sollen die anderen urteilen, ob sie jetzt die offenen Fragen anhand meiner Analogie verstanden haben, oder ich sie hätten lieber stattdessen auf die technische Spezifikation verweisen sollen, weil man Deiner Meinung nach smail und email am besten nur vollkommen getrennt voneinander betrachten sollte.


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

    Du meinst, weil man es nicht für externe Adressen nutzen sollte? Diese Meinung teile ich nicht. Wenn Weiterleitung nur intern sein soll, dann sollte netcup wie es auch andere Vorredner geschrieben haben darauf hinweisen. Ich verstehe zwar all Deine Argumente, warum Du denkst, dass man Weiterleitungen nicht nehmen sollte, weil sie eben in der heutigen Welt schwierig im Handling sind. Aber Du liegst falsch mit der Annahme, dass sie eben nicht dafür vorgesehen sind. Vielleicht liest Du Dich mal ein. Da wirst Du auf Seite 5 lesen "bleibt die Weiterleitung ein unverzichtbares Feature von E-Mail". Auf Seite 4 steht das eigentliche Problem bzgl. DKIM und S/MIME - nicht das Weiterleiten an sich, sondern dass die MTAs auf dem Weg seit 25 Jahren die Mails beim Weiterleiten eben nicht nur weiterleiten, sondern auch im Inhalt verändern. Da DKIM und S/MIME aber den original Inhalt signiert haben und jede noch so minimale Änderung diese Signatur bricht, kommt es zu dem Problem.


    Du wirst sehen, dass man für sämtliche im Laufe der Jahre eingeführte Techniken, um Email vertrauensvoller zu machen, immer bemüht war, auch Lösungen für das Forwarding-Problem zu finden, weil Weiterleiten eben ein essentielles Feature ist.

  • jni verwechsle Relaying nicht mit Forwarding ...

    beim Forwarding generierst Du eine neue Mail und hängst die urspr. als Anhang dazu; (a)

    beim Relaying leitest Du diese an eine Poststation weiter ohne sie zu verändern; (b)


    und um bei Deiner Erklärung/Vergleich mit der realen Welt zu bleiben, das Beispiel mit Brief öffnen und in einem neuen Kuvert weitersenden entspricht eher dem (a) als dem (b)

    Grüße / Greetings

    Walter H.


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

  • Sorry, aber keiner redet hier von Forwarding und ich verwechsle auch nichts. Wenn Du Dich wirklich an einzelnen Wort so schön aufhängen kannst, dann schreib doch dem Autor des zitierten Artikels. Der hat es "Forwarding-Problem" genannt, sorry für die vergessenen Quotes.


    Schon mal .forward benutzt? Oder /etc/aliases? Da werden keine ursprünglichen Mails als Anhang angehängt, trotzdem heißt es .forward. Was Du meinst ist allein der Sprachjargon der MUA Welt. Und selbst die hängen Forwards nicht immer als Anhang an, sondern es gibt auch Inline Forwarding oder in meinem sogar ein Redirect, was dem Relaying entspricht:


    pasted-from-clipboard.png


    Wir reden hier alle ausschließlich von Relaying, auch im Beispiel. Ich verändere nichts am Inhalt der eigentlichen Nachricht. Wenn Du jetzt immer noch das Haar in der Suppe suchst, dann packt eben die Poststelle den Brief nicht aus, sondern nimmt ihn so wie er ist und packt ihn in einen neuen zusätzlichen Umschlag und schickt in weiter. Das wirst Du jetzt wieder als Attachment sehen, aber ein Attachment ist bei Email eine Inhalts-Aufteilung (Content-Type: multipart/...). Die Umschläge sind ganz außerhalb des Content.


    Wenn auch das nicht zählt und Du unbedingt darauf bestehst, dass man Relaying an der unveränderten Email erkennt: auch Relaying verändert eine Email - schon mal die Header nach dem Relaying angesehen?

  • Soeben nochmal getestet, wenn ich user1+user2@meinedomain.tld als Weiterleitungsadresse eintrage, dann kommt nur bei user1 eine Nachricht an. Also genau wie bei dir auch.

    Works as intended. Mailadressen sind user+box@domain.tld

    Also egal was hinter dem + steht, es wird alles an user ausgeliefert. Das hinter dem Plus kann zur Filterung benutzt werden. Damit kann man also unendlich viele Aliase benutzen die an den gleichen user gehen.

    War wohl eigentlich gedacht, dass wenn ein user verschiedene Mailboxen (Ordner) hat, dass man direkt in den Ordner zustellen kann. So ganz durchgesetzt hat sich das aber nicht.

  • Works as intended. Mailadressen sind user+box@domain.tld

    Also egal was hinter dem + steht, es wird alles an user ausgeliefert. Das hinter dem Plus kann zur Filterung benutzt werden. Damit kann man also unendlich viele Aliase benutzen die an den gleichen user gehen.

    War wohl eigentlich gedacht, dass wenn ein user verschiedene Mailboxen (Ordner) hat, dass man direkt in den Ordner zustellen kann. So ganz durchgesetzt hat sich das aber nicht.

    Zumal der Workaround im vorliegenden Fall wohl einfach ist. Einfach jede gewünschte Weiterleitungsadresse einzeln eingeben. Das ist in Zeiten von Copy&Paste noch nicht mal ein größerer Arbeitsaufwand ;).

  • Works as intended

    Ach je, wenn man von einem System umzieht und hatte dort anna+martin, das man als kompletten localpart interpretiert bekommen hat (da gab es anna allein auch und trotzdem hat anna+martin dahin nicht zugestellt), dann ist das gar nicht "intended" ;( Das Problem war also nicht, dass die Weiterleitungsadresse an anna+martin gind und der Workaround, dass man nun die Adressen von Anna und Martin einzeln als Weiterleitungsziele angegeben hat, sondern dass die Adresse selbst von extern benutzt wurde und nicht mehr an ihr komplettes Ziel kam, sondern nur bei anna ankam.


    Der Workaround dafür war, dass als Email-Adresse nun annamartin (gab es auf dem alten System nicht) eingerichtet wurde und unter dieser der Alias anna+martin. Interessant ist, dass es in diesem Fall dann nicht als "Filter" für anna interpretiert wird sondern es beim Ziel Hauptadresse landet. In den Headern sieht es dann so aus:

    Code
    X-Original-To: anna+martin@domain.tld
    Delivered-To: annamartin@domain.tld
  • Der Support hat mir sehr ausführlich geschrieben, dass man hier einem häufig gewünschten Feature der netcup Kunden nachgekommen ist, das sogar im Hostingpanel extra hinzugefügt wurde, da es dort nicht offiziell unterstützt war - Stichwort recipient delimiter in postfix bzw. allgemein auch address tagging. So haben User die Mögichkeit ohne neue Mailadressen anzulegen doch eindeutige Adressen in z.B. Web-Formularen zu verwenden.

    1. Auch wenn viele Kunden das wollten, es in der Oberfläche beim Anlegen von Mailadressen deutlich zu machen (v.a. weil das Delimiter-Symbol nicht + sein muss, sondern der Provider z.B. in postfix frei wählen kann) bzw. zumindest es in der Doku zu erwähnen hätte ich bei einer so expliziten Änderung des Hostingpanels erwartet. Aber was nicht ist kann ja noch werden.
    2. Ich habe jetzt noch keine Antwort auf meine Rückfrage, ob die Verwendung des + in einer Alias Adresse tatsächlich nicht als recipient delimiter interpretiert wird sonder erst in die Hauptadresse umgeschrieben wird und somit auch eine valide Lösung ist.
    3. Die vom Support vorgeschlagene Lösung war das Verhalten über das recipient delimiter Feature und einer Mailbox mit Sieve-Filtern zu lösen, also die Mailbox für den Teil vor dem + einrichten (anna) und dann in der Mailbox die eigentlich an anna+martin geschickten Mails auch noch an martin weiterzuschicken (redirect). Der Haken für mich: anna und martin bräuchten eigentlich nur eine Weiterleitung auf ihre Stamm-Mailbox statt einer weiteren hier, aber ohne Mailbox auch keine Sieve-Filter. Dann eben anna am besten gleich alles über Sieve-Filter abhandeln...
  • Ich habe jetzt noch keine Antwort auf meine Rückfrage, ob die Verwendung des + in einer Alias Adresse tatsächlich nicht als recipient delimiter interpretiert wird sonder erst in die Hauptadresse umgeschrieben wird und somit auch eine valide Lösung ist.

    In der Dokumentation des Postfix-Mailservers (der afaik bei netcup zum Einsatz kommt) steht dazu Folgendes:

    When a mail address localpart contains the optional recipient delimiter

    (e.g., user+foo@domain), the lookup order becomes: user+foo@domain,

    user@domain, user+foo, user, and @domain.

    Das müsste je nach Implementierung somit auch für virtuelle Aliase gelten. Ausprobiert habe ich das bei eigenen Servern jedoch noch nie.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Guter Hinweis. Aber so wie ich das lese, sagt die Doku dann doch etwas anderes, dass primär auch eine finale Adresse mit + möglich wäre und nur, falls dieser Lookup zu keinem Ergebnis führt man auch noch user@domain prüft. Dem ist bei netcup eben nicht so. Wenn ich allein user+foo@ egal als Mailbox, Weiterleitung oder beides definiere, aber user@ nicht definiert habe, landet die Mail nachweislich im Nirvana. Ist mir bei meinen Tests am WE aufgefallen und habe ich gerade nochmals mit neuen Adressen verifiziert. Zumindest das @domain (denke ich mal damit ist das catchall gemeint) sollte falls keine Ziel gefunden wird die Mail erhalten. Insofern könnte es doch ein Bug sein, die Mail muss ja irgendwo landen oder zumindest bounced werden und es könnte daran liegen, dass netcup es eben doch anders implementiert als in der postfix Doku beschrieben. Werde ich weiter verfolgen.

  • Und noch ein Debug-Ergebnis: schickt man mit eingeschalteter Weiterleitung an nicht definierte Adressen eine Mail z.B. user+foo@ und es sind weder user@ noch user+foo@ definiert, wird die Mail an meine catchall zugestellt. Also hier stimmt die lookup order lt. virtual wieder.