Ankündigung

Einklappen
Keine Ankündigung bisher.

Werden "interne" E-Mails kommentarlos verworfen?

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

    Werden "interne" E-Mails kommentarlos verworfen?

    Hallo zusammen!

    Ich habe bei DomainFactory eine Domain example.net mit dem Paket ManagedHosting Professional.

    Catch-All ist für diese Domain deaktiviert. Wenn ich "von außen" (also etwa mit Gmail) eine E-Mail an eine nicht existente Adresse [email protected] schreibe, erhalte ich erwartungsgemäß innerhalb weniger Sekunden eine Unzustellbarkeitsnachricht:

    554 Sorry, no mailbox here by that name.
    Völlig korrekt soweit. Wenn ich nun aber über per https://webmail.df.eu/ und Login etwa als [email protected] an dieselbe nicht existente Adresse [email protected] schreibe, erhalte ich keine Unzustellbarkeitsnachricht. Vielmehr scheint die E-Mail kommentarlos verworfen zu werden! Mit Thunderbird und K-9 ist das Ergebnis dasselbe; auch macht es offenbar keinen Unterscheid, ob ich sslout.df.eu oder smtprelaypool.ispgateway.de als SMTP-Server verwende.

    Also das kann's ja wohl nicht sein! Ist dieses Problem bekannt?

    Viele Grüße
    Christoph

    #2
    Ich habe versucht, dein Problem nachzuvollziehen, bekomme jedoch richtigerweise folgende "Bounce-Mail":
    Code:
    This message was created automatically by mail delivery software.
    
    A message that you sent could not be delivered to one or more of its
    recipients. This is a permanent error. The following address(es) failed:
    
    [email protected]
        host mxlbrelaxed.ispgateway.de [80.67.31.54]
        SMTP error from remote mail server after RCPT TO:<[email protected]>:
        554 Sorry, no mailbox here by that name.
    
    
    
    Reporting-MTA: dns; smtprelay01.ispgateway.de
    
    Action: failed
    Final-Recipient: rfc822;[email protected]
    Status: 5.0.0
    Remote-MTA: dns; mxlbrelaxed.ispgateway.de
    Diagnostic-Code: smtp; 554 Sorry, no mailbox here by that name.
    
    
    
    Return-path: <[email protected]>
    Received: from [134.119.228.2] (helo=webmail.df.eu)
        by smtprelay01.ispgateway.de with esmtpa (Exim 4.92.3)
        (envelope-from <[email protected]>)
        id 1jslfN-0004KI-M5
        for [email protected]; Tue, 07 Jul 2020 13:21:37 +0200
    MIME-Version: 1.0
    Content-Type: text/plain; charset=US-ASCII;
     format=flowed
    Content-Transfer-Encoding: 7bit
    Date: Tue, 07 Jul 2020 13:21:37 +0200
    From: [email protected]
    To: [email protected]
    Subject: Test an nix
    Message-ID: <[email protected]example.net>
    X-Sender: [email protected]
    User-Agent: Roundcube Webmail
    X-Df-Sender: akBuMTVyLmV1
    In meinem Fall verhält sich das System also wie erwartet.

    PS: Statt [email protected] und [email protected] habe ich natürlich eine meiner real existierenden Domains bzw. Mailadressen verwendet ;-)

    Kommentar


      #3
      Moin,

      ich habe es vorhin und gerade nocheinmal auch ausprobiert und bei mir fehlt der Bounce, wenn ich an eine nicht existierende Adresse einer meiner Domains schreibe (also wie im Ausgangsposting). Gut finde ich das auch nicht, denn eigentlich gilt ja die Regel, dass E-Mail entweder zugestellt werden, oder bouncen. Wenn meine Mutter mir nun eine E-Mail schreiben will und sich beim Local Part vertippt, bekomme weder ich die E-Mail, noch Mama einen Bounce.

      Viele Grüße

      Thomas
      https://www.roessing.org

      Kommentar


        #4
        Zitat von jjknw Beitrag anzeigen
        Ich habe versucht, dein Problem nachzuvollziehen, bekomme jedoch richtigerweise folgende "Bounce-Mail": (…) In meinem Fall verhält sich das System also wie erwartet.
        Vielen Dank fürs Testen, auch an Thomas! Das wird jetzt ja noch verrückter, wenn sich das Mail-System auch noch unterschiedlich verhält. Ich werde mich an den Support wenden.

        Viele Grüße
        Christoph

        Kommentar


          #5
          Beim Support habe ich bislang nichts Greifbares erreicht. Bei eigenen Tests habe ich jedoch festgestellt, dass sich das Mail-System offenbar wirklich nicht deterministisch verhält. Mit einem Skript habe ich mit Absender [email protected]mple.net jeweils 100 E-Mails an zufällige, garantiert nicht existente Adressen der Form [email protected] verschickt. Das war das Ergebnis:

          Uhrzeit Bounces
          ca. 19:32 Uhr 41
          ca. 19:38 Uhr 63
          ca. 20:12 Uhr 38

          Da scheint mir doch einiges im Argen zu liegen. Es könnte sich durchaus lohnen, wenn ihr eure Tests auch nochmal wiederholt.

          Kommentar


            #6
            Da scheint mir doch einiges im Argen zu liegen. Es könnte sich durchaus lohnen, wenn ihr eure Tests auch nochmal wiederholt.
            Moin,
            Test, 2156: Bounce "554 Sorry, no mailbox here by that name."

            Viele Grüße

            Thomas
            https://www.roessing.org

            Kommentar


              #7
              Der Support hat mir mittlerweile zweimal im Brustton der Überzeugung erklärt, das Problem gelöst zu haben, aber tatsächlich besteht es nach wie vor. Meine 300 automatisiert versendeten E-Mails gestern könnten nach Ansicht des Supports "Spamfilter o.ä. Mechanismen gegen das massenhafte Senden" ausgelöst haben und seien deshalb kein sicherer Indikator.

              Ich habe daher seit gestern jeweils zur vollen Stunde eine einzige Test-Mail an eine zufällige, jeweils andere und garantiert nicht existente Adresse wie [email protected] geschickt. Das ist das Ergebnis:

              Datum und Uhrzeit Bounce erhalten?
              2020-07-08 00:00 Uhr Ja
              2020-07-08 01:00 Uhr NEIN
              2020-07-08 02:00 Uhr Ja
              2020-07-08 03:00 Uhr Ja
              2020-07-08 04:00 Uhr Ja
              2020-07-08 05:00 Uhr Ja
              2020-07-08 06:00 Uhr Ja
              2020-07-08 07:00 Uhr Ja
              2020-07-08 08:00 Uhr NEIN
              2020-07-08 09:00 Uhr NEIN
              2020-07-08 10:00 Uhr NEIN
              2020-07-08 11:00 Uhr Ja
              2020-07-08 12:00 Uhr Ja
              2020-07-08 13:00 Uhr Ja
              2020-07-08 14:00 Uhr Ja
              2020-07-08 15:00 Uhr NEIN
              2020-07-08 16:00 Uhr NEIN
              2020-07-08 17:00 Uhr Ja
              2020-07-08 18:00 Uhr NEIN
              2020-07-08 19:00 Uhr Ja
              2020-07-08 20:00 Uhr NEIN
              2020-07-08 21:00 Uhr Ja
              2020-07-08 22:00 Uhr Ja
              2020-07-08 23:00 Uhr NEIN
              2020-07-09 00:00 Uhr Ja
              2020-07-09 01:00 Uhr NEIN
              2020-07-09 02:00 Uhr NEIN
              2020-07-09 03:00 Uhr NEIN
              2020-07-09 04:00 Uhr NEIN

              Das gefällt mir überhaupt nicht. :-(

              Kommentar


                #8
                Nach meiner ersten Anfrage (vor immerhin drei Wochen) hat der Support die "Konfiguration … neu geschrieben", um etwaige Fehler zu beseitigen.

                Nachdem ich diese angebliche Fehlerbeseitigung gründlich durch ca. 300 systematische Test-Mails geprüft und damit eindeutig widerlegt hatte, wurde mir vorgeworfen, meine "massenhaften" Tests hätten "Spamfilter o.ä. Mechanismen" ausgelöst und die Ergebnisse seien deshalb nicht verlässlich.

                Einen Tag später hat der Support behauptet, das Problem "behoben" zu haben. Es war aber ganz offensichtlich nicht behoben.

                Dann redete man sich damit heraus, dass Bounces bis zu drei Tage auf sich warten lassen können. Als die Bounces nach drei Tagen (natürlich) immer noch nicht da waren, erklärt der Support nun, dass die Fachabteilung das Problem nicht reproduzieren könne.

                Also, liebe Fachabteilung: Ihr müsst nichts reproduzieren, denn das habe ich schon für euch erledigt. Ich habe am 9. Juli 2020 um 08:00:00 Uhr eine E-Mail an eine Adresse mit dem local part ruc5ktfr37u2quk9 geschrieben, und die hätte bouncen müssen. Hat sie aber nicht. Kann ja wohl so schwer nicht sein, in den Logfiles nach dieser Zeichenkette zu suchen…

                Kommentar


                  #9
                  Guten Morgen Herr Schneegans,

                  Zitat von Christoph Schneegans Beitrag anzeigen
                  Nach meiner ersten Anfrage (vor immerhin drei Wochen) hat der Support die "Konfiguration … neu geschrieben", um etwaige Fehler zu beseitigen.

                  Nachdem ich diese angebliche Fehlerbeseitigung gründlich durch ca. 300 systematische Test-Mails geprüft und damit eindeutig widerlegt hatte, wurde mir vorgeworfen, meine "massenhaften" Tests hätten "Spamfilter o.ä. Mechanismen" ausgelöst und die Ergebnisse seien deshalb nicht verlässlich.

                  Einen Tag später hat der Support behauptet, das Problem "behoben" zu haben. Es war aber ganz offensichtlich nicht behoben.

                  Dann redete man sich damit heraus, dass Bounces bis zu drei Tage auf sich warten lassen können. Als die Bounces nach drei Tagen (natürlich) immer noch nicht da waren, erklärt der Support nun, dass die Fachabteilung das Problem nicht reproduzieren könne.

                  Also, liebe Fachabteilung: Ihr müsst nichts reproduzieren, denn das habe ich schon für euch erledigt. Ich habe am 9. Juli 2020 um 08:00:00 Uhr eine E-Mail an eine Adresse mit dem local part ruc5ktfr37u2quk9 geschrieben, und die hätte bouncen müssen. Hat sie aber nicht. Kann ja wohl so schwer nicht sein, in den Logfiles nach dieser Zeichenkette zu suchen…
                  Könnten Sie mir zu der Thematik die Ticket-ID nennen? Gerne würden wir den Sachverhalt prüfen.

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

                  Kommentar


                    #10
                    Hallo,

                    Zitat von Marcel Kaufmann Beitrag anzeigen
                    Könnten Sie mir zu der Thematik die Ticket-ID nennen? Gerne würden wir den Sachverhalt prüfen.
                    Die Ticket-ID ist 8809192.

                    Kommentar


                      #11
                      Hallo Herr Schneegans,

                      Zitat von Christoph Schneegans Beitrag anzeigen
                      Hallo,
                      Die Ticket-ID ist 8809192.
                      Danke für die Rückmeldung! Wir prüfen das Ticket nun entsprechend und melden uns dann erneut.
                      Blog - Facebook - Twitter
                      Communitybetreiber: domainfactory GmbH
                      Impressum / Pflichtangaben

                      Kommentar


                        #12
                        Zitat von Marcel Kaufmann Beitrag anzeigen
                        Hallo Herr Schneegans,



                        Danke für die Rückmeldung! Wir prüfen das Ticket nun entsprechend und melden uns dann erneut.
                        Wir haben Sie zwischenzeitlich kontaktiert und bitten um Ihre Mithilfe. Eine Meldung in dieser Richtung ist mir auch neu, wir werden uns das aber genau ansehen und hoffentlich schnellstmöglich Erklärungen liefern können. Dafür ist es aber wichtig, dass wir es selbst nachstellen können, daher die entsprechende Anfrage.

                        Mit freundlichen Grüßen

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

                        Kommentar

                        Lädt...
                        X