Hallo, On Wed, Jul 02, 2003 at 11:38:00AM +0200, Michael Helms wrote:

Adalbert Michelic schrieb:

...

* On Wed, 02 Jul 2003 at 9:51 +0200, Michael Helms wrote:

...

An: Person1@wvigmbh.de CC: xxx@yyy.de yyy@xxx.de .... Person2@wvigmbh.de

Person2 bekommt diese mail nicht. Sind Person1 und Person2 vertauscht, bekommt Person1 die mail nicht.

Das sieht mir eher nach einem procmail Problem aus. Sprich fetchmail holt die Mails ordentlich ab aber procmail wirf sie halt ins erste passende Postfach. Je nachdem ob das ein BCC oder CC war sollte die Mail kein/ein oder zwei mal bei Person[12] ankommen. Greetings Daniel -- Das Leben ist ein Spiel: Unwirklich, unrealistisch!!! Nur dass man es nicht mehr neu starten kann!!! Kein LÖSCHEN; kein RESTART; nur GAME OVER!!!!!!

* On Wed, 02 Jul 2003 at 11:38 +0200, Michael Helms wrote:

Adalbert Michelic schrieb:

...

* On Wed, 02 Jul 2003 at 9:51 +0200, Michael Helms wrote:

...

Ich hab hier folgendes Problem:

Aus Österreich gehen mails ab mit folgenden Emfängern:

An: Person1@wvigmbh.de CC: xxx@yyy.de yyy@xxx.de .... Person2@wvigmbh.de

Person2 bekommt diese mail nicht. Sind Person1 und Person2 vertauscht, bekommt Person1 die mail nicht.

Wenn beide im To: stehen, was ist dann?

Hab gerade mal nachgeschaut. Das Problem war auch schon, wenn beide im To stehen. Da hat dann der erste die Mail nicht bekommen.

Okay, bestätigt meinen Verdacht.

...

...

Ich habe das Log-Level von sendmail bereits so hoch geschraubt, dass ich mir sicher bin, dass sendmail nie versucht hat eine mail an Person2 zuzustellen.

Wie äussert sich der Versuch genau in den Logfiles?

Na eben gar nicht. Hier ein Ausszug:

--------------schnipp-------

NOQUEUE: <-- MAIL FROM: BODY=8BITMIME SIZE=32671 RAA19831: --> 250 ... Sender ok RAA19831: <-- RCPT TO: RAA19831: --> 250 ... Recipient ok RAA19831: <-- DATA RAA19831: --> 354 Enter mail, end with "." on a line by itself RAA19831: from=, size=32346, class=0, pri=62346, ......... RAA19831: --> 250 RAA19831 Message accepted for delivery RAA19831: alias => spi RAA19831: to=sss, delay=00:00:09, xdelay=00:00:00, mailer=local, .. RAA19831: done

-----------schnapp----------------

Und Person2 findet keine Erwähnung.

Ah, ich habe Deinen obigen Satz anfangs irrtümlich als "... dass ich mir sicher bin, daß sendmail versucht hat ..." gelesen. Jetzt macht es Sinn.

...

...

fetchmail arbeitet jetzt auch mit -v -v und ich warte nun auf den Nächsten "Unfall". Bei der Durchforstung der alten

Warten? Ist das Problem nicht reproduzierbar, d.h. tritt es nur bei einem bestimmten Absender auf? Da würd ich mal spontan drauf tippen, daß der Murks hat.

Ich konnte es bis jetzt nicht reproduzieren.

D.h. wenn Du über einen GMX-Testaccount eine Mail an beide Personen gleichzeitig (und evtl. noch ein paar andere) schickst, kommt die Mail bei beiden an?

Ob es nur bei einem bestimmten Absender auftritt weiss ich nicht. Ist auch nicht so einfach raus zu bekommen. Wer merkt schon dass er eine mail nicht bekommen hat?

Naja, vielleicht fällts ja auf.

Das mit dem Murks beim Absender dachte ich auch erst. Aber die Mail-Header sehen (für mich) vernümpftig aus.

Naja, die sagen ja im Regelfall (!= catch-all) nicht viel aus.

...

...

Logfiles nach ähnlichen Problemen hat sich aber eigentlich schon gezeigt, dass fetchmail durchaus 2 mails abgeholt hat (die logs sich nicht so ausfühlich, dass man wirklich damit was anfangen könnte, die Vermutung stützt sich auf die Anzahl der Oktets).

fetchmail? Da ist aber kein catch-all Account, oder ähnliches grausames im Spiel? Da könnt ichs gleich glauben, wenn sich fetchmail verhaspelt.

Was ist ein catch-all Account? Vermutlich das was wir machen. Es gibt beim Provider nur 1 Postfach wo alles rein geht. Dieses Postfach wird abgerufen und dann intern mittels fetchmail und sendmail auf die richtigen Empfänger verteilt.

Genau das.

Das geht viel schneller als ein Postfach pro Empfänger beim Provider, und ist auch viel pflegeleichter.

Das glaub ich Dir gleich, daß es schneller ist. Wenn nicht alle Mails kommen, muss es fast zwangsläufig schneller sein ... *eg*

Und wieso sollte sich fetchmail verhaspeln?

Na sieht man doch. Lies Dir mal den Abschnitt über Multidrop-Mailboxen in man fetchmail durch. Mit den Informationen, die ich von dort und aus Deinen Mails gewonnen habe, schließe ich folgendes: Der Mailserver des problematischen Absenders verschickt zwei Kopien der Mail, eine an Person1, die andere an Person2. mailin.webmailer.de sortiert die hintereinander ins gleiche Postfach ein. fetchmail holt die erste Mail, sieht, daß sie für Person1 ist, und stellt an Person1 zu. Dann kommt die zweite Mail, fetchmail sieht anhand der Message-ID, daß die Mail schon mal da war, und legt sie ad acta. Bei einer Mail stehen die Empfänger nun mal nicht im Header, sondern im Envelope. Mit dem Einsortieren in ein POP3-Postfach geht das Envelope flöten. Alles, was sich dann noch rekonstruieren lässt, beruht auf good-will der beteiligten Mailserver. Vergiss es. Wenn das eine Firma ist, und so sieht es aus, dann besorg da wenigstens pro Empfänger eine POP3-Box. Wenn das Poppen dafür 30 Sekunden länger dauert, sollte das nichtmal ein Miniaturunternehmen umbringen dürfen, schon gar nicht eine GmbH, die eh mehr Geld herumliegen haben sollte. Noch besser: Suche einen Provider, der Dir die Mails queued, und dann per ETRN oder UUCP rausrückt (UUCP IMO bevorzugt).

...

Schau mal in die POP3(?)-Postfächer, was da so rum liegt. # telnet pophost.webmailer.de pop3 | USER foo | PASS blah | LIST

Wie kommt man da wieder raus?

QUIT :-) Mach das catch-all/multidrop-Zeugs weg. Das kann nicht gescheit funktioniert. Reicht vielleicht für den Heimgebrauch noch (und nicht mal da würd ichs nehmen), aber für eie Firma ist das - Sorry - inakzeptabel. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at

* On Wed, 02 Jul 2003 at 14:27 +0200, Michael Helms wrote:

Adalbert Michelic schrieb:

...

D.h. wenn Du über einen GMX-Testaccount eine Mail an beide Personen gleichzeitig (und evtl. noch ein paar andere) schickst, kommt die Mail bei beiden an?

Genau so ist es.

...

Der Mailserver des problematischen Absenders verschickt zwei Kopien der Mail, eine an Person1, die andere an Person2. mailin.webmailer.de sortiert die hintereinander ins gleiche Postfach ein. fetchmail holt die erste Mail, sieht, daß sie für Person1 ist, und stellt an Person1 zu. Dann kommt die zweite Mail, fetchmail sieht anhand der Message-ID, daß die Mail schon mal da war, und legt sie ad acta.

Dann müsste es doch reproduzierbar sein, oder?

Noe, muss nicht. Wart mal, aus Österreich kommt die Mail? Von einem AON-Benutzer? Und auf AON-Seite läuft qmail, mein spezieller Freund. Wenn Du eine Mail an 5 Benutzer auf der gleichen Maschine schickst, versendet qmail 5 Kopien. sendmail und andere nicht so kranke Mailserver versenden nur eine Kopie, und geben bei dieser alle 5 Adressaten im Envelope an. mailin.webmailer.de, mit sendmail bestückt trägt nun bei jeder der Kopien im Received-Header ein, für wen die Mail ist. fetchmail Deinerseits detektiert Duplikate und verwirft sie. Bei einer über !qmail versendeten Kopie, trägt der mailin.webmailer.de gar nix im Received-Header ein. fetchmail reimt sich dann die vermutlichen Empfänger via To:-/Cc:-Header zusammen. Welche der beiden Verhaltensweise nun ****** ist, möchte ich an dieser Stelle nicht kommentieren .... Hast Du irgendwo einen qmail-Server, wo Du einliefern kannst? Probier das mal aus. Möglicherweise würde es Dir dann helfen, fetchmail, das Entfernen der Duplikate auszutreiben. Aber nichtsdestotrotz - multidrop kann prinzipbedingt nicht korrekt funktionieren. Alle Aussagen wie immer ohne Gewähr, ich versuche nur, was zusammenzureimen.

...

Bei einer Mail stehen die Empfänger nun mal nicht im Header, sondern im Envelope. Mit dem Einsortieren in ein POP3-Postfach geht das Envelope flöten. Alles, was sich dann noch rekonstruieren lässt, beruht auf good-will der beteiligten Mailserver.

Vergiss es. Wenn das eine Firma ist, und so sieht es aus, dann besorg da wenigstens pro Empfänger eine POP3-Box. Wenn das Poppen dafür 30 Sekunden länger dauert, sollte das nichtmal ein Miniaturunternehmen umbringen dürfen, schon gar nicht eine GmbH, die eh mehr Geld herumliegen haben sollte.

Das sind nicht 30 sek, sondern eher 30 sek pro Postfach. Umbringen tut das keinen. Aber der Pflegeaufwand ist deutlich höher.

Ja, kann sein. Aber dafür bekommen alle die Mail.

...

Noch besser: Suche einen Provider, der Dir die Mails queued, und dann per ETRN oder UUCP rausrückt (UUCP IMO bevorzugt).

Was ist das?

Bei ETRN brauchst Du glaub ich eine fixe IP-Adresse. Der Provider empfängt alle Mails, stellt fest, daß Du grad nicht erreichbar bist, und steckt daraufhin alle mal in die Queue. fetchmail sagt dann ETRN zum Server, daraufhin schüttet der Dir die Mails alle in den Rachen. Der Server muss aber Deine Adresse kennen, er schickt die Mails nicht einfach dorthin, von wo das ETRN gekommen ist. UUCP ist unix-to-unix copy. Schaut so aus, daß auf dem Server ein Spoolverzeichnis existiert, wo dann jeweils die Mails und ein Control-File landen. Dein Rechner baut dann auf irgendeinem Weg (kann TCP sein, eine serielle Verbindung, Brieftauben, $WHATEVER) eine verbindung zum Server auf, holt die Files alle ab, und führt die control-Files aus. Für Mail steht da immer 'rmail irgendwas' drinnen. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at

* On Wed, 02 Jul 2003 at 16:30 +0200, Michael Helms wrote:

Adalbert Michelic schrieb:

...

Noe, muss nicht. Wart mal, aus Österreich kommt die Mail? Von einem AON-Benutzer? Und auf AON-Seite läuft qmail, mein spezieller Freund.

Woher weißt du das es von aon kommt? Ich dachte ich hab alle Spuren verwischt. Aber diese Spur hätte ich wohl besser gelassen.

*rofl* Gewusst habe ich es nicht - ich habe mir nur das Verhalten durch den Kopf gehen lassen, und auf qmail als Mailserver beim Absender geschlossen. Und prominentester qmail-Benutzer in Österreich ist nun einmal AON, da lag der Schluß nahe :-)

...

Wenn Du eine Mail an 5 Benutzer auf der gleichen Maschine schickst, versendet qmail 5 Kopien. sendmail und andere nicht so kranke Mailserver versenden nur eine Kopie, und geben bei dieser alle 5 Adressaten im Envelope an. mailin.webmailer.de, mit sendmail

Äh, bis hier hab ich es wohl verstanden. Also, da sendet jemand 2 Mails an uns und benutzt (unbewusst) qmail.

...

bestückt trägt nun bei jeder der Kopien im Received-Header ein, für wen die Mail ist. fetchmail Deinerseits detektiert Duplikate und

Nun kommen hier bei meinem Provider 2 Mails an und das dortige sendmail leitet diese weiter ohne am Header etwas zu ändern (weil die Mails mit qmail gesendet wurden). Und dann .....

...

verwirft sie. Bei einer über !qmail versendeten Kopie, trägt der mailin.webmailer.de gar nix im Received-Header ein. fetchmail reimt sich dann die vermutlichen Empfänger via To:-/Cc:-Header zusammen.

Hab heute wohl nen Brett vorm Kopf, aber ich krieg die 2 Handlungsstränge (1 ne Mail mit 5 Adressaten und sendmail, oder 1 ne Mail + 4 Kopien und qmail) nicht getrennt.

Okay, ich probiers noch mal langsam: fetchmail versucht im multidrop-modus wie folgt die Empfänger festzustellen: a) Analyse des Received: Headers. b) Analyse etwaiger Resent-To/Cc/Bcc-Header c) Analyse von To/Cc/Bcc. qmail sendet 5 mal die gleiche Mail an euch, trägt aber bei jeder Mail im Envelope-To einen anderen Empfänger ein. fetchmail bei euch holt die Mail 5 Mal ab, schmeisst aber 4 davon weg, weil sie alle die gleiche Message-ID haben. Irgendeine der Mails kommt an, diese hat einen Received:-Header mit gültiger Empfängeradresse (Modus a). fetchmail stellt die Mail diesem einen Empfänger zu. Ein anderer Mailserver schickt die Mail nur einmal an euch, mit 5 Empfängern im Envelope-To. sendmail auf dem mailin.webmailer.de sieht, dass die Mail an mehrere geht, und trägt im Received:-Header keine Adresse ein. fetchmail muss daraufhin zur Adressatenermittlung Modus c verwenden. Die Mail wird allen fünf Empfängern zugestellt. Das hier ist der Abschnitt aus man fetchmail: Use the multiple-local-recipients feature with caution -- it can bite. Also note that all multidrop features are ineffective in ETRN mode. Also, note that in multidrop mode duplicate mails are sup­ ---> pressed. A piece of mail is considered duplicate if it ---> has the same message-ID as the message immediately preced­ ---> ing and more than one addressee. Such runs of messages ---> may be generated when copies of a message addressed to ---> multiple users are delivered to a multidrop box. Man könnte das Verhalten von fetchmail im multidrop-Modus verbessern (zumindest für euch), wenn man die Mails nur wegschmeisst, wenn die Message-ID ident ist _und_ die ermittelten Empfänger. Ich trau mir fast wetten, daß bei euch da immer 2 Mails im Postkasten liegen, die eine mit Received: for <Person1>, die zweite mit Received: for <Person2>. Die, die später im Postkasten zu liegen kommt, fällt raus ...

...

Welche der beiden Verhaltensweise nun ****** ist, möchte ich an dieser Stelle nicht kommentieren ....

Hast Du irgendwo einen qmail-Server, wo Du einliefern kannst? Probier das mal aus. Möglicherweise würde es Dir dann helfen, fetchmail, das Entfernen der Duplikate auszutreiben. Aber nichtsdestotrotz - multidrop kann prinzipbedingt nicht korrekt funktionieren.

Ich bin mit dem entsprechenden Teil der man-Page nocch nicht fertig, bleibe aber drann.

Okay. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at

* On Thu, 03 Jul 2003 at 11:44 +0200, Michael Helms wrote:

Adalbert Michelic schrieb: .......

Vielen Dank für die umfangreiche Hilfe. Das Problem ist damit zwar noch nicht ganz gelöst, aber ich habe ne Menge gelernt.

Schön :-)

...

Man könnte das Verhalten von fetchmail im multidrop-Modus verbessern (zumindest für euch), wenn man die Mails nur wegschmeisst, wenn die Message-ID ident ist _und_ die ermittelten Empfänger.

Mir scheint diese "Verbesserung" durchaus sinnvoll, zumindest als Parameter (es gibt ja ohnehin schon einen qmail spezifischen Pararmeter).

Mal schaun ob ich die Stelle in den sourcen finde.

Wenn Du nicht zurechtkommst, kannst Du mir ja Bescheid sagen, dann knöpf ich mirs mal vor, und versuche mein Glück. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at