eMail Rückläufe(r) "Bouncehandler"

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

  • eMail Rückläufe(r) "Bouncehandler"

    Hallo,

    welche Möglichkeiten gibt es, eMails die nicht ankommen aus dem Newsletterverteiler zu löschen?

    Habe bereits das Beispiel aus dem PHPMagazin 5.04 gelesen, gibt es jedoch noch andere Möglichkeiten eMails auszutragen?

    Danke!

    Gruß Björn
    » http://www.htaccess-generator.com

  • #2
    gibt es denn einen anderen weg, als die "mail delivery failure"-emails auszuwerten?

    Kommentar


    • #3
      ich denke imap ist hier das zauberwort oder irre ich mich?


      http://de2.php.net/manual/de/ref.imap.php

      Kommentar


      • #4
        Die frage ist, was das problem ist?

        - hast du ein problem die mails zurück zu bekommen
        - oder hast du ein problem die mails auszulesen?

        Welche methoden stehen denn in dem genannten artikel?

        Kommentar


        • #5
          Beim Beispiel von PHPMag mußt du auf die qmail oder sendmail "email-Datei" auf dem Server zugreifen können. Per Unix Script wird die eMail dann an ein PHP Script weitergeleitet und dort ausgelesen. Die ausgelesene eMail Adresse wird dann aus der Datenbank entfernt. Auf dem Server wo ich es realisieren muss, komme ich nicht an die entsprechende Datei...
          » http://www.htaccess-generator.com

          Kommentar


          • #6
            Irgendwie mußt du auf die Inbox des Accounts zugreifen, von dem aus der Newsletter gesendet wird bzw. der als Reply-To angegeben ist. Ohne Zugriff hast du schon verloren.

            I.d.R. konfiguriert man den Account einfach so, dass eingehende Mails (vor oder nach dem Spam-, Viren- und sonstigen Filtern) einen weiteren Filter durchlaufen, der natürlich in PHP geschrieben sein kann, aber in C oder so natürlich performanter ist.

            Der Filter entscheidet, ob die Mail ein Bounce ist und entfernt ggf. den Adressaten aus der Empfängerliste.
            Die Schwierigkeit besteht darin, eine Bounce-Mail überhaupt als solche zu erkennen. Web.de-Bounces sehen z.B. ganz anders aus als die von GMX ...
            Auf die großen Provider kann man sich schnell einstellen, aber für die vielen kleinen Firmen-MTAs ist es günstig, wenn man dem Filter schnell und einfach neue "Bounce-Formate" beibringen kann.


            Schau dich mal um, ob du nicht ein Newsletter-Tool findest, das Bounces selbst behandelt, bei dem du dir abschauen kannst, wie es das macht.

            Kommentar


            • #7
              Original geschrieben von onemorenerd

              Die Schwierigkeit besteht darin, eine Bounce-Mail überhaupt als solche zu erkennen. Web.de-Bounces sehen z.B. ganz anders aus als die von GMX ...
              Auf die großen Provider kann man sich schnell einstellen, aber für die vielen kleinen Firmen-MTAs ist es günstig, wenn man dem Filter schnell und einfach neue "Bounce-Formate" beibringen kann.
              Ich habs bis jetzt noch nicht gebraucht aber ich bin davon ausgegangen,
              dass alle MTAs für solche situation nach den entsprechenden rfcs vorgehen.
              Also 1891 und 1892 wobei 1892 das interessante ist.
              Ist das nicht so ?
              (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

              Kommentar


              • #8
                Ist das nicht so ?
                Ne, das ist leider nicht so.

                RFC 1892 spezifiziert den Rahmen, 1894 füllte ihn mit etwas Leben, wurde aber inzwischen von 3464 überholt. Was 1892 mit "A machine parsable body part" mehr um- als beschreibt, sieht in 3464.E so aus:
                --RAA14128.773615765/CS.UTK.EDU
                content-type: message/delivery-status

                Reporting-MTA: dns; cs.utk.edu
                ...
                --RAA14128.773615765/CS.UTK.EDU
                Schon laut 1894 und erst recht nach 3464 müßte der String 'Reporting-MTA:' in jeder Bouncemail zu finden sein. Wenn dem so wäre, müßte ich obiges Posting natürlich zurücknehmen, denn dann wären Bounces ganz easy zu parsen. Aber ich habe gerade ca. 12000 Bounces durchsucht und nicht ein einziges Mal 'Reporting-MTA' gefunden.

                ich bin davon ausgegangen,
                dass alle MTAs für solche situation nach den entsprechenden rfcs vorgehen.
                Oh Vorsicht, RFCs sind eine feine Sache, vor allem die, die flächendeckend angewandt werden. Aber man sollte als Programmierer niemals damit rechnen, dass alle sich an ein RFC halten.

                Kommentar


                • #9
                  Hmm das sind ja nicht so gute nachrichten ...

                  Original geschrieben von onemorenerd
                  Oh Vorsicht, RFCs sind eine feine Sache, vor allem die, die flächendeckend angewandt werden. Aber man sollte als Programmierer niemals damit rechnen, dass alle sich an ein RFC halten.
                  Naja von den MTAs die im produktiven und weit verbreiteten einsatz sind
                  erwarte ich sowas. Aber gut dass ich nun weis dass es nicht so ist,
                  falls ich das mal brauche.

                  greets

                  [Nachtrag]
                  Gibt es denn wenigstens immer eine "Action" oder "Status" im body des multipart/report bei
                  den bouncemails ? Dann könnte man sich ja noch was basteln.
                  Zuletzt geändert von closure; 20.10.2006, 08:10.
                  (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

                  Kommentar


                  • #10
                    ein sinnvoller weg ist
                    http://en.wikipedia.org/wiki/VERP

                    ... d.h. du richtest eine catch-all-adresse ein (bounce@example.com),
                    packst beim versenden an den return-path ein hash <md5>-bounce@example.com, und merkst dir die zuweisung md5-email-adresse

                    wenn du ein e-mail mit diesem md5-hash bekommst, ist es ein bounce.


                    grüße
                    axo

                    Kommentar

                    Lädt...
                    X