linux-l: weihnachtsmail via script?

[Jan-Benedict Glaw]

On Wed, Dec 15, 1999 at 08:29:03PM +0100, Oliver Hillmann wrote:
> On Wed, 15 Dec 1999, Jan-Benedict Glaw wrote:
> 
> > [..]
> > > # hier ein bissel Zeit lassen
> > > sleep 20
> > 
> > Warum warten? ...dann kommen (vor lauter Warten) die Mail noch zu spät an!
> > Eientlich können alle ernstzunehmenden MTAs (postfix, smail, qmail, exim,
> > vielleicht auch sendmail) mit tausenden von Mails umgehen. Der Trick ist,
> > anhand der Geschwindigkeit (wie viele KB..MB pro sek bekommen wir denn los-
> > getreten?) eben nicht die ganze Leitung plattzumachen. Dann geht's insgesamt
> 
> Solch ein Skript hat bei mir nach einigen hundert Mails eben mit
> fork()-Fehlern (Memory, File deskriptoren ausgegangen) schon die Grätsche
> gemacht, und das bei smail. Das problem ist aus meiner Sicht nicht, daß
> {smail,sendmail,postfix,..} das nicht kann, sondern daß das Skript
> /usr/lib/sendmail - vorauf das auch immer ein Symlink sein mag - forkt,
> dann das nächste, dann das nächste, und flux mehr solcher File
> Deskriptoren verschlingender Tochter-Prozesse am Laufen hat, als durch
> ulimit erlaubt wird... Das scheint mir kein spezielles MTA-Problem zu
> sein... 

...wundert mich...

> Ich weiß von anderen, denen es ähnlich ging :)
> 
> > schneller. ...und Limits wie ausgehende file descriptoren wurden schon immer
> > abgefangen. Die Mail geht das in die queue und kommt später wieder 'raus...
> 
> Schon immer abgefangen? Wann und von wem?

Design bei z.B. postfix und qmail ist ja, daß man die Mail einfach erstein-
mal in ein 'dropdir' wirft (-> das macht ei nkleines Programm), und daß die
Mails dann aus diesem dropdir von dem Programm, daß die Mails wirklich
versendet, eingesammelt werden. Bei alten sendmails (8.8.x und zurück...)
mag's sein, daß aufgrund des designs damit die Kiste leicht plattzubekommen
war, aber weder mit postfix, noch mit qmail, hib' ich sowas je wieder
"geschafft". (GMX macht z.B. (gepatchtes) qmail. Ein Freund von mir macht
die Verteilung der Mails für linux-kernel at vger.rutgers.edu für Deutschland.
Da kommen minütlich Mails rein, die dann an hunterte/tausende Leute gehen.
Die Kiste mag vielleicht eine Last von 8..12 bekommen (ein etwas betagter
Pentium), aber vo nSterben war da noch nie die Rede...).

Ich verteile nur ein paar kleinere Listen (bis knapp 200 Leute / Liste mit
nur einem/wenigen Dutzend postings pro Tag, dann aber meistens auf einem
Haufen), und Lastprobleme hatte ich (zumindest seit postfix) dann auch
nicht mehr. ...und die Kiste _ist_ an sich schon lahm...

Welche MTAs (und welche Versionen) hast Du denn so schon gekillt bekommen?
Mich wundert das etwas, weilnormalerweise solche Mails der Reihe nach (und
nicht parallel) in die queues gepackt werden:

cat mailadressen| while read ADRESSE; do echo "Hallo" mailx $ADRESSE; done

schichtet alle Mails der Reihe nach in die queues, und dann ist es nur noch
Sache eines (möglicherweise schlecht programmierten MTAs), die auszuteilen.
Es macht aber definitiv keinen Sinn, sofort für jede eingehende Mail zu
fork()en, da ja durchaus mehrere Mails mit gleicher Domain (zww. mit gleichem
MX) darunter sein könnten. Dann läßt sich die Mail nämlich in einem Rutsch
an alle Empfänger (auf einem MX) schicken. Sehe ich immer wieder wenn ich
Listen mit vielen GMXlern habe. Von einer auf die andere Sekunde sind 
100 Mails 'raus;)

...und 

echo "hallo" | mailx `cat mailadressen`

sollte die Mails ebenfalls der Reihe nach (und nicht parallel) in die 
queues einsortieren (lassen, wenn's ein dropdir gibt). Verfahren ab da wie
oben; ersteinmal alle 'raussuchen, die den selben MX haben...

MfG, JBG

-- 
Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!!
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 240 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/19991215/61e1bb87/attachment.sig>