nicht angemeldet
Mail::DeliveryStatus::BounceParser
Hallo geehrtes Forum,
ich stecke fest... :(
Ich rufe eine POP3-Mailbox ab und überprüfe die Nachrichten mit dem BounceParser-Modul. Dieses allerdings kennzeichnet jede Nachricht als gebounced. Die Arrays @reports und @adresses werden nicht, wie im CPAN beschrieben, gefüllt:
my $pop = Net::POP3->new( 'pop.domain.de', Timeout => 60 );
if ( $pop->login( $username, $password ) > 0) {
my $pop_alle_emails = $pop->list;
foreach my $pop_email ( keys %$pop_alle_emails ) {
my $in_mail = $pop->get( $pop_email );
my $bounce = eval { Mail::DeliveryStatus::BounceParser->new( $in_mail ); };
my @addresses = $bounce->addresses;
my @reports = $bounce->reports;
print Dumper $bounce;
...
Der Dump sieht (ich hoffe aus das Wesentliche gekürzt) so aus:
$VAR1 = bless( {
'orig_message_id' => undef,
'parser' => bless( {
...
'reports' => [],
'log' => undef,
'is_bounce' => 1,
...
'ME_Bodyhandle' => bless( {
'MBS_Data' => '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Tahoma>text</FONT></DIV></BODY></HTML>
'
Der Dump ist sehr umfangreich und ich verstehe nicht viel davon. Die Nachricht wurde mit Outlook-Express abgeschickt und besteht nur aus dem Wort 'text'. Sie ist irgendwo in den Tiefen des Hashes $bounce zu finden. Dem entnehme ich, daß das Modul die Nachricht analysiert hat.
Erwartet habe ich, daß 'is_bounce' false ist. Desweiteren habe ich gedacht, daß ich in @adresses Emailadressen finde, aber es ist ein leeres Array, genauso wie @reports. Daran ändert sich auch nichts, wenn ich ein 'echtes' Bounce-Mail analysieren lasse. Also irgendwas mache ich falsch - aber was bloß? May someone please help me?
Bedrückte Grüße
JOhnnY
-
Works as designed. Schau in den Quelltext. Alle Messages sind durch den Konstruktor standardmäßig als Bounces markiert. Neun Ausnahmen löschen dieses Flag.
Wenn dir das nicht gefällt, mach einen Bug auf, du weißt ja, wie das geht.
-
Hi CPAN,
Works as designed. Schau in den Quelltext. Alle Messages sind durch den Konstruktor standardmäßig als Bounces markiert. Neun Ausnahmen löschen dieses Flag.
--- aaaah, vielen Dank! Das Modul ist dafür gedacht, eine reine 'Bounce-Back-Mailbox' zu bearbeiten, richtig? Den Quelltext hatte ich mir schonmal angeschaut, wobei das meine Fähigkeiten weit übersteigt. Ich begreife das Konzept der objektorientierten Programmierung bisher nicht. Nach den Bounces zu gucken, fiel mir nicht ein. Ich habe versucht, den Teil zu finden, der @reports und @adresses füllt.
"If the bounce message is not structured according to RFC1892, BounceParser will
still try to return as much information as it can; in particular, you can count
on "email" and "std_reason" to be present."Bei meinem Versuch waren jedoch beide Arrays komplett leer. Kannst Du mir da vielleicht nochmal auf die Sprünge helfen?
Wenn dir das nicht gefällt, mach einen Bug auf, du weißt ja, wie das geht.
--- bisher habe ich noch nie einen Bug reportet... Da aber wahrscheinlich auch im CPAN 'funzt nich' als exakte Beschreibung des Fehlers nicht ausreichend ist, möchte ich gerne vorher genau verstanden haben, was das Modul tut und auch nicht tut.
Danke nochmal für Deine Antwort!
JOhnnY-
Das Modul ist dafür gedacht, eine reine 'Bounce-Back-Mailbox' zu bearbeiten, richtig?
Ja, das wird aber auch explizit so in der Doku gesagt.
Bei meinem Versuch waren jedoch beide Arrays komplett leer.
Dann gib mal eine Bouncenachricht, mit der man das nachstellen kann.
Da aber wahrscheinlich auch im CPAN 'funzt nich' als exakte Beschreibung des Fehlers nicht ausreichend ist
Richtig. Mit den folgenden drei Punkten kommuniziert man aber schon sehr klug:
1. Das sind meine Vorbedingungen/Voraussetzungen/Umgebung/Daten und ich habe dies gemacht.
2. Dann ist das passiert.
3. Ich habe aber erwartet, dass jenes passiert, weil...-
Hi CPAN,
Das Modul ist dafür gedacht, eine reine 'Bounce-Back-Mailbox' zu bearbeiten, richtig?
Ja, das wird aber auch explizit so in der Doku gesagt.--- ok, beim zweiten Lesen fällt es mir auch ins Auge: 'Mail::DeliveryStatus::BounceParser analyzes RFC822 bounce messages' heißt nicht, daß er _alle_ Nachrichten analysiert. Dann wäre mein Part ja, davor noch eine Weiche zu programmieren, die die potentiellen Bounce-Mails an den Parser weiterleitet. Damit jedoch ist das, wofür ich das Modul verwenden wollte, bereits erledigt: das Erkennen von Bounce-Mails. Der Autor hat sehr viele Reg-Exe 'gesammelt', um genau zu analysieren, welche Art von Bounce vorliegt ('the standardized reason' => $report->get('std_reason'); ). Dieses Feld, welches in @reports enthalten sein soll, würde ja aussagen _ob_ es sich um eine Bounce-Mail handelt, es ist jedoch in meinem Script immer leer. :(
Bei meinem Versuch waren jedoch beide Arrays komplett leer.
Dann gib mal eine Bouncenachricht, mit der man das nachstellen kann.--- ist im Prinzip egal welche, ich hab mal eine angehängt. Auch die folgenden Zeilen bringen kein Ergebnis:
my $orig_message_id = $bounce->orig_message_id; # ABCD.1234@mx.example.com
my $orig_message = $bounce->orig_message; # Mail::Internet objectHier sollte doch, egal ob Bounce-Mail oder nicht, in jedem Fall die Original-Mail enthalten sein. Ist bei mir leer.
Ich leite die Bounce-Mails vorerst manuell an eine Mailbox weiter. Diese Mailbox erhält zusätzlich auch andere Arten von Mails, mit denen andere Aktionen verbunden sind. Daher dachte ich, das Modul kann mir sagen, ob es sich um eine Bounce-Mail handelt, oder nicht. Dies, so dachte ich, sei durch die Variable 'is_bounce' beschrieben. Wenn ich diese nicht nehmen kann, dann doch vielleicht std_reason?
Hier ist ein Beispiel einer Bounce-Mail, die leere @report und @adresses ergibt, wie alle anderen Mails allerdings auch:
<bounce-mail>
----- Original Message -----
From: MAILER-DAEMON@domain.info
To: l.b@domain.eu
Sent: Friday, February 12, 2010 3:02 PM
Subject: failure noticeHi. This is the qmail-send program at domain.info.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.irgendwer@gmx.de:
213.165.64.100 does not like recipient.
Remote host said: 550 5.1.1 irgendwer@gmx.de... User is unknown
{mx065}
Giving up on 213.165.64.100.--- Below this line is a copy of the message.
Return-Path: l.b@domain.eu
Received: (qmail 5115 invoked from network); 12 Feb 2010 15:02:12 +0100
Received: from localhost (127.0.0.1)
by localhost with SMTP; 12 Feb 2010 15:02:12 +0100
MIME-Version: 1.0
From: versender noreply@domain.info
Reply-To: l.b@domain.eu
Date: Fri, 12 Feb 10 15:02:12 +0100
Subject: Betreff
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <kxqezo.43sifw@>
To: irgendwer@gmx.de<html>
</bounce-mail>
Da aber wahrscheinlich auch im CPAN 'funzt nich' als exakte Beschreibung des Fehlers nicht ausreichend ist
Richtig. Mit den folgenden drei Punkten kommuniziert man aber schon sehr klug:--- ich habe Deine erhellenden Ausführungen hier gelesen, trotz mäßigem Englisch ein bißchen mitgeschmunzelt und nehme dies seitdem als Richtschnur für die Formulierungen meiner Fragen.
Da ich jedoch auf meiner Suche nach Beispielen von Anwendungen dieses Moduls auf einige Beschreibungen gestoßen bin, die aussagen, daß das Modul wunderbar funktioniert, gehe ich erstmal davon aus, daß der Fehler in meinem Script liegt. Das sollte ich zur Gänze ausschließen können, bevor ich einen Bug-Report schreibe. Ansonsten beschreibe ich eher einen 'Anwendungs-Bug' meinerseits, was höchstens zum Schmunzeln anregt...
So long
JOhnnY-
Hier ist ein Beispiel einer Bounce-Mail
Das ist nicht das richtige Format, das sieht aus wie die stark verkürzte Ansicht eines Mailclients. Damit kann man nichts anfangen. Ich meinte etwas, womit ich das Modul füttern kann, also wo noch alle Header intakt sind. Du kannst die Angaben anonymisieren, die privat sind oder auf dich schließen lassen, aber du darfst nichts weglöschen.
Ansonsten beschreibe ich eher einen 'Anwendungs-Bug' meinerseits, was höchstens zum Schmunzeln anregt...
Man darf im RT statt Bugs auch Wünsche formulieren. Da kannst du deine Situation beschreiben: "Ich wollte M::DS::BP dazu einsetzen, echte Mail und Bounces zu klassifizieren, aber alle Mails werden zunächst als Bounces behandelt... etc. etc."
-
Hier ist ein Beispiel einer Bounce-Mail
Das ist nicht das richtige Format, das sieht aus wie die stark verkürzte Ansicht eines Mailclients. Damit kann man nichts anfangen.--- hhhmmmm. Das ist, was ich zur Verfügung habe. Dann werde ich mir eine andere Lösung suchen müssen, z.B. aus dem Modul die einzelnen Prüfungen herauskopieren und damit die Mails analysieren.
Ich leite die erhaltenen Bounces von meinem Mailclient an die Mailbox weiter. Ich weiß nicht, wie ich da an den fehlenden Header herankommen soll?
-
Ach Mensch, Johnny, du bist 'ne Nulpe. :( Die fehlen nicht! Das ist eine Angelegenheit der Ansicht, wie ich schon sagte.
In KMail: Ansicht → Nachrichtencode ansehen. Oder Datei → Speichern unter… mit Typ RFC822-Nachricht oder mbox. Oder du kämmst die mbox-Datei durch, wo dein Client alle Nachrichten aufbewahrt.
-
Hi CPAN,
Ach Mensch, Johnny, du bist 'ne Nulpe.
--- made my day... ;-)
In KMail: Ansicht → Nachrichtencode ansehen. Oder Datei → Speichern unter… mit Typ RFC822-Nachricht oder mbox. Oder du kämmst die mbox-Datei durch, wo dein Client alle Nachrichten aufbewahrt.
--- ich speichere, ich öffne, ich sehe:
Received: (qmail 28621 invoked by uid 1007); 15 Feb 2010 17:13:25 +0100
Delivered-To: vdomains-domain.de-mobil@domain.de
Received: (qmail 28617 invoked by uid 1450); 15 Feb 2010 17:13:25 +0100
Delivered-To: vivnemhc-domain.de-l.b@domain.de
X-Originally-To: l.b@domain.de
Received: (qmail 28612 invoked by uid 1007); 15 Feb 2010 17:13:25 +0100
Delivered-To: vdomains-domain.eu-l.b@domain.eu
Received: (qmail 28604 invoked for bounce); 15 Feb 2010 17:13:25 +0100
Date: 15 Feb 2010 17:13:25 +0100
From: MAILER-DAEMON@server152-han.de-nserver.de
To: l.b@domain.eu
Subject: failure notice
X-SpamAssassin: $spamass_statusHi. This is the qmail-send program at server152-han.de-nserver.de.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.ab@bc.de:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.--- Below this line is a copy of the message.
Return-Path: l.b@domain.eu
Received: (qmail 31989 invoked from network); 8 Feb 2010 16:13:25 +0100
Received: from server152-han.de-nserver.de (HELO localhost.localdomain) (85.158.176.168)
by server152-han.de-nserver.de (qpsmtpd/0.82) with ESMTP; Mon, 08 Feb 2010 16:13:25 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Type: multipart/mixed; boundary="_----------=_1265642005319810"
X-Mailer: MIME::Lite 3.021 (F2.76; A2.03; B3.07_01; Q3.07)
Date: Mon, 8 Feb 2010 16:13:25 +0100
From: active system (L.b) l.b@domain.eu
To: ab@bc.de
Subject: Hallo BetreffX-User-Auth: Auth by localip through 85.158.176.168
This is a multi-part message in MIME format.
--_----------=_1265642005319810
Content-Transfer-Encoding: binary
Content-Type: multipart/alternative; boundary="_----------=_1265642005319811"This is a multi-part message in MIME format.
--_----------=_1265642005319811
Content-Disposition: inline
Content-Length: 2990
Content-Transfer-Encoding: binary
Content-Type: text/plainTEXT
--_----------=_1265642005319811
Content-Disposition: inline
Content-Length: 5728
Content-Transfer-Encoding: binary
Content-Type: text/html<html>
</html>
--_----------=_1265642005319811--
--_----------=_1265642005319810
Content-Disposition: attachment; filename=mail.txt
Content-Length: 2990
Content-Transfer-Encoding: binary
Content-Type: text/plaintext_anhang
--_----------=_1265642005319810--
Doch diese Prozedur kann ich ja nicht jedesmal machen, bevor ich eine Mail weiterleite?!
Genulpte Grüße
JOhnnY-
Da kiekste vielleicht wie'n Elch aus der Wäsche, aber damit kann ich deinen Bericht, die besagten Accessoren würden leer zurückliefern, nicht nachvollziehen.
use Mail::DeliveryStatus::BounceParser qw(); my $bounce = eval {Mail::DeliveryStatus::BounceParser->new([<DATA>]);}; my $address_ref = [$bounce->addresses]; # ['ab@bc.de'] my ($report) = $bounce->reports; $report->get('email'); # 'ab@bc.de' $report->get('std_reason'); # 'unknown' __DATA__ Received: (qmail etc. etc.-
Da kiekste vielleicht wie'n Elch aus der Wäsche, aber damit kann ich deinen Bericht, die besagten Accessoren würden leer zurückliefern, nicht nachvollziehen.
Ok. Wenn ich die Mail mit Header direkt als String analysieren lasse, erhalte ich dasselbe Ergebnis wie Du (was schonmal erhebend ist :)
Dann entsteht der Fehler dadurch, daß die Mail nicht direkt als Bounce in der Mailbox landet, sondern ich sie mit dem Mailclient weiterleite.
Da ich für einen Teil der Mails keine Bounce-Adresse einrichten kann, bleibt mir nur, etwas Eigenes zu schreiben. Im Prinzip eine Hard-/Soft-Bounce-Erkennung. Da bietet mir der Quellcode des Moduls ja genügend Hilfestellung.
Danke.
JOhnnYP.S.
guck ich so?
-
-
-
-
-
-
-
-
-
