Ankündigung

Einklappen
Keine Ankündigung bisher.

Email-Weiterleitung zu GMail-Addresse unzuverlässig

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Email-Weiterleitung zu GMail-Addresse unzuverlässig

    Hallo zusammen,
    ich habe für eines meiner DF-IMAP-Konten konfiguriert, dass eingehende Mails auch an eine externe Mail-Adresse (in diesem Fall eine Gmail-Adresse) weitergeleitet werden. Grundsätzlich klappt dies auch - allerdings nicht zuverlässig. Regelmäßig kommen Mails nicht im Gmail-Account an (auch nicht im Spam-Ordner). Kennt dies jemand bzw. was könnte ich tun, um diesen Problemen aus dem Weg zu gehen?
    Grüße aus Hamburg


    #2
    Hallo almudy,

    Zitat von almudy Beitrag anzeigen
    Hallo zusammen,
    ich habe für eines meiner DF-IMAP-Konten konfiguriert, dass eingehende Mails auch an eine externe Mail-Adresse (in diesem Fall eine Gmail-Adresse) weitergeleitet werden. Grundsätzlich klappt dies auch - allerdings nicht zuverlässig. Regelmäßig kommen Mails nicht im Gmail-Account an (auch nicht im Spam-Ordner). Kennt dies jemand bzw. was könnte ich tun, um diesen Problemen aus dem Weg zu gehen?
    Für das beschriebene Verhalten könnten mehrere Möglichkeiten bestehen, wie z.B. die E-Mail wird als Spam erkannt und verworfen oder es greift hier die SPF-Prüfung, da die E-Mail nicht von der korrekten Absender-E-Mail-Adresse versendet wird. Generell besteht die Möglichkeit, dass durch die technische Abteilung eine Prüfung der Maillogs durchgeführt wird. Dazu benötigen wir eine authentifizierte Anfrage aus dem Kundenmenü (admin.df.eu) mit den folgenden Angaben:

    - Absender
    - Empfänger und Forwarder
    - Sendezeitpunkt nicht älter als 3 Tage, da sonst keine Logs mehr zur Verfügung stehen

    Blog - Facebook - Twitter
    Communitybetreiber: domainfactory GmbH
    Impressum / Pflichtangaben

    Kommentar


      #3
      Eine sinnvolle Option ist es auf jeden Fall die Weiterleitung mit den individuellen Mailfiltern und nicht den normalen Forwardern zu realisieren, das ist auf jeden Fall zuverlässiger.

      Kommentar


        #4
        Ich habe inzwischen das gleiche Problem. Liegt meiner Vermutung nach daran, dass immer mehr Sender DKIM verwenden und Googlemail dann denkt, dass der DF-Server die Mail "gefälscht" hätte.

        Ich habe mir damit beholfen, die Mails von Googlemail über good ol' POP3 abzurufen. Ist halt etwas langsamer.

        Kommentar


          #5
          Zitat von joernschellhaas Beitrag anzeigen
          Ich habe inzwischen das gleiche Problem. Liegt meiner Vermutung nach daran, dass immer mehr Sender DKIM verwenden und Googlemail dann denkt, dass der DF-Server die Mail "gefälscht" hätte.

          Ich habe mir damit beholfen, die Mails von Googlemail über good ol' POP3 abzurufen. Ist halt etwas langsamer.
          Nach unserer Erfahrung liegt es im Regelfall an fehlerhaften SPF-Einträgen. Da prüft Google seit einiger Zeit recht genau. Dazu gibt es noch weitere Threads hier, die das genau behandeln. Bei Fragen bitte gerne melden!

          Mit freundlichen Grüßen

          Nils Dornblut
          Blog - Facebook - Twitter
          Communitybetreiber: domainfactory GmbH
          Impressum / Pflichtangaben

          Kommentar


            #6
            Ja OK, hab nochmal nachgelesen und ausprobiert. War wohl eher SPF. Fehlermeldung sowas wie:

            Remote Server returned '554 5.0.0 <gmail-smtp-in.l.google.com #5.0.0 smtp; 550-5.7.26 The MAIL FROM domain [***] has an SPF record with a 550-5.7.26 hard fail policy (-all) but it fails to pass SPF checks with the ip: 550-5.7.26 [***]. To best protect our users from spam and phishing, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answ...authentication for more 550 5.7.26 information. ****** - gsmtp>'​
            Allerdings, so wie ich das Problem verstehe, kann daran keiner was ändern, außer DomainFactory, wo dann das Sender Rewriting Scheme aktiviert werden müsste.

            Ich habe mal eine Weiterleitung an anonbox.net gemacht, damit ich die "rohe" weitergeleitete Mail sehe (hab mal großzügig eventuelle private Daten durch * ersetzt):

            Code:
            From ***@googlemail.com Wed Sep 28 17:45:01 2022
            Return-Path: <***@googlemail.com>
            Delivered-To: b4ytn-***@b4ytn.anonbox.net
            Received: (qmail 50942 invoked by uid 0); 28 Sep 2022 17:45:01 -0000
            Received: from unknown (HELO mx16.ispgateway.de) (***.***.***.***)
              by anonbox.net with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 28 Sep 2022 17:45:01 -0000
            X-Envelope-to: ***@lmprod.de
            Received: from [***.***.***.***] (helo=mail-ej1-f45.google.com)
                by mx16.ispgateway.de with esmtps  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
                (Exim 4.94.2)
                (envelope-from <***@googlemail.com>)
                id 1odb7D-0004V4-AB
                for ***@lmprod.de; Wed, 28 Sep 2022 19:44:59 +0200
            Received: by mail-ej1-f45.google.com with SMTP id sd10so28735549ejc.2
                    for <***@lmprod.de>; Wed, 28 Sep 2022 10:44:59 -0700 (PDT)
            X-Google-DKIM-Signature: ******
            X-Gm-Message-State: ******
            X-Google-Smtp-Source: ******
            X-Received: by ****** with SMTP id ******;
                    Wed, 28 Sep 2022 10:44:58 -0700 (PDT)
            Received: from ?IPV6:******? (dynamic-******.c23.pool.telefonica.de. [******])
                    by smtp.gmail.com with ESMTPSA id ******
                    for <***@lmprod.de>
                    (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
                    Wed, 28 Sep 2022 10:44:57 -0700 (PDT)
            Message-ID: <******@LMProd.de>
            Date: Wed, 28 Sep 2022 19:45:08 +0200
            MIME-Version: 1.0
            User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
             Thunderbird/***
            From: =?UTF-8?Q?J=c3=b6rn_Schellhaas?= <***@LMProd.de>
            To: =?UTF-8?Q?J=c3=b6rn_Schellhaas?= <***@LMProd.de>
            Subject: Weiterleitungstest SPF
            Content-Type: text/plain; charset=UTF-8; format=flowed
            Content-Transfer-Encoding: 7bit
            X-Received-SPF: pass ( mx16.ispgateway.de: domain of googlemail.com designates ***.***.***.*** as permitted sender )
            X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
                spamfilter03.ispgateway.de
            X-Spam-Level:
            X-Spam-Status: No, hits=-6.6 required=9999.0 tests=BAYES_00 autolearn=disabled
                version=3.4.0
            X-Spam-CMAETAG: v=2.2 cv=****** c=1 sm=1 tr=0 a=******
            X-Spam-CMAECATEGORY:
            X-Spam-CMAESUBCATEGORY:
            X-Spam-CMAESCORE:
            
            Weiterleitungstest SPF
            Da ist jedenfalls nichts davon zu sehen, dass der SRS-Header gesetzt ist oder der Envelope-Sender geändert wurde, oder?

            Kommentar


              #7
              Zitat von joernschellhaas Beitrag anzeigen
              Allerdings, so wie ich das Problem verstehe, kann daran keiner was ändern, außer DomainFactory, wo dann das Sender Rewriting Scheme aktiviert werden müsste.
              SRS bieten wir nicht an und eine Implementierung ist nicht geplant aktuell. Im Regelfall ist das aber auch nicht zwingend erforderlich. Wollen Sie einmal testen, ob es mit ~all, also der Tilde statt dem Bindestrich, besser funktioniert? Alternativ passend den/die Server aufnehmen, ich bin hier noch weiter darauf eingegangen:

              https://forum.df.eu/forum/produkte/e...2332#post12332

              Da ich jetzt über den genauen Weg keinen kompletten Einblick habe, wenden sie sich bitte ansonsten über das Kundenmenü an die Technik und wir schauen uns das dann an.

              Mit freundlichen Grüßen

              Nils Dornblut

              Blog - Facebook - Twitter
              Communitybetreiber: domainfactory GmbH
              Impressum / Pflichtangaben

              Kommentar


                #8
                Hallo Herr Dornblut,

                danke für Ihre Antwort und die Infos zu der anderen Diskussion.

                Ich befürchte, Sie verstehen das Problem nicht richtig. Ich müsste ja den SPF-Record von der Domain vom Absender ändern, und das kann ich natürlich nicht (Der SPF-Eintrag von meiner Domain steht übrigens schon auf ~all).

                Vielleicht wende ich mich dann wirklich mal an die Technik. Aber es würde mich wundern wenn wir es ohne SRS zum Laufen bekämen.

                EDIT: Habe gerade den anderen Thread überflogen und möchte darauf hinweisen, dass es sich meiner Einschätzung nach um ein anderes Problem handelt, weil es dort um den einfachen Versand und hier um die Weiterleitung geht.
                Zuletzt geändert von joernschellhaas; 16.10.2022, 00:11.

                Kommentar


                  #9
                  Hallo joernschellhaas,

                  das mag durchaus sein, dass das Problem hier anders gelagert ist. Bitte daher gerne mal die Technik kontaktieren und gemeinsam nach einer Lösung suchen. Ergebnis dann gerne hier veröffentlichen. Bitte in der Anfrage möglichst klar aufzeigen, was für eine Kette bedient werden soll und wie die Weiterleitungen genau laufen.

                  Mit freundlichen Grüßen

                  Nils Dornblut
                  Blog - Facebook - Twitter
                  Communitybetreiber: domainfactory GmbH
                  Impressum / Pflichtangaben

                  Kommentar


                    #10
                    Die E-Mail-Weiterleitung mit imap-Konten ist immer eine Hit-and-Miss-Sache.

                    Kommentar


                      #11
                      Antwort vom Support (#DF-51878):

                      Ihre Annahme ist korrekt. Da bei der Weiterleitung der originale Absender verwendet wird, schlägt bei Google die SPF-Prüfung fehl sobald die Absenderdomain einen entsprechenden Eintrag gesetzt hat. Leider ist derzeit nicht geplant SRS bei uns einzuführen, wir bedauern. Eine Alternative um die Weiterleitung über uns zum funktionieren zu bekommen existiert leider nicht.
                      Wäre die Frage, ob/wie ich daraus einen Feature Request machen könnte.

                      Mein aktueller Workaround dazu ist, die Nachrichten von Googlemail über POP3 abrufen zu lassen. Aber Googlemail macht das nur einmal pro Stunde, das ist etwas unpraktisch bei Bestätigungsmails und sowas.

                      Kommentar


                        #12
                        Nils Dornblut , besteht die Möglichkeit eines Feature Requests?

                        Kommentar


                          #13
                          Zitat von joernschellhaas Beitrag anzeigen
                          Nils Dornblut , besteht die Möglichkeit eines Feature Requests?
                          Sie meinen für die Einführung von SRS? Ich spreche das immer mal wieder an, es ist aber leider so, dass das aktuell wenig Chance auf zeitnahe Umsetzung hat, wie schon von der Technik geschrieben. Tut mir leid, die Nachfrage danach gebe ich aber entsprechend weiter.

                          Mit freundlichen Grüßen

                          Nils Dornblut
                          Blog - Facebook - Twitter
                          Communitybetreiber: domainfactory GmbH
                          Impressum / Pflichtangaben

                          Kommentar


                            #14
                            Super, danke

                            Kommentar

                            Lädt...
                            X