RE: Majordomo-Probleme (again :(( )
At 08:58 20.03.2002 +0100, Ralf Kayser wrote:
Doofe Frage, wie kann ich es auf einer Kiste erzeugen, das die mail einfach zurück geht?
Setz einfach in der xxx.config: reply_to = <irgend eine Mail-Adresse> Damit verhinderst Du schon mal den gröbsten Unfug durch gedankenloses Replyen.
Und wie kann ich verhindern, das Der Major sie wieder als korrekt ansieht?
Setze moderate = yes moderator = <irgend ein User> Damit laufen die Mails wenigstens nicht wieder auf die Liste zurück, sondern zum Moderator, der sie ja dann nicht zu genehmigen braucht.
Schau wie oben gezeigt ins Maillog rein, während sendmail den Kram rausschiebt. Wird alles nur einmal verschickt, oder auch dort schon mehrfach? Auch dort schon mehrfach (aber zeitversetzt um ca 30 Minuten)
Dann machs doch beim näxten Mal zB so: Mail dem Major in den Rachen werfen, und danach fetchmail anhalten. Dann können die Empfänger wenigstens keinen Unfug treiben. Oder Du machst ne Procmail-Regel, welche Dir alle suspekten Mails abfängt. Andy PS: was ich schon immer mal wissen wollte, aber nie zu fragen traute: Was heißt eigentlich das rc in fetchmailrc, procmailrc, rcpostfix usw.? Und was bedeuten die Abkürzungen /usr, /etc, /opt? Ist in diesem Thread OT, aber einen neuen Thread anfangen wäre wohl übertrieben ;)
Hi
-----Original Message----- From: Andy Feile [mailto:lists@feile.net]
Doofe Frage, wie kann ich es auf einer Kiste erzeugen, das die mail einfach zurück geht?
Setz einfach in der xxx.config:
reply_to = <irgend eine Mail-Adresse> Tja, in der Mail ist ein Reply-To: gesetzt. Und zwar nicht auf die Liste sondern auf den depp (mich), der den Major bedient :(
So wie ich das sehe, wird das Teil von manchen Hosts original an die Absende-Adresse zurück geschickt und ich hab keine Ahnung warum.
Damit verhinderst Du schon mal den gröbsten Unfug durch gedankenloses Replyen. Deswegen ist er drin
Und wie kann ich verhindern, das Der Major sie wieder als korrekt ansieht?
Setze
moderate = yes moderator = <irgend ein User> Hmmmmm. Die Einstellung 'moderate = yes' beisst sich mit der Sendebeschränkung durch eine andere Liste (hier announce.list) Wenn Du beides hast, dreht sich IMHO der Major im Kreis.
Damit laufen die Mails wenigstens nicht wieder auf die Liste zurück, sondern zum Moderator, der sie ja dann nicht zu genehmigen braucht. Leider nicht, siehe oben
Schau wie oben gezeigt ins Maillog rein, während sendmail den Kram rausschiebt. Wird alles nur einmal verschickt, oder auch dort schon mehrfach? Auch dort schon mehrfach (aber zeitversetzt um ca 30 Minuten)
Dann machs doch beim näxten Mal zB so: Mail dem Major in den Rachen werfen, und danach fetchmail anhalten. Dann können die Empfänger wenigstens keinen Unfug treiben. The Problem is, ich weiss nie, wann die Jungs anfangen die Mail an die Liste zu schicken. Und ich will nicht immer zuschauen müssen :))
PS: was ich schon immer mal wissen wollte, aber nie zu fragen traute:
Was heißt eigentlich das rc in fetchmailrc, procmailrc, rcpostfix usw.? Und was bedeuten die Abkürzungen /usr, /etc, /opt?
Ist in diesem Thread OT, aber einen neuen Thread anfangen wäre wohl übertrieben ;)
/usr bedeutet IMHO /user == Geraffel für den User /opt bedeutet optional == Unnötiger Müll, nicht zum Systemlauf nötig (das ist das Verzeichnis, bei dem ich mich dank KDE und SuSE immer nach einer Installation zurückhalten muss um kein rm -r /opt/* auszuführen *g*) Gruss Ralf
Andy Feile:
Doofe Frage, wie kann ich es auf einer Kiste erzeugen, das die mail einfach zurück geht?
Setz einfach in der xxx.config:
reply_to = <irgend eine Mail-Adresse>
N E I N ! Sorry. Aber an die Wand bin ich vor kurzem geklatscht. Es gibt Server, die das im Fehlerfall nicht beachten. Das Resultat ist eine üble Mailschwemme im endlos-Loop. Einer dieser Server langt schon, um die Kiste heißzumailen. Von absichtlichem Mißbrauch rede ich schon gar nicht. Man kommt leider nicht drum herum, das Teil anständig zu konfigurieren. Wenn wir so gar nicht drauf kommen, würde ich zumindest erstmal vorschlagen: Die Adressen der Empfänger sind eine simple Textdatei. Benenn die doch erstmal um und lege eine neue an, in der nur Du drin stehst. Dann kannst du in Frieden testen. Hast du vielleicht einen guten Draht zu einem der Empfänger, die das Problem haben? Vielleicht kannst du ja nur mit dem und dir Testnews schreiben. Ich werde irgendwie das Gefühl nicht los, daß das Problem ganz woanders liegt. Hattest du hier schonmal einen Mailheader gepostet? Von einer Mail, die dir um die Ohren geflogen ist? Gruß, Ratti
Hallo, * On Wed, Mar 20, 2002 at 07:08 PM (+0100), Ratti wrote:
reply_to = <irgend eine Mail-Adresse>
N E I N !
Sorry. Aber an die Wand bin ich vor kurzem geklatscht.
Es gibt Server, die das im Fehlerfall nicht beachten. Das Resultat ist eine üble Mailschwemme im endlos-Loop.
Ich denke, genau das kann passieren, wenn als "reply_to"-Adresse die Listen-Adresse selber angegeben wird. Ich habe aber die Mails in diesem Thread so verstanden, dass das gerade nicht gemeint ist.
Einer dieser Server langt schon, um die Kiste heißzumailen.
Klar. Gruß, Steffen
Hallo, Ratti:
Es gibt Server, die das im Fehlerfall nicht beachten. Das Resultat ist eine üble Mailschwemme im endlos-Loop.
Steffen Moser:
Ich denke, genau das kann passieren, wenn als "reply_to"-Adresse die Listen-Adresse selber angegeben wird.
Dann würde es sowieso loopen, wenn man es nicht anders verhindert (moderierte Liste, ...)
Ich habe aber die Mails in diesem Thread so verstanden, dass das gerade nicht gemeint ist.
Ich bezog mich darauf, daß es eben _keine_ Lösung ist, ein reply-to zu setzen. Beispiel aus meinem bedauerlichen Alltag. Folgende Mail verliess die Liste an über 1000 User: From: newsletter@firma.foo To: EMPFÄNGER_AUS_DATENBANK@ziel.foo Reply-To: listenverwalter@firma.foo Das sollte darin resultieren, daß menschliche Antworten ebenso wie Feedback nicht in die Liste gehen, sondern an den Verwalter. Von den über 1000 Empfängern waren geschätzt 80 nicht erreichbar. Also eigentlich: 80 Fehlermeldungen an den Verwalter. 2 Server schickten aber an die Liste zurück, statt an den Verwalter. (Bezeichnenderweise beide mit der gleichen Softwareversion des Mailservers...) Wenn man jetzt das Problem hat, daß der Eingangsfilter der Liste aufgrund zu simpel gestrickter RE diese Mail wieder als Listenfutter zulässt, dann hat man den Loop. Fazit: Mein Kommentar liefert keine Lösung. Er verwirft nur die Idee des "Reply-To", weil das nicht klappt. Gemein. ;-) Gruß, Ratti
Hi
-----Original Message----- From: Ratti [mailto:ratti@gesindel.de] Sorry. Aber an die Wand bin ich vor kurzem geklatscht.
Es gibt Server, die das im Fehlerfall nicht beachten. Das Resultat ist eine üble Mailschwemme im endlos-Loop.
Einer dieser Server langt schon, um die Kiste heißzumailen. Von absichtlichem Mißbrauch rede ich schon gar nicht. Man kommt leider nicht drum herum, das Teil anständig zu konfigurieren. Jep. Ich denke, das wird genau das Problem sein. So wie ich das interpretiere, sendet mein major eine Mail raus (an alle), diese wird dann von einem/mehreren Hosts wie oben beschreiben zurückgeschickt und das Spiel fängt von vorne an. Da die Mail initial von einer schreiberlaubten Emailadresse kam, hat major auch keinen Grund, sie nicht 'wieder' zu versenden, worauf wir wieder mal einen 'kleinen' Mailloop haben.
Aber, wie kann ich den major davor bewahren, in einen loop zu kommen????? <sehrratlos> Ich kann auch nicht hergehen, und die fetchmailsache abschalten, denn ich weiss nie, wann der newsletter kommt und bin seltener zuhause (leider).
Wenn wir so gar nicht drauf kommen, würde ich zumindest erstmal vorschlagen:
Die Adressen der Empfänger sind eine simple Textdatei. Benenn die doch erstmal um und lege eine neue an, in der nur Du drin stehst. Dann kannst du in Frieden testen.
Mit 'meinen' Adressen (alle echt gebastelt, auch welche bei web.de und hotmail (grusel)) funktioniert alles.
Hast du vielleicht einen guten Draht zu einem der Empfänger, die das Problem haben? Vielleicht kannst du ja nur mit dem und dir Testnews schreiben.
Wenn die Mails danebenlaufen, bekommen alle die Massenmails und ich alle schläge *schluchtzschluck*
Ich werde irgendwie das Gefühl nicht los, daß das Problem ganz woanders liegt. Hattest du hier schonmal einen Mailheader gepostet? Von einer Mail, die dir um die Ohren geflogen ist?
Kann ich Dir nochmal schicken. Indeed, ich denke, das da einer/mehrere der Empfängerhosts die Mail einfach wieder zum absender durchrouten, statt sie zuzustellen. Nur, wie ich da reagieren/es verhindern kann - keine Ahnung. Mir graust es scho vor dem näxten Newsletter. Der soll wohl zwischen Samstag und Montag verschickt werden ;(((((( Gruss Ralf
Hallo, Ralf Kayser:
Mir graust es scho vor dem näxten Newsletter. Der soll wohl zwischen Samstag und Montag verschickt werden ;((((((
Uuuuups... Holzhammervorschlag aus der Notlösungskiste: Per procmail einen X-Eintrag in den Mailheader machen. In Hochdeutsch etwa so: Wenn X-DEBAKEL enthalten: Mail verwerfen. Sonst: Mailheader X-DEBAKEL einfügen Resultat: - Mail wird vom Listeneigner abgeschickt. - Enthält nicht den Header X-DEBAKEL, bekommt ihn also verpasst, geht in die Liste. - Mail kommt (wie auch immer) zurück, enthält Header X-DEBAKEL, ab in die Tonne. Vielleicht Verfeinerung: Rückkommende Mail geht _nicht_ in die Tonne, sondern ins Postfach "MalGucken", dann sieht man auch gleich, woher die Mail zurückkommt. HarHar. Gruß, Ratti P.S.: Ich betrachte das nicht als Lösung, sondern als Notoperation.
Hallo, * On Wed, Mar 20, 2002 at 10:53 AM (+0100), Andy Feile wrote:
PS: was ich schon immer mal wissen wollte, aber nie zu fragen traute:
Was heißt eigentlich das rc in fetchmailrc, procmailrc, rcpostfix usw.?
Ich tippe mal auf "run control". Die Verzeichnisnamen wurden ja bereits erklärt. Gruß, Steffen
participants (4)
-
Andy Feile -
Ralf Kayser -
Ratti -
Steffen Moser