[qmail] Wie remote delevery bei temprärer Internetverbindung auslösen?
Sebastian Niehaus
schon lange ein Dorn im Auge war, hatte ich nun an einen Austausch
gedacht und qmail installiert. Die Installation lief erstaunlich
glatt und prinzipiell scheint alles, was ich so brauche zu klappen.
Einziges Problem: wenn ich offline bin, versucht qmail nach seinem
eingebauten Schema auszuliefern, was natürlich zweckfrei ist. Wenn ich
dann nach längerer Pause online bin, werden die Intervalle vermutlich
so groß sein, daß qmail just in dem interessanten Zeitrahmen nicht
ausliefert.
Was ich suche:
· wie kann ich die Auslieferung anstossen ? - Ein Äquivalent zu
'sendmail-q'
· wie kann ich die Auslieferungsversuche unterbrechen?
So eine spontane Idee meinerseits wäre, diesen Prozeß, mit dem qmail
gestartet wird (/var/qmail/rc) totzumachen und ihn dann bei der
Einwahl neu zu starten. Klingt aber nach einem nicht gerade eleganten
Weg und wie er sich auf das Auslieferungsverhalten einwirkt, weiß ich
zugegebenermassen auch nicht.
Hat irgendjemand einen Pointer, ein RTFM oder ähnliches, was mir
weiterhelfen könnte? - Danke.
Sebastian
Sebastian Niehaus
> Was ich suche:
>
> · wie kann ich die Auslieferung anstossen ? - Ein Äquivalent zu
> 'sendmail-q'
>
> · wie kann ich die Auslieferungsversuche unterbrechen?
Tja, und wenn ich nicht nur die Überschriften von 'Life with qmail'
gelesen hätte (sondern auch den Inhalt ausführlicher), hätte ich Euch
wohl nicht mit dieser Frage nerven müssen. *gmbl*.
Sorry,
Sebastian
michael hufnagl
Sebastian Niehaus <niehaus-dated-1...@socha.net> wrote in
news:m3r8sph...@niehaus.dynodns.net:
[...]
su suchst serialmail. such da mal bei www.qmail.org danach.
cu
micha
Matthias Andree
[qmail für dialup, festes retry-Schema durchbrechen]
> Was ich suche:
>
> · wie kann ich die Auslieferung anstossen ? - Ein Äquivalent zu
> 'sendmail-q'
Je nach OS zum Beispiel:
killall -ALRM qmail-send (Linux)
pkill -ALRM qmail-send (neuere Solaris)
Oder von qmail wieder auf Postfix umsteigen, bevor Du qmail richtig
aufbohrst (was viel Zeit kostet) und installieren, in main.cf
defer_transports=smtp eintragen und wie bisher mit "sendmail -q" die
Auslieferung anstoßen - das erlaubt feinere Spam-Abweisung, ist
flexibler, einfacher handzuhaben, erheblich schneller und schont die
Festplatte.
Zusammen mit postconf -e defer_transports= bzw. defer_transports=smtp in
ip-up respektive ip-down wird das wirklich praktisch.
> · wie kann ich die Auslieferungsversuche unterbrechen?
Bei qmail? Gar nicht, Du kannst nur die Mail in eine Extra-Queue werfen,
wo sie u. U. bis zum St.-Nimmerleins-Tag liegenbleibt,
Hol' die Software hinter http://cr.yp.to/serialmail.html, und beachte
das "TOISP" file im Archiv.
--
Matthias Andree
"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." - Benjamin Franklin
Stefan Paletta
> [qmail für dialup, festes retry-Schema durchbrechen]
>> 'sendmail-q'
>
> Je nach OS zum Beispiel:
>
> killall -ALRM qmail-send (Linux)
>
> pkill -ALRM qmail-send (neuere Solaris)
Oder portabel:
svc -a /service/qmail/
>> · wie kann ich die Auslieferungsversuche unterbrechen?
> Bei qmail? Gar nicht, Du kannst nur die Mail in eine Extra-Queue werfen,
> wo sie u. U. bis zum St.-Nimmerleins-Tag liegenbleibt,
Quark.
# ip-up
rm -f /var/qmail/control/concurrencyremote
svc -t /service/qmail/
# ip-down
echo 0 > /var/qmail/control/concurrencyremote
svc -t /service/qmail/
Stefan
Matthias Andree
> * Matthias Andree wrote/schrieb/scripsit:
> > [qmail für dialup, festes retry-Schema durchbrechen]
> >> · wie kann ich die Auslieferung anstossen ? - Ein Äquivalent zu
> >> 'sendmail-q'
> >
> > Je nach OS zum Beispiel:
> >
> > killall -ALRM qmail-send (Linux)
> >
> > pkill -ALRM qmail-send (neuere Solaris)
>
> Oder portabel:
>
> svc -a /service/qmail/
Woher willst Du wissen, daß qmail unter supervise läuft?
Soviel zum Thema "portabel".
> # ip-up
> rm -f /var/qmail/control/concurrencyremote
> svc -t /service/qmail/
>
> # ip-down
> echo 0 > /var/qmail/control/concurrencyremote
> svc -t /service/qmail/
<IRONIE>Sehr sinnvoll </IRONIE> (außerdem willst Du svc -h).
Man nimmt normalerweise an, daß der Dialup seine Mail schnell und mit
wenig Overhead und Redundanz loswerden will, und da qmail-remote der
falsche Client, weil er z. B. kein PIPELINING redet, und weil Mail mit
mehreren Empfängern auch ohne VERP einmal je Empfänger verschickt wird
-- alles Sachen, die bei serialmail nicht passieren.
Stefan Paletta
> Stefan Paletta <ste...@world.wronline.de> writes:
>> Oder portabel:
>>
>> svc -a /service/qmail/
>
> Woher willst Du wissen, daß qmail unter supervise läuft?
Tut's wahrscheinlich nicht - sollte es aber.
Der geneigte Leser mag evtl. den Pfad anpassen, wenn er
eine alte Version daemontools verwendet.
>> # ip-down
>> echo 0 > /var/qmail/control/concurrencyremote
>> svc -t /service/qmail/
>
><IRONIE>Sehr sinnvoll </IRONIE> (außerdem willst Du svc -h).
Was soll daran nicht sinnvoll sein?
SIGHUP nutzt nichts, weil ein ungepatchtes qmai-send concurrency*
daraufhin nicht neu liest.
> Man nimmt normalerweise an, daß der Dialup seine Mail schnell und mit
> wenig Overhead und Redundanz loswerden will, und da qmail-remote der
> falsche Client, weil er z. B. kein PIPELINING redet, und weil Mail mit
> mehreren Empfängern auch ohne VERP einmal je Empfänger verschickt wird
> -- alles Sachen, die bei serialmail nicht passieren.
Letztere Faehigkeit fehlt auch serialmail (und dir sollte klar sein,
dass schon qmail-local dies verhindert).
Meiner Erfahrung nach ist ein zuverlaessiges serialmail setup (das hast
du ja schon spoettisch angedeutet) ungleich komplizierter einzurichten
als mein Vorschlag - dafuer opfere ich gerne diesen recht theoretischen
Vorteil.
Stefan
Sebastian Niehaus
[Ersteinmal Danke für die Rückmeldungen]
[...]
> > > killall -ALRM qmail-send (Linux)
> > >
> > > pkill -ALRM qmail-send (neuere Solaris)
> >
> > Oder portabel:
> >
> > svc -a /service/qmail/
>
> Woher willst Du wissen, daß qmail unter supervise läuft?
Ist hier in der Tat so (supervise war nach - glaube ich - Deiner
Empfehlung ohnehin schon installiert.)
[...]
> Man nimmt normalerweise an, daß der Dialup seine Mail schnell und
> mit wenig Overhead und Redundanz loswerden will, und da qmail-remote
> der falsche Client, weil er z. B. kein PIPELINING redet, und weil
> Mail mit mehreren Empfängern auch ohne VERP einmal je Empfänger
> verschickt wird
Da hier selten Mails mit mehreren Empfängern losgehen, sollte hier
kein großer Unterschied entstehen.
> -- alles Sachen, die bei serialmail nicht passieren.
Von serialmail hält mich ab, daß ich nicht über einen Smarthost gehe.
Sebastian
Matthias Andree
> SIGHUP nutzt nichts, weil ein ungepatchtes qmai-send concurrency*
> daraufhin nicht neu liest.
Hrmpf. Talk about inconsistent code. Mit diesem Einwand riecht's wohl
so, als wollte man am sinnvollsten qmail-remote mal RFC-2197 vorlesen.
> > Man nimmt normalerweise an, daß der Dialup seine Mail schnell und mit
> > wenig Overhead und Redundanz loswerden will, und da qmail-remote der
> > falsche Client, weil er z. B. kein PIPELINING redet, und weil Mail mit
> > mehreren Empfängern auch ohne VERP einmal je Empfänger verschickt wird
> > -- alles Sachen, die bei serialmail nicht passieren.
>
> Letztere Faehigkeit fehlt auch serialmail (und dir sollte klar sein,
> dass schon qmail-local dies verhindert).
Das ist leider wahr, hatte ich nicht bedacht. Hier müßte man in der Tat
qmail-queue etwas verwursten, daß es SMTP PIPELINING redet (und so eine
Art qmail-smtpc nach qmail-qmqpc-Vorbild bauen) -- oder einfach nicht
qmail nehmen.
> Meiner Erfahrung nach ist ein zuverlaessiges serialmail setup (das hast
> du ja schon spoettisch angedeutet) ungleich komplizierter einzurichten
> als mein Vorschlag - dafuer opfere ich gerne diesen recht theoretischen
> Vorteil.
Moment, ich habe nicht gesagt, daß das eo ipso unzuverlässig ist. qmail
an sich ist komplex einzurichten, das hat mit serialmail nichts zu
tun. Unter diesen Voraussetzungen scheint auf den ersten Blick Deine
Lösung die gangbarste zu sein, allein, sie hat ein essentielles Problem:
wer qmail auf dem Hub für ein LAN laufen läßt, schießt sich damit die
lokale Mailzustellung per SMTP gleich mit ab. Gleichzeitig ist das
qmail-Problem "zwei Leute derselben Domain => zwei SMTP-Sessions mit
selber Mail" aber nach wie vor vorhanden.
Was lehrt uns das? qmail nur mit Flatrate oder bei extrem niedrigem
Mailaufkommen.
Stefan Paletta
> Das ist leider wahr, hatte ich nicht bedacht. Hier müßte man in der Tat
> qmail-queue etwas verwursten, daß es SMTP PIPELINING redet (und so eine
> Art qmail-smtpc nach qmail-qmqpc-Vorbild bauen) -- oder einfach nicht
> qmail nehmen.
Leidest du oefters unter so schlimmen Alptraeumen?
> Moment, ich habe nicht gesagt, daß das eo ipso unzuverlässig ist.
| Bei qmail? Gar nicht, Du kannst nur die Mail in eine Extra-Queue werfen,
| wo sie u. U. bis zum St.-Nimmerleins-Tag liegenbleibt,
Die Aussage ist ja gar nicht mal so falsch - das Konzept mit der Maildir
gefaellt mir gar nicht - deshalb mein anderer Vorschlag.
> qmail
> an sich ist komplex einzurichten, das hat mit serialmail nichts zu
> tun.
``LKW-Fahren an sich ist komplex.''
> Unter diesen Voraussetzungen scheint auf den ersten Blick Deine
> Lösung die gangbarste zu sein, allein, sie hat ein essentielles Problem:
> wer qmail auf dem Hub für ein LAN laufen läßt, schießt sich damit die
> lokale Mailzustellung per SMTP gleich mit ab.
Matthias, hab etwas Phantasie.. In dem Falle zwei Instanzen qmail, fuer jede
Aufgabe eine. _Dieses_ Problem ist auch noch mit postfix und defer_transports
das selbe, nicht wahr? [1]
> Gleichzeitig ist das
> qmail-Problem "zwei Leute derselben Domain => zwei SMTP-Sessions mit
> selber Mail" aber nach wie vor vorhanden.
cf. RFC1925 2. (7a)
> Was lehrt uns das? qmail nur mit Flatrate oder bei extrem niedrigem
> Mailaufkommen.
ROTFL ;>
Ste'Those who do not understand UUCP...'fan
[1] IIRC kann man einen zweiten smtp transport unter anderem Namen anlegen
und nur diesen deferred setzen
Matthias Andree
> * Matthias Andree wrote/schrieb/scripsit:
> > Das ist leider wahr, hatte ich nicht bedacht. Hier müßte man in der Tat
> > qmail-queue etwas verwursten, daß es SMTP PIPELINING redet (und so eine
> > Art qmail-smtpc nach qmail-qmqpc-Vorbild bauen) -- oder einfach nicht
> > qmail nehmen.
>
> Leidest du oefters unter so schlimmen Alptraeumen?
Bitte? QMail ist halbgar.
> > Unter diesen Voraussetzungen scheint auf den ersten Blick Deine
> > Lösung die gangbarste zu sein, allein, sie hat ein essentielles Problem:
> > wer qmail auf dem Hub für ein LAN laufen läßt, schießt sich damit die
> > lokale Mailzustellung per SMTP gleich mit ab.
>
> Matthias, hab etwas Phantasie.. In dem Falle zwei Instanzen qmail, fuer jede
> Aufgabe eine.
Überflüssige Ressourcenverschwendung, weil die Kiste die Aufgabe nicht
anders erfüllen kann?
> _Dieses_ Problem ist auch noch mit postfix und defer_transports das
> selbe, nicht wahr? [1]
Nein, ist es nicht, wie Deine Fußnote andeutet:
http://mandree.home.pages.de/postfix/dialup.html
> > Gleichzeitig ist das
> > qmail-Problem "zwei Leute derselben Domain => zwei SMTP-Sessions mit
> > selber Mail" aber nach wie vor vorhanden.
>
> cf. RFC1925 2. (7a)
Nein. Postfix existiert.
> > Was lehrt uns das? qmail nur mit Flatrate oder bei extrem niedrigem
> > Mailaufkommen.
>
> ROTFL ;>
Das ist nicht lustig, sondern einer der Gründe, warum bei mir kein qmail
mehr läuft: es verschwendet Bandbreite.
Stefan Paletta
> Stefan Paletta <ste...@world.wronline.de> writes:
>> * Matthias Andree wrote/schrieb/scripsit:
>> > Das ist leider wahr, hatte ich nicht bedacht. Hier müßte man in der Tat
>> > qmail-queue etwas verwursten, daß es SMTP PIPELINING redet (und so eine
>> > Art qmail-smtpc nach qmail-qmqpc-Vorbild bauen) -- oder einfach nicht
>> > qmail nehmen.
>>
>> Leidest du oefters unter so schlimmen Alptraeumen?
>
> Bitte? QMail ist halbgar.
Sortier doch erstmal dein Vokabular, bevor du sowas verbreitest.
Wir sprachen davon, dass qmail unfaehig ist, "RCPT TO"-Aggregation zu
betreiben - das hat mit ESMTP PIPELINING nicht die Bohne was zu tun.[1]
Die Ursache des Fehlens von "RCPO TO"-Aggregation liegt in qmail-send,
nicht aber in qmail-queue, was _natuerlich_ mehrere Empfaenger pro Message
unterstuetzt, und noch nicht mal in qmail-remote (das was du dir oben als
qmail-smtpc konstruierst), welches naemlich mehrere Empfaenger schon
unterstuetzt, aber nie so aufgerufen wird.
>> Matthias, hab etwas Phantasie.. In dem Falle zwei Instanzen qmail, fuer jede
>> Aufgabe eine.
>
> Überflüssige Ressourcenverschwendung, weil die Kiste die Aufgabe nicht
> anders erfüllen kann?
``Profile. Don't Speculate.'', Matthias. Zwei Instanzen qmail verbrauchen nicht
mehr Speicher als ein postfix.
>> > Was lehrt uns das? qmail nur mit Flatrate oder bei extrem niedrigem
>> > Mailaufkommen.
>>
>> ROTFL ;>
>
> Das ist nicht lustig, sondern einer der Gründe, warum bei mir kein qmail
> mehr läuft: es verschwendet Bandbreite.
Ich formuliere mal so um, dass es nicht allzu peinlich verallgemeinert ist:
Unter bestimmten Umstaenden (grosse Mails mit jeweils mehreren Empfaengern,
die am selben MX abgeliefert werden koennten) uebertraegt es ein Vielfaches
der Datenmenge des optimalen Falls und nutzt deshalb die zur Verfuegung
stehende Bandbreite schlecht, wenn diese zu gering ist.
Stefan
[1] ESMTP PIPELINING wird von qmail-smtpd unterstuetzt
pa...@kleiner.scot.de
> Stefan Paletta <ste...@world.wronline.de> writes:
>> SIGHUP nutzt nichts, weil ein ungepatchtes qmai-send concurrency*
>> daraufhin nicht neu liest.
> Hrmpf. Talk about inconsistent code. Mit diesem Einwand riecht's wohl
> so, als wollte man am sinnvollsten qmail-remote mal RFC-2197 vorlesen.
Hier kann ich leider keinerlei Bezug erkennen.
> Was lehrt uns das? qmail nur mit Flatrate oder bei extrem niedrigem
> Mailaufkommen.
Nein, ich empfehle qmail gerade bei grossen Mailaufkommen und Server fuer
Mailing Lists. Bei grossen Mailaufkommen wird die 'Verschwendung' von
Bandbreite durch nicht praktiziertes Multi-RCPT normalerweise
verschwindend gering, die Performance und Sicherheit steigt, da kein
Code zum parsen von RCPT TO existiert.
In Sonderfaellen, wo oftmals _grosse_ mails an viele Empfaenger mit
gleichen MX verschickt werden, sollte man einen anderen MTA waehlen, wenn
man qmail nicht vollends beherrscht.
Gerrit.
pa...@smarden.org
>> Aufgabe eine.
> anders erfuellen kann?
Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle moeglichen
Sonderfaelle Code in das Project integriert wird, der dann bei den wenigsten
Installation benoetigt wird, aber ueberall vorhanden ist.
Gerrit.
Matthias Andree
> >> > Das ist leider wahr, hatte ich nicht bedacht. Hier müßte man in der Tat
> >> > qmail-queue etwas verwursten, daß es SMTP PIPELINING redet (und so eine
> >> > Art qmail-smtpc nach qmail-qmqpc-Vorbild bauen) -- oder einfach nicht
> >> > qmail nehmen.
> >>
> >> Leidest du oefters unter so schlimmen Alptraeumen?
> >
> > Bitte? QMail ist halbgar.
>
> Sortier doch erstmal dein Vokabular, bevor du sowas verbreitest.
Ich wiederhol's nochmal. Qmail ist halbgar. Wenn Du Details dazu haben
willst, was gängig fehlt, benutz' bitte groups.google.com.
> Wir sprachen davon, dass qmail unfaehig ist, "RCPT TO"-Aggregation zu
> betreiben - das hat mit ESMTP PIPELINING nicht die Bohne was zu
> tun.[1]
Nicht? Ohne RCPT-TO-Aggregation ist es in der Tat wenig hilfreich.
> Die Ursache des Fehlens von "RCPO TO"-Aggregation liegt in qmail-send,
> nicht aber in qmail-queue, was _natuerlich_ mehrere Empfaenger pro Message
> unterstuetzt,
Weswegen man qmail-queue als spätesten Punkt nehmen kann, an dem man
Mail mit mehreren Empfängern exportieren kann.
> und noch nicht mal in qmail-remote (das was du dir oben als
> qmail-smtpc konstruierst), welches naemlich mehrere Empfaenger schon
> unterstuetzt, aber nie so aufgerufen wird.
qmail-remote unterstützt kein PIPELINING, und das ganze Geraffel könnte
man mit so einem qmail-smtpc erschießen - Smarthost vorausgesetzt. Man
kann auch gleich einen MTA nehmen, der die Features, die man sucht, ohne
"zweite Installation" erledigt.
> ``Profile. Don't Speculate.'', Matthias. Zwei Instanzen qmail
> verbrauchen nicht mehr Speicher als ein postfix.
Speicher ist nicht die einzige Ressource. Das Zeug will aufgesetzt und
unterhalten sein -- und das exzessiv umständliche queueing erledigt man
mit einer zweiten Installation sicher nicht.
> [1] ESMTP PIPELINING wird von qmail-smtpd unterstuetzt
Ja, weil's trivial ist, eine Zeile in die EHLO-Antwort zu schreiben
(mehr braucht's nicht, wenn man nicht forkt), es wird aber nicht von
qmail-remote unterstützt, aus geradezu lächerlichen Gründen. Dabei ist
der nötige Code da, in serialsmtp.
Matthias Andree
> Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle moeglichen
> Sonderfaelle Code in das Project integriert wird, der dann bei den wenigsten
> Installation benoetigt wird, aber ueberall vorhanden ist.
Es ist kein Sonderfall, sondern reguläres Mailrouting anhand
"transport_maps" -- bzw. einfach ein Flag "dieser `Mailer' läuft nur bei
sendmail -q". Falschaussagen über MTAs, die Du nicht richtig kennst,
machen qmail nicht besser.
Matthias Andree
> > Was lehrt uns das? qmail nur mit Flatrate oder bei extrem niedrigem
> > Mailaufkommen.
>
> Nein, ich empfehle qmail gerade bei grossen Mailaufkommen und Server fuer
> Mailing Lists.
Dann nimm mal große Mailinglists (z. B. Bugtraq): dort ist qmail
jämmerlich verreckt. Fehlender Support für Softupdates tat sein übriges.
Wer seine Augen davor verschließt, beweist damit nicht mehr als seine
Lernresistenz.
> Bei grossen Mailaufkommen wird die 'Verschwendung' von Bandbreite
> durch nicht praktiziertes Multi-RCPT normalerweise verschwindend
> gering, die Performance und Sicherheit steigt, da kein Code zum parsen
> von RCPT TO existiert.
Und der Overhead (Context switch wie Packetzahl) durch fehlendes ESMTP
PIPELINING in qmail-remote wächst auch. Du bist unseriös, wenn Du qmail
für solche Zwecke empfiehlst.
"Sicherheit" ist vorhanden. Die Releaseversion von Postfix hat keine
bekannten Sicherheitsprobleme.
"Performance", ja... so eine tolle Performance, daß Bugtraq sich
außerstande sieht, weiterhin qmail zu benutzen und auf Postfix umsteigt,
das dann "mal eben" die Wartezeit auf den Mailversand erheblich
verringert und besser skaliert.
http://mandree.home.pages.de/postfix/bench2.html
167:25 (Mails/s jeweils, Mails mit 10 Empfängern im LAN) für
Postfix:qmail spricht wohl für sich.
http://msgs.SecurePoint.com/cgi-bin/get/postfix0107/138.html
http://archives.neohapsis.com/archives/postfix/2001-07/0457.html
(derselbe Artikel)
> In Sonderfaellen, wo oftmals _grosse_ mails an viele Empfaenger mit
> gleichen MX verschickt werden, sollte man einen anderen MTA waehlen, wenn
> man qmail nicht vollends beherrscht.
Das hat mit Beherrschen nichts zu tun, sondern mit mangelnder Eignung
von qmail für alle Kisten jenseits one-to-one-Mailings über schnelle
Links (und selbst die sind besser beraten, wenn sie serialmail auf einen
guten Smarthost statt qmail-remote benutzen).
Gerrit, akzeptier' bitte endlich, daß qmail 1.03 seit Jahren überholt
ist. Niemand bestreitet die Sicherheit, es ist aber qmail nicht der
einzige sichere MTA, es ist aber nach meinen bisherigen Erkenntnissen
der langsamste. Durch FUD und falsche Beratung wird weder qmail besser
noch Deinen Kunden gedient. Was qmail2 bringt, bleibt abzuwarten, ich
will nicht ausschließen, daß es ERHEBLICH schneller ist als qmail, aber
ich hab' bisher keins gesehen.
BTW, Realname wäre nett.
Gerrit Pape
>> Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle moeglichen
>> Sonderfaelle Code in das Project integriert wird, der dann bei den wenigsten
>> Installation benoetigt wird, aber ueberall vorhanden ist.
> sendmail -q". Falschaussagen ueber MTAs, die Du nicht richtig kennst,
> machen qmail nicht besser.
Lerne endlich lesen. Ich habe keine Falschaussage ueber irgendeinen MTA
gemacht (was hat Matthias hier schon wieder interpretiert?).
Warum haeltst du dich nicht einfach aus threads, die qmail zum Thema haben,
heraus, anstatt andauernd weinerlich deine Meinung zu wiederholen. qmail
scheint dich ja echt zu belasten.
Gerrit.
Gerrit Pape
> <pa...@kleiner.scot.de> writes:
>> > Was lehrt uns das? qmail nur mit Flatrate oder bei extrem niedrigem
>> > Mailaufkommen.
>>
>> Nein, ich empfehle qmail gerade bei grossen Mailaufkommen und Server fuer
>> Mailing Lists.
> jaemmerlich verreckt. Fehlender Support fuer Softupdates tat sein uebriges.
> Wer seine Augen davor verschliesst, beweist damit nicht mehr als seine
> Lernresistenz.
>> Bei grossen Mailaufkommen wird die 'Verschwendung' von Bandbreite
>> durch nicht praktiziertes Multi-RCPT normalerweise verschwindend
>> gering, die Performance und Sicherheit steigt, da kein Code zum parsen
>> von RCPT TO existiert.
> fuer solche Zwecke empfiehlst.
> Das hat mit Beherrschen nichts zu tun, sondern mit mangelnder Eignung
Deine Meinung. Ich mag dein Wortwahl nicht.
> Gerrit, akzeptier' bitte endlich, dass qmail 1.03 seit Jahren ueberholt
Nein. Wie du weisst, wird qmail heutzutage mehr eingesetzt als postfix.
Akzeptiere endlich, dass es auch andere Meinungen gibt.
> der langsamste. Durch FUD und falsche Beratung wird weder qmail besser
> noch Deinen Kunden gedient. Was qmail2 bringt, bleibt abzuwarten, ich
Weder betreibe ich FUD, noch falsche Beratung, unterlasse diese
falschen Unterstellungen, du hast mir schon genug Zeit gekostet.
> BTW, Realname waere nett.
Ja. Gerrit.
Matthias Andree
> Deine Meinung. Ich mag dein Wortwahl nicht.
Dein Problem. qmail ist "sicher", der Rest des qmail-advertisings ist
angesichts der weiterentwickelten Konkurrenz in sich zusammengefallen
wie ein Kartenhaus.
> > Gerrit, akzeptier' bitte endlich, dass qmail 1.03 seit Jahren ueberholt
>
> Nein. Wie du weisst, wird qmail heutzutage mehr eingesetzt als
> postfix.
Behauptet Dan, von unabhängigen Quellen liegen mir keine Zahlen
vor. Über die Einsatzhäufigkeit (vor allem in Verbindung mit gewissen
Quellen) läßt sich aber kein Rückschluß auf die Qualität ziehen. Beweis:
ChangeLog zu Sendmail 8.12.1.
> > der langsamste. Durch FUD und falsche Beratung wird weder qmail besser
> > noch Deinen Kunden gedient. Was qmail2 bringt, bleibt abzuwarten, ich
>
> Weder betreibe ich FUD, noch falsche Beratung, unterlasse diese
> falschen Unterstellungen, du hast mir schon genug Zeit gekostet.
Es ist keine falsche Unterstellung; daß qmail langsam und für große
Mailinglisten nicht die erste Wahl ist, ist mit Zahlen (nicht nur
meinen) belegt.
Nun hast Du das Profil, das alle DJB-Advokaten mit "profile, don't
speculate" haben wollen, und es schmeckt Dir nicht, aber ich fühle mich
für den Erhalt Deines Weltbilds nicht verantwortlich.
Matthias Andree
> Matthias Andree <matthia...@gmx.de> wrote:
> > <pa...@smarden.org> writes:
>
> >> Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle
> >> moeglichen Sonderfaelle Code in das Project integriert wird, der
> >> dann bei den wenigsten Installation benoetigt wird, aber ueberall
> >> vorhanden ist.
>
> > sendmail -q". Falschaussagen ueber MTAs, die Du nicht richtig
> > kennst, machen qmail nicht besser.
>
> Lerne endlich lesen. Ich habe keine Falschaussage ueber irgendeinen
> MTA gemacht (was hat Matthias hier schon wieder interpretiert?).
Nein, nicht über irgendeinen, sondern über alle anderen.
> Warum haeltst du dich nicht einfach aus threads, die qmail zum Thema
> haben, heraus, anstatt andauernd weinerlich deine Meinung zu
> wiederholen. qmail scheint dich ja echt zu belasten.
qmail belastet mich nicht, Deine wiederholten unhaltbaren Behauptungen
über qmail, das hier von Dir meilenweit über den Klee gelobt wird, sind
eine Belastung für alle diejenigen, die eine objektive Wahl des MTA
anstreben.
Die besondere Eignung von qmail für große Mailinglisten wird von Dir
allenfalls durch Relativierungen der Einwände oder Belege, daß andere
MTA besser leisten als Mailinglisten-Backend, zu rechtfertigen gesucht,
Fakten werden abgeschoben oder ignoriert, sie können aber nicht von Dir
widerlegt werden. "profile, don't speculate". Das Bugtraq-Beispiel
taucht in Deinen Äußerungen nicht auf. Warum bloß nicht?
Ob es Codeanalyse oder Empirie ist, Du bist keinem Argument zugänglich.
Du bist offenkundig lernresistent. Es empfiehlt sich für Dich, sich
andere Mailer anzusehen, und dann zu entscheiden, ob qmail wirklich noch
die erste Wahl ist oder es besser beim persönlichen und objektiv nicht
zu beanstandenden "ich mag qmail, weil ich's gut kenne" in Deinen
Äußerungen bleibt.
Stefan Paletta
> Es ist keine falsche Unterstellung; daß qmail langsam und für große
> Mailinglisten nicht die erste Wahl ist, ist mit Zahlen (nicht nur
> meinen) belegt.
Ausgehend von <http://mandree.home.pages.de/postfix/bench2.html>:
Deine Messungen erscheinen groesstenteils sinnvoll und die Zahlen sind in
dem Rahmen wie ich sie erwarte. Das Problem ist nur: was du gemessen hast,
hat keinerlei Relevanz 'fuer grosse Mailinglisten'. 1000 Mails mit je einem
Empfaenger oder 1000 Mails mit je 10 Empfaengern sind weitest moeglich von
'grosse Mailinglisten' entfernt. Warum hast du nicht z.B. eine Mail mit
20.000 Empfaengern bis 10 Mails mit je 200.000 Empfaengern gemessen?
Du gibst ausserdem keine Auskunft darueber, mit welcher concurrencyremote
qmail lief, bzw. welche Anzahl Verbindungen den anderen MTA gestattet war.
Aus der Beschreibung 'built from ports' muss ich annehmen, dass die vor-
gegebene, recht geringe concurrencyremote von 20 beibehalten wurde.
Stefan
Stefan Paletta
> Dann nimm mal große Mailinglists (z. B. Bugtraq): dort ist qmail
> jämmerlich verreckt.
Ich moechte nicht ausschliessen, dass die Leute wussten was sie taten,
als sie das qmail alle Empfaenger einzeln an zwei postfixen relayen
liessen, mir erscheint dieses Setup aber doch arg von Unkenntnis ge-
plagt. Solange niemand erklaert, warum ein qmail die Last nicht alleine
hat bewaeltigen koennen (und der von dir genannte Artikel sagt ziemlich
deutlich, dass sie das nie produktiv versucht haben), haben sie offen-
sichtlich qmail falsch eingesetzt.
Da die genauen Umstaende niemand von uns kennt, sollten wir mit dieser
Geschichte sehr vorsichtig sein.
> "Sicherheit" ist vorhanden. Die Releaseversion von Postfix hat keine
> bekannten Sicherheitsprobleme.
Das ist voellig irrelevant. Das einzige was zaehlt, ist die Wahrschein-
lichkeit, dass ueberhaupt welche vorhanden sind. Das kann man z.B. ab-
schaetzen am Code- und Featureumfang, an der Historie des Autors und an
der Historie des Codes. Dabei sieht postfix relativ blass aus.
Stefan
Gerrit Pape
>> Deine Meinung. Ich mag dein Wortwahl nicht.
> Dein Problem. qmail ist "sicher", der Rest des qmail-advertisings ist
> angesichts der weiterentwickelten Konkurrenz in sich zusammengefallen
> wie ein Kartenhaus.
>> > Gerrit, akzeptier' bitte endlich, dass qmail 1.03 seit Jahren ueberholt
>>
>> Nein. Wie du weisst, wird qmail heutzutage mehr eingesetzt als
>> postfix.
> Behauptet Dan, von unabhaengigen Quellen liegen mir keine Zahlen
> vor. Ueber die Einsatzhaeufigkeit (vor allem in Verbindung mit gewissen
> Quellen) laesst sich aber kein Rueckschluss auf die Qualitaet ziehen. Beweis:
> ChangeLog zu Sendmail 8.12.1.
Deine Meinung. An die, die eine aktuelle Studie interessiert (3.10.):
http://cr.yp.to/surveys.html
>> > der langsamste. Durch FUD und falsche Beratung wird weder qmail besser
>> > noch Deinen Kunden gedient. Was qmail2 bringt, bleibt abzuwarten, ich
>>
>> Weder betreibe ich FUD, noch falsche Beratung, unterlasse diese
>> falschen Unterstellungen, du hast mir schon genug Zeit gekostet.
Ich _unterstreiche_ dieses nocheinmal, du hast mir etwas unterstellt, aber
darauf nicht geantwortet.
> Es ist keine falsche Unterstellung; dass qmail langsam und fuer grosse
> Mailinglisten nicht die erste Wahl ist, ist mit Zahlen (nicht nur
> meinen) belegt.
Deine Meinung. An die, die es interessiert:
http://www.qmail.org/top.html
Der fuenfte Absatz listet ein paar sites, die qmail benutzen.
Ich habe auch niemals angezweifelt, dass es schnellere MTAs gibt, trotzdem
empfehle ich qmail gerade bei grossen Mailaufkommen und Server fuer Mailing
Lists. Es gibt noch andere Faktoren als Schnelligkeit.
Matthias, ich habe keine Lust mit dir darueber zu diskutieren.
> Nun hast Du das Profil, das alle DJB-Advokaten mit "profile, don't
> speculate" haben wollen, und es schmeckt Dir nicht, aber ich fuehle mich
> fuer den Erhalt Deines Weltbilds nicht verantwortlich.
Da das mal wieder persoenlich angreifend ist, versuche ich auf die
Objektivitaet der Leserschaft zu vertrauen.
Wenn mir hier irgendjemand auch nur eine Aussage meinerseits, die irgendwie
"profile, don't speculate" ist, aufzeigen kann, stelle ich mich dem gerne,
mir ist keine bekannt.
Matthias, wenn du jetzt noch irgendwelche sachlichen Einwaende zu meine
original Posting <9phidc$l12$1...@bolzen.all.de> hast, meinetwegen sprich,
sonst bitte schweig, ich habe mit dir persoenlich nichts zu tun und will es
auch nicht.
Gerrit.
Gerrit Pape
>> Matthias Andree <matthia...@gmx.de> wrote:
>> > <pa...@smarden.org> writes:
>>
>> >> Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle
>> >> moeglichen Sonderfaelle Code in das Project integriert wird, der
>> >> dann bei den wenigsten Installation benoetigt wird, aber ueberall
>> >> vorhanden ist.
>>
>> > sendmail -q". Falschaussagen ueber MTAs, die Du nicht richtig
>> > kennst, machen qmail nicht besser.
>>
>> Lerne endlich lesen. Ich habe keine Falschaussage ueber irgendeinen
>> MTA gemacht (was hat Matthias hier schon wieder interpretiert?).
> Nein, nicht ueber irgendeinen, sondern ueber alle anderen.
Du bist unglaublich. Lies noch einmal meinen Satz, die vier Zeilen oben.
Hast du etwas daran auszusetzen? Dann erklaere mir, wo darin die
Falschaussage ist, ansonsten ziehe deine falsche Anschuldigung zurueck.
>> Warum haeltst du dich nicht einfach aus threads, die qmail zum Thema
>> haben, heraus, anstatt andauernd weinerlich deine Meinung zu
>> wiederholen. qmail scheint dich ja echt zu belasten.
> qmail belastet mich nicht, Deine wiederholten unhaltbaren Behauptungen
> ueber qmail, das hier von Dir meilenweit ueber den Klee gelobt wird, sind
Da das nun wieder persoenlich ist..
Wie bitte? Was fuer Drogen nimmst du? Zeige mir auch nur eine unhaltbare
Behauptung meinerseits ueber qmail auf!! Zitiere mich, wo ich qmail "ueber
den Klee lobe", mir ist nichts bekannt!! Du bist unverschaemt und wirst
wahrscheinlich wieder die falschen Beschuldigungen nicht zuruecknehmen.
> eine Belastung fuer alle diejenigen, die eine objektive Wahl des MTA
> anstreben.
Deine wiederholten unhaltbaren Behauptungen [0]
ueber qmail, das hier von Dir meilenweit ueber den Klee schlecht gemacht
wird, sind eine Belastung fuer alle diejenigen, die eine objektive Wahl des
MTA anstreben!
Das ist der einzige Grund, warum ich hier gelegentlich in die threads
springe, ich habe kein Interesse daran, irgendjemanden fuer einen dialup MTA
qmail zu empfehlen.
> Die besondere Eignung von qmail fuer grosse Mailinglisten wird von Dir
> allenfalls durch Relativierungen der Einwaende oder Belege, dass andere
> MTA besser leisten als Mailinglisten-Backend, zu rechtfertigen gesucht,
> Fakten werden abgeschoben oder ignoriert, sie koennen aber nicht von Dir
Auch das entbehrt wieder jeglicher Grundlage und ist persoenlich angreifend,
ich habe deine Fakten -wenn du die meinst- weder abgeschoben, noch
ignoriert,
ueberpruefe dich selbst.
> widerlegt werden. "profile, don't speculate". Das Bugtraq-Beispiel
> taucht in Deinen Auusserungen nicht auf. Warum bloss nicht?
Weil ich keine Zeit und Lust, mit dir zu diskutieren, meine Erfahrungen
haben auch gezeigt, dass das wahrscheinlich nicht moeglich ist.
Fuer die, die es interessert: D J Bernstein, Author von qmail, hatte mal
eine persoenliche Auseinandersetzung mit Ben Greenbaum:
http://cr.yp.to/freebugtraq/greenbaum/01.txt , 02.txt, 03.txt, ..., 10.txt
Auch wenn es ausschliesslich technische Gruende hat, ist es nur _ein_
Beispiel.
> Ob es Codeanalyse oder Empirie ist, Du bist keinem Argument zugaenglich.
> Du bist offenkundig lernresistent. Es empfiehlt sich fuer Dich, sich
> andere Mailer anzusehen, und dann zu entscheiden, ob qmail wirklich noch
> die erste Wahl ist oder es besser beim persoenlichen und objektiv nicht
> zu beanstandenden "ich mag qmail, weil ich's gut kenne" in Deinen
> Aeusserungen bleibt.
Unverschaemt. Was ist deine Mission? Was hast du persoenlich mit mir zu tun?
Wer bist du, mir zu unterstellen, ich sei dies und das und lernresistent?
Du nimmst hier meine Postings, unterstellst meiner Person irgendwelche
obskure Sachen, beschreibst mich auf falsche und unverschaemte Weise,
verdrehst Worte oder interpretierst sie falsch, und machst mir auch noch
Empfehlungen. Ich brauch die nicht, ich habe hier in dieser Grruppe noch
niemals Hilfe gesucht.
Ich wiederhole:
Warum haeltst du dich nicht einfach aus threads, die qmail zum Thema
haben, heraus, anstatt andauernd weinerlich deine Meinung zu
wiederholen. qmail scheint dich ja echt zu belasten.
Lass mich auf jeden Fall in Ruhe, und unterlasse persoenliche Angriffe.
Wenn du noch sachliche Einwaende zu meinem original Posting
<9phiu8$l12$2...@bolzen.all.de>
"Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle moeglichen
Sonderfaelle Code in das Project integriert wird, der dann bei den wenigsten
Installation benoetigt wird, aber ueberall vorhanden ist."
hast, bitte ..., sonst schweig.
Gerrit.
[0]
http://groups.google.com/groups?q=matthias+andree+qmail&start=10&group=de.comm.software.mailserver&scoring=d&rnum=12&selm=m3ae0cwfj6.fsf%40emma1.emma.line.org
[qmail kotzt zu spaet ins Essen]
http://groups.google.com/groups?q=matthias+andree+qmail&group=de.comm.software.mailserver&scoring=d&rnum=10&selm=m3ae0276xf.fsf%40emma1.emma.line.org
qmail ist unertraeglich unter hoher Last und erwuergt sich mit der
umstaendlichen queue beim Preprocessing
http://groups.google.com/groups?q=g:thl2992531916d&selm=m3itfjnd8t.fsf%40emma1.emma.line.org
[postfix] hat Bugs nicht, die qmail hat.
http://groups.google.com/groups?q=g:thl2992531916d&selm=m3hev2kx1a.fsf%40emma1.emma.line.org
qmail ist nur einsetzbar, wenn man nicht nach Volumen bezahlt und eine
wirklich heftig boese schnelle Festplatte hat
http://groups.google.com/groups?selm=m3y9mui36a.fsf%40emma1.emma.line.org&output=gplain
Stefan Paletta
> Naja, viele Betreiber großer Mailinglisten migrieren von qmail in
> Richtung Postfix, z.B. freshmeat.net. Sowas tut man nicht aus Jux
> und Tollerei.
Wie naiv...
Solange ich die wirklichen Gruende nicht kenne, bin ich sehr
vorsichtig bei der Beurteilung. Manchen Leuten traue ich auch
zu, von qmail auf postfix umzustellen, nur weil die ``Lizenz''
von qmail nicht in ihr Weltbild passt.
Btw. CriticalPath setzt vermehrt Exchange statt ihres qmail
Derivates ein.
Stefan
Matthias Andree
> Ich moechte nicht ausschliessen, dass die Leute wussten was sie taten,
> als sie das qmail alle Empfaenger einzeln an zwei postfixen relayen
> liessen, mir erscheint dieses Setup aber doch arg von Unkenntnis ge-
> plagt.
Nein, dieses Setup rührt aus der "alle Empfänger einzeln"-Eigenschaft
von qmail her - die übrigens als Workaround für fehlendes MX-seitiges
VERP von ezmlm so "befohlen" wird.
Daß qmail unter hoher Last, vor allem mit großen Backlogs, aus der Kiste
nicht ausreichend performt, sieht man an der Existenz von Patches wie
dem big-todo oder big-concurrency, um nur zwei Beispiele zu
nennen. Willst Du 400 smtp-Clients? Sag's Postfix und Du hast sie. Kein
Patch nötig.
> Solange niemand erklaert, warum ein qmail die Last nicht alleine hat
> bewaeltigen koennen (und der von dir genannte Artikel sagt ziemlich
> deutlich, dass sie das nie produktiv versucht haben), haben sie offen-
> sichtlich qmail falsch eingesetzt. Da die genauen Umstaende niemand
> von uns kennt, sollten wir mit dieser Geschichte sehr vorsichtig sein.
Ja. Da Postfix aber letztlich nichts anderes macht als qmail, wenn es
hinter ezmlm sitzt, nämlich 1-zu-1-Mailings, ist die Frage, ob qmail
nicht doch etwas - sagen wir mal angestaubt - ist.
[Sicherheitsprobleme]
> Das ist voellig irrelevant. Das einzige was zaehlt, ist die Wahrschein-
> lichkeit, dass ueberhaupt welche vorhanden sind. Das kann man z.B. ab-
> schaetzen am Code- und Featureumfang, an der Historie des Autors und an
> der Historie des Codes. Dabei sieht postfix relativ blass aus.
So, tut es das, vor allem gemessen an Historie von Autor und Code? Dann
führ' mal ein paar Belege ins Feld oder schweig.
http://www.postfix.org/security.html
Bei qmail fängst Du vorn und hinten an zu patchen, wenn Du was brauchst,
aus den verschiedensten Quellen. Soviel zur Historie des Autors und des
Codes.
Ich halte Postfix nicht für unsicherer als qmail, obwohl es ein
komplexeres System ist. Es ersetzt - wie qmail - unter anderem String-,
und I/O-Libraries durch eigenen Code, hat vernünftiges Design (das
schließt chroot unprivilegierter Prozesse und "setgid genügt, wir
brauchen kein setuid" mit ein, das muß qmail beides noch lernen) und
/lesbaren/ Code. Ferner schießt man sich mit Konfigurationsfehlern oder
nicht so schnell in die Füße (rcpthosts fehlt => qmail ist promiskes
Relay)
Matthias Andree
> Ausgehend von <http://mandree.home.pages.de/postfix/bench2.html>:
> Deine Messungen erscheinen groesstenteils sinnvoll und die Zahlen sind in
> dem Rahmen wie ich sie erwarte. Das Problem ist nur: was du gemessen hast,
> hat keinerlei Relevanz 'fuer grosse Mailinglisten'. 1000 Mails mit je einem
> Empfaenger oder 1000 Mails mit je 10 Empfaengern sind weitest moeglich von
> 'grosse Mailinglisten' entfernt. Warum hast du nicht z.B. eine Mail mit
> 20.000 Empfaengern bis 10 Mails mit je 200.000 Empfaengern gemessen?
Weil ezmlm zum Beispiel genau das nicht tut, sondern zur VERP-Emulation
1-zu-1-Mailings macht.
> Du gibst ausserdem keine Auskunft darueber, mit welcher concurrencyremote
> qmail lief, bzw. welche Anzahl Verbindungen den anderen MTA gestattet
> war.
Der "andere MTA" ist da beschrieben, wie schnell der ist, auch:
smtp-sink, single-threaded, mit exzessiv großem listen(2)-Backlog, das
die Mail vom Netz liest und wegwirft, wie viele Mails das von
smtp-source, das ich benutzt habe, um die Mail ins System zu drücken,
abnimmt, ist im Benchmark mit angeführt.
Ein echter anderer MTA auf nur einem Host ist zu langsam, echte MTAs
könnte ich nehmen, wenn ich ein komplettes LAN mit Mail zukippen könnte,
ich habe aber nur einen Rechner hier (gut, es stehen noch mehr
drumherum, aber ich will da keinen 486SX mit einer Platte in den Weg
stellen, die Latenzzeiten über 20 ms erzeugt und max. 1,3 MB/s abnimmt)
> Aus der Beschreibung 'built from ports' muss ich annehmen, dass die vor-
> gegebene, recht geringe concurrencyremote von 20 beibehalten wurde.
Du würdest nicht wollen, daß ich daran drehe und den Test wiederhole,
dann sag' ich nämlich Postfix, es soll 1000 Mails auf einen Schlag
ausliefern, normal fängt es klein an und geht allmählich auf 10 hoch,
solange der Empfänger Mail abnehmen kann.
Allein, man wird kaum mehr als 40 oder 50 Verbindungen (bei Sendmail
erheblich weniger) gleichzeitig zu einem anderen Rechner bekommen, da
ist aber wieder das "es ist nur ein Zielrechner"-Problem.
Das Problem ist aber ohne nicht die concurrency in qmail, ich habe mir
während des Tests angesehen, wie viele Mails reingegangen und wie viele
rausgekomen waren, und die meiste Zeit liefen keiner bis ein
qmail-remote, das steht aber auch da: "(not visible from the table)
qmail's preprocessing is a real performance killer. The throughput ramps
up considerably after all mail has been preprocessed. (I did a separate
test I don't report above.)"
In diesem Test habe ich mir alle 15 s mit qmail-qshow angesehen, wie
groß die Queues sind, und dabei festgestellt, daß erst dann 20
qmail-remote laufen, sobald qmails Preprocessing abgeschlossen ist, das
ist aber erst geraume Zeit nach Ende des Einliefervorgangs der Fall und
betrifft nur noch die letzten Mails - wenn aber schon 3 oder 4 min um
sind, bevor die concurrency überhaupt interessant wird, macht's nicht
mehr viel aus, ob man 20 oder 120 zuläßt, ob dann aus der letzten halben
oder dreiviertel Minute 10 s werden oder 20 -- was macht das für den
Durchsatz noch?
Es lohnt sich wirklich, sich Postfix mal in Ruhe genau anzusehen, das
Ding ist "aus der Büchse" schon zügig, wenn man daran tunt, geht die
sprichwörtliche Post richtig ab.
Juergen P. Meier
>* Matthias Andree wrote/schrieb/scripsit:
[bugtraq]
>Da die genauen Umstaende niemand von uns kennt, sollten wir mit dieser
>Geschichte sehr vorsichtig sein.
ACK.
Aus der Bugtraq geschichte ist mangels genauerer Info's nichts herauszuholen.
Ich kann eben nur von meinen direkten Erfahrungen mit qmail sprechen,
und in der umgebung, wo qmail seinerzeit durch sendmail wegen performance
problemen beim abarbeiten einer einmal angesammelten Queue von >2000 mails
[was dann passiert, wenn mal fuer 5 minuten nichts mehr geht...]
ersetzt wurde. (damals fehlte noch erfahrung mit postfix)
Fuer dieses system (100k mails/tag, peak ueber 1h: kanpp 30000) war qmail
schlicht nicht faehig, ein performantes queuing verhalten zu zeigen.
Nein, patchen der sourcen kam nicht in Frage.
Heute wuerde ich dort postfix preferieren. Oder qmail mit entsprechenden
vom Author als potentiell gefaehrlich eingestuften patches, wenn
postfix dem kunden zu featurereich ist.
>> "Sicherheit" ist vorhanden. Die Releaseversion von Postfix hat keine
>> bekannten Sicherheitsprobleme.
>
>Das ist voellig irrelevant.
Das ist genau das, womit DJB wirbt.
Im gegensatz zu qmail ist eine Releaseversion von Postfix allerdings
Brauchbar.
> Das einzige was zaehlt, ist die Wahrschein-
>lichkeit, dass ueberhaupt welche vorhanden sind. Das kann man z.B. ab-
>schaetzen am Code- und Featureumfang, an der Historie des Autors und an
>der Historie des Codes. Dabei sieht postfix relativ blass aus.
Du hast das Lesen aus dem Kaffesatz und das analysieren von Sternbildern
vergessen. Ausserdem lassen sich derartige Wahrscheinlichkeitsaussagen
auch noch aus den Fingern saugen.
Es geht hier um Sicherheit, nicht um Wahrscheinlichkeit.
Juergen
--
J...@lrz.fh-muenchen.de
"This World is about to be Destroyed!"
Juergen P. Meier
>>> Nein. Wie du weisst, wird qmail heutzutage mehr eingesetzt als
>>> postfix.
>
>> Behauptet Dan, von unabhaengigen Quellen liegen mir keine Zahlen
>> vor. Ueber die Einsatzhaeufigkeit (vor allem in Verbindung mit gewissen
>> Quellen) laesst sich aber kein Rueckschluss auf die Qualitaet ziehen. Beweis:
>> ChangeLog zu Sendmail 8.12.1.
>
>Deine Meinung. An die, die eine aktuelle Studie interessiert (3.10.):
>http://cr.yp.to/surveys.html
Studien, die nicht unabhaengig sind, oder gar vom Hersteller selbst
generiert wurden, sind nicht aussagekraeftig.
Als naechstes kommt hier eine Mindcraft studie, die genau zu den gleichen
Zahlenwerten als ergebnis kommt, jedoch qmail durch Exchange ersetzt.
DJB's Studien waren nie relevant, und werden es auch nie sein. Nicht weil
ich DJB die faehigkeit absprechen will, solche Studien gewissenhaft
durchfuerhen zu koennen, sondern weil hier ein Interessenskonflikt
herrscht. Und solange ich DJB bei seiner Studie nicht ueber die Schulter
schauen kann, bleiben seine Ergebnisse irrelevant.
Fuer mich zaehlen nur unabhaengige Studien serioeser Quellen und meine
Eigenen Beobachtungen, was MX'e angeht.
Leztere zeigen gaenzlich andere Zahlen als die von DJB.
Fuer andere als mich selbst sind diese aber genausowenig relevant wie
seine, da ich nunaml einen Bias gegen DJB habe.
>> Es ist keine falsche Unterstellung; dass qmail langsam und fuer grosse
>> Mailinglisten nicht die erste Wahl ist, ist mit Zahlen (nicht nur
>> meinen) belegt.
>
>Deine Meinung. An die, die es interessiert:
>http://www.qmail.org/top.html
>Der fuenfte Absatz listet ein paar sites, die qmail benutzen.
>Ich habe auch niemals angezweifelt, dass es schnellere MTAs gibt, trotzdem
>empfehle ich qmail gerade bei grossen Mailaufkommen und Server fuer Mailing
>Lists. Es gibt noch andere Faktoren als Schnelligkeit.
Welche Faktoren meinst du?
>Matthias, ich habe keine Lust mit dir darueber zu diskutieren.
Das ist Schade. Du stellst hier einigen Behauptungen auf, wo mich
der Nachweis durchaus interessieren wuerde.
Aber wenn du keine Lust hast...
[persoenliches zw. Gerrit und Mathias geloescht]
Gerrit Pape
> Gerrit Pape <pa...@smarden.org> wrote:
>>Deine Meinung. An die, die eine aktuelle Studie interessiert (3.10.):
>>http://cr.yp.to/surveys.html
> Studien, die nicht unabhaengig sind, oder gar vom Hersteller selbst
> generiert wurden, sind nicht aussagekraeftig.
http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/bench2.html ?
>>Lists. Es gibt noch andere Faktoren als Schnelligkeit.
> Welche Faktoren meinst du?
>>Matthias, ich habe keine Lust mit dir darueber zu diskutieren.
> Das ist Schade. Du stellst hier einigen Behauptungen auf, wo mich
> der Nachweis durchaus interessieren wuerde.
Bitte, ich habe keine Behauptungen aufgestellt, nur eine Empfehlung fuer
qmail ausgesprochen. Mir ist es egal, was Ihr fuer einen MTA einsetzt.
> Aber wenn du keine Lust hast...
Dieser Matthias Andree kosten mich hier schon genug Zeit, sorry.
Gruss, Gerrit.
Stefan Paletta
> Stefan Paletta <ste...@world.wronline.de> writes:
>> Ausgehend von <http://mandree.home.pages.de/postfix/bench2.html>:
>> 1000 Mails mit je einem
>> Empfaenger oder 1000 Mails mit je 10 Empfaengern sind weitest moeglich von
>> 'grosse Mailinglisten' entfernt. Warum hast du nicht z.B. eine Mail mit
>> 20.000 Empfaengern bis 10 Mails mit je 200.000 Empfaengern gemessen?
>
> Weil ezmlm zum Beispiel genau das nicht tut, sondern zur VERP-Emulation
> 1-zu-1-Mailings macht.
_Bitte_ _was_?!
ezmlm queued wie jeder vernuenftige MLM nur eine Mail an alle Empfaenger;
mit VERP.
>> Du gibst ausserdem keine Auskunft darueber, mit welcher concurrencyremote
>> qmail lief, bzw. welche Anzahl Verbindungen den anderen MTA gestattet
>> war.
>
> Der "andere MTA" ist da beschrieben, wie schnell der ist, auch:
> smtp-sink, single-threaded, mit exzessiv großem listen(2)-Backlog, das
Ich meinte offensichtlich die "Konkurrenz".
> qmail's preprocessing is a real performance killer. The throughput ramps
> up considerably after all mail has been preprocessed. (I did a separate
> test I don't report above.)"
Old news.
> In diesem Test habe ich mir alle 15 s mit qmail-qshow angesehen, wie
> groß die Queues sind, und dabei festgestellt, daß erst dann 20
> qmail-remote laufen, sobald qmails Preprocessing abgeschlossen ist, das
> ist aber erst geraume Zeit nach Ende des Einliefervorgangs der Fall und
> betrifft nur noch die letzten Mails - wenn aber schon 3 oder 4 min um
> sind, bevor die concurrency überhaupt interessant wird, macht's nicht
> mehr viel aus, ob man 20 oder 120 zuläßt, ob dann aus der letzten halben
> oder dreiviertel Minute 10 s werden oder 20 -- was macht das für den
> Durchsatz noch?
Bei nur einer Mail ist das preprocessing, unabhaengig von der Anzahl der
Empfaenger, verschwindend kurz und die concurrency kann sofort ausgenutzt
werden.
Stefan
Juergen P. Meier
>Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
>> Gerrit Pape <pa...@smarden.org> wrote:
>>>Deine Meinung. An die, die eine aktuelle Studie interessiert (3.10.):
>>>http://cr.yp.to/surveys.html
>
>> Studien, die nicht unabhaengig sind, oder gar vom Hersteller selbst
>> generiert wurden, sind nicht aussagekraeftig.
>
>http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/bench2.html ?
Das ist ein Benchmark.
Was genau willst du mit diesem Link aussagen? Und was hat er mit
meiner Aussage, die du darueber quotest, zu tun?
Die kommunikationspartner meines Postfix MTA's zuhause sind
jedoch zu einem fuenftel andere Postfix MTA's, ca. 5% qmails
ein Exchange server, ca. 30% unbekannt ein paar Viruswalls
und der Rest sendmail.
Obfuscation treffe ich in der Praxis haeufig bei sendmail
und anderen MTA's, doch das ist nur Spekulation.
Auch geben sich einige als sendmail aus, wobei ich glaube,
dies hebt sich mit den sendmails auf, die sich sich nicht
zu erkennen geben.
Das sind die Zahlen, die von letztem Juni stammen, und die
MTA's getest hat, die mit meinem MX zuhause gesprochen
haben. Das ist in keinster Weise ein repraesentatives Survey.
>>>Lists. Es gibt noch andere Faktoren als Schnelligkeit.
>
>> Welche Faktoren meinst du?
>>>Matthias, ich habe keine Lust mit dir darueber zu diskutieren.
>> Das ist Schade. Du stellst hier einigen Behauptungen auf, wo mich
>> der Nachweis durchaus interessieren wuerde.
>
>Bitte, ich habe keine Behauptungen aufgestellt, nur eine Empfehlung fuer
>qmail ausgesprochen. Mir ist es egal, was Ihr fuer einen MTA einsetzt.
Also Eine Empfehlung ohne Begruendung der selben.
Und du bist nicht bereit eine Begruendung auf Nachfrage zu liefern?
Nungut, niemand kann dich dazu Zwingen, aber dann beschwer dich nicht,
wenn jemand eine andere Empfehlung nimmt, oder deine grundlose
Empfehlung anzweifelt, oder gegenargumente dazu bringt.
Ueber Argumente laesst sich Diskutieren, alles andere ist FUD.
>> Aber wenn du keine Lust hast...
>
>Dieser Matthias Andree kosten mich hier schon genug Zeit, sorry.
Immerhin liefert er Begruendungen und dazu Zahlen,
die jeder fuer sich selbst ueberpruefen kann.
Ich habe zwar seinen Test (obige URL) nicht nachgebaut, meine
Erfahrungen mit qmail ohne softupdates, sendmail und neuerdings
postfix in der Realen Welt[tm] auf Produktiven MTA's
zeigen mir, das Andree's Zahlen nicht voellig falsch sind, auch
wenn ich die schlechten Werte fuer sendmail nicht gaenzlich
nachvollziehen kann. (wobei ich noch keinen direkten Vergleich
von sendmail und postfix selbst gesehen habe)
Das muss natuerlich jeder fuer sich selbst nachpruefen, wenn
er Matthias (der wohl als postfix-advokat anzusehen ist) oder
mir (ich habe was gegen DJB, und halte qmail nicht fuer einen
leistungsfaehigen MTA, bin also zumindest bei qmail voreingenommen)
glauben schenken mag.
Matthias Andree
> ezmlm queued wie jeder vernuenftige MLM nur eine Mail an alle Empfaenger;
> mit VERP.
Du hast recht, es muß ezmlm + qmail heißen.
> Bei nur einer Mail ist das preprocessing, unabhaengig von der Anzahl der
> Empfaenger, verschwindend kurz und die concurrency kann sofort ausgenutzt
> werden.
Ja. Das Ergebnis ist, daß Postfix "bei nur einer Mail (an 10 Empfänger)"
fünf- bis sechsmal schneller ist als qmail, wie Du dem Benchmark
entnehmen kannst.
Matthias Andree
> Deine Meinung. An die, die eine aktuelle Studie interessiert (3.10.):
> http://cr.yp.to/surveys.html
Interessant ist, daß die Postfix-Filterregeln kaputt sind. Davon
abgesehen, daß ich nur raten kann, daß M. für CRLF stehen soll:
1 / ESMTP PostfixM.250-/ { print postfix; next }
2 / ESMTP Postfix / { print postfix; next }
3 /M.250-PIPELININGM.250-SIZE [0-9]*M.250-ETRNM.250 8BITMIMEM.*250.* OkM.502 Error: command not implemented.*M.221 ByeM./ { print postfix; next }
Die Kisten, die veränderte Banner haben, greift er nicht
zuverlässig. Jüngere Postfixen, die XVERP können, greift er ebenfalls
nicht.
Es ist nicht dokumentiert, welche Befehle er schickt, wie er sie
auswertet, wir haben nur ein paar Filterregeln. Nachvollziehen kann man
die Studie nicht. Die IPs, die er getestet hat, sind nicht
gelistet. Selbst bei einer Million kann man ohne Mühe die Daten ins Netz
stellen, 4 Millionen Byte sind nicht viel.
Man kann nur mutmaßen, worauf z. B. hier das nächste 250.* matchen
soll. Wenn's VRFY ist, böse Falle, das kann man abschalten.
Die aktuelle Studie ist auch aus anderen Gründen eine Farce.
"* Sendmail is continuing to drop in popularity. 405 addresses (42%)
are running Sendmail, down from 434 a year ago."
Mag ja sein, aber DJB als Mathematiker sollte wissen, daß die 434 da
irrelevant sind. Er meinte "48 %".
"Meanwhile, the Sendmail company continues to claim on its web pages
that Sendmail ``powers the majority of the Internet's mail servers,''
on the basis of surveys I carried out years ago. See
http://cr.yp.to/surveys/sendmail.html for further discussion."
Interessant, daß sich gerade DJB über alte Profile beschwert, er ist
doch derjenige, der seine Webseiten nicht updatet, wenn er über andere
hergezogen ist.
Die Studie geht auf das tatsächlich verwaltete Mailvolumen nur ein, wo
es für qmail wichtig ist, und daß das relevant ist, zeigt die Studie
selbst: "Two thirds of the qmail deployments, 110 addresses this year
and 53 addresses last year, are cpmta deployments by a single company,
Critical Path, with 152 million mailboxes. See http://www.cp.net."
Böse Zungen könnten jetzt unterstellen, daß qmail deswegen so viele neue
IPs hat, weil man so viele Installationen braucht, weil es langsam ist.
Schließlich ist DJB der Urheber dieser Studie, und er hat -- aus welchen
Gründen auch immer -- den Zwang, seine Software zu promoten.
> >> Weder betreibe ich FUD, noch falsche Beratung, unterlasse diese
> >> falschen Unterstellungen, du hast mir schon genug Zeit gekostet.
>
> Ich _unterstreiche_ dieses nocheinmal, du hast mir etwas unterstellt, aber
> darauf nicht geantwortet.
Du hast die Belege wiederholt ignoriert, Diskussion ist müßig.
> Der fuenfte Absatz listet ein paar sites, die qmail benutzen.
> Ich habe auch niemals angezweifelt, dass es schnellere MTAs gibt, trotzdem
> empfehle ich qmail gerade bei grossen Mailaufkommen und Server fuer Mailing
> Lists. Es gibt noch andere Faktoren als Schnelligkeit.
Das mag sein, doch keine davon sind relevant, schon gar nicht, wenn sie
nicht genannt werden. Du hast Dich den sachlichen (technischen)
Argumenten verschlossen und schiebst jetzt diffuse andere Argumente mit
ins Feld, kannst aber keines meiner Argumente, warum Postfix /besser/
geeignet ist, sachlich widerlegen.
> Matthias, ich habe keine Lust mit dir darueber zu diskutieren.
Niemand zwingt Dich.
> Matthias, wenn du jetzt noch irgendwelche sachlichen Einwaende zu meine
> original Posting <9phidc$l12$1...@bolzen.all.de> hast, meinetwegen sprich,
> sonst bitte schweig, ich habe mit dir persoenlich nichts zu tun und will es
> auch nicht.
Ich habe Dir Argumente geliefert (die übrigens jedem, der hingucken
will, auch hinlänglich bekannt sind), warum (daß) durch großes
Mailaufkommen die Performance gerade bei qmail nicht steigt. Daß "Bei
grossen Mailaufkommen [...] die Sicherheit steigt, da kein Code zum
parsen[sic] von RCPT TO existiert", ist offenkundig Schwachsinn.
Matthias Andree
> > Studien, die nicht unabhaengig sind, oder gar vom Hersteller selbst
> > generiert wurden, sind nicht aussagekraeftig.
>
> http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/bench2.html ?
Unabhängig und nicht vom Hersteller generiert.
> Bitte, ich habe keine Behauptungen aufgestellt, nur eine Empfehlung fuer
> qmail ausgesprochen. Mir ist es egal, was Ihr fuer einen MTA einsetzt.
So drop dead.
> > Aber wenn du keine Lust hast...
>
> Dieser Matthias Andree kosten mich hier schon genug Zeit, sorry.
Ich kann ja nichts dazu, daß Du nicht über Deinen Tellerrand gucken
kannst.
Matthias Andree
> Ich habe zwar seinen Test (obige URL) nicht nachgebaut, meine
> Erfahrungen mit qmail ohne softupdates, sendmail und neuerdings
> postfix in der Realen Welt[tm] auf Produktiven MTA's
> zeigen mir, das Andree's Zahlen nicht voellig falsch sind, auch
> wenn ich die schlechten Werte fuer sendmail nicht gaenzlich
> nachvollziehen kann. (wobei ich noch keinen direkten Vergleich
> von sendmail und postfix selbst gesehen habe)
Zum Teil konnte ich sie mit 4.4-RC selbst nicht nachvollziehen, nachdem
Claus Aßmann sich schon in dieser Richtung geäußert hatte. Am Ende der
Seite ist auch ein Hinweis dazu angebracht, die Tabellen haben in der
rechten Spalte ebenfalls Anmerkungen dazu.
Mein Prinzip war aber, die MTA für FreeBSD auszupacken und nicht zu
tunen. Ich kann mir durchaus vorstellen, daß man Sendmail[1] oder Exim
Beine machen kann, aber man muß dann sehen, daß man das den anderen MTA
auch gestattet, und spätestens da stehe ich vor dem Problem, daß ich
Exim nicht hinreichend kenne, um es tunen zu können, demnach wäre der
"tuned MTA shootout" unfair geworden, zum Nachteil von Exim, dessen
Design ich gewiß nicht schätze, der eine oder andere wird sich an die
heftigen Diskussionen mit Andreas M. Kirchwitz hier erinnern.
Nur ist Tuning - neben der Unfairness durch Kenntnis des MTA - zum Teil
von Trial & Error begleitet (so hat mich der Umstand, daß Exim mit 5
Clients schneller ausliefert als mit 20, doch sehr überrascht), das
Tuning wird somit sehr zeitaufwendig.
> Das muss natuerlich jeder fuer sich selbst nachpruefen, wenn
> er Matthias (der wohl als postfix-advokat anzusehen ist) oder
> mir (ich habe was gegen DJB, und halte qmail nicht fuer einen
> leistungsfaehigen MTA, bin also zumindest bei qmail voreingenommen)
> glauben schenken mag.
Es muß vor allem jeder überlegen, ob er
1a. lieber demjenigen glaubt, der eigene positive Argumente vorbringt oder
1b. ausweicht und beschriebene Mängel relativiert
2a. demjenigen glaubt, der die MTAs schonmal benutzt hat (trifft bei mir
auf Exim nicht zu) oder
2b. demjenigen, der sie sich aus Prinzip gar nicht ansieht
Es mag sich auch mit Exim 4 oder qmail 2 alles wieder ändern, mag sein,
daß qmail 2 schneller als Postfix ist. Allein, noch gibt's keinen der
beiden.
[1] http://www.shub-internet.org/brad/papers/sendmail-tuning/
Matthias Andree
> Wie naiv...
> Solange ich die wirklichen Gruende nicht kenne, bin ich sehr
> vorsichtig bei der Beurteilung. Manchen Leuten traue ich auch
> zu, von qmail auf postfix umzustellen, nur weil die ``Lizenz''
> von qmail nicht in ihr Weltbild passt.
Selbst das ist ein valider Grund zur Umstellung.
> Btw. CriticalPath setzt vermehrt Exchange statt ihres qmail
> Derivates ein.
Interessant, gerade in Verbindung mit Dan's aktueller Statistik, die
doch gerade behauptet, cpmta hätte 110 Neuinstallationen...
Kannst Du die Quelle belegen?
Matthias Andree
> >> >> Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle
> >> >> moeglichen Sonderfaelle Code in das Project integriert wird, der
> >> >> dann bei den wenigsten Installation benoetigt wird, aber ueberall
> >> >> vorhanden ist.
> Du bist unglaublich. Lies noch einmal meinen Satz, die vier Zeilen oben.
> Hast du etwas daran auszusetzen? Dann erklaere mir, wo darin die
> Falschaussage ist, ansonsten ziehe deine falsche Anschuldigung zurueck.
Der fragliche Abschnitt ist wiederholt zitiert.
Aus dem Kontext heraus ergibt sich zweifelsfrei, daß Du dieses
vermeintliche "Feature" (nämlich den defer_transports-Parameter in
Postfix) als überflüssigen ressourcenverschwenderischen Code für alle
möglichen Sonderfälle hältst.
Es ist eine Falschaussage, daß das Code für selten benötigte Sonderfälle
ist.
> Wie bitte? Was fuer Drogen nimmst du? Zeige mir auch nur eine unhaltbare
> Behauptung meinerseits ueber qmail auf!! Zitiere mich, wo ich qmail "ueber
> den Klee lobe", mir ist nichts bekannt!! Du bist unverschaemt und wirst
> wahrscheinlich wieder die falschen Beschuldigungen nicht
> zuruecknehmen.
Billige Polemik. Du empfiehlst qmail für fette Mailinglisten, kannst das
aber nicht fundiert Begründen, nur durch Relativierung oder Ignorieren
meiner Argumente.
> Weil ich keine Zeit und Lust, mit dir zu diskutieren, meine Erfahrungen
> haben auch gezeigt, dass das wahrscheinlich nicht moeglich ist.
> Fuer die, die es interessert: D J Bernstein, Author von qmail, hatte mal
> eine persoenliche Auseinandersetzung mit Ben Greenbaum:
> http://cr.yp.to/freebugtraq/greenbaum/01.txt , 02.txt, 03.txt, ...,
> 10.txt
Ich zitiere einfach meinen Abschnitt:
> > Ob es Codeanalyse oder Empirie ist, Du bist keinem Argument zugaenglich.
> > Du bist offenkundig lernresistent. Es empfiehlt sich fuer Dich, sich
> > andere Mailer anzusehen, und dann zu entscheiden, ob qmail wirklich noch
> > die erste Wahl ist oder es besser beim persoenlichen und objektiv nicht
> > zu beanstandenden "ich mag qmail, weil ich's gut kenne" in Deinen
> > Aeusserungen bleibt.
>
> Unverschaemt. Was ist deine Mission? Was hast du persoenlich mit mir zu tun?
> Wer bist du, mir zu unterstellen, ich sei dies und das und
> lernresistent?
Du hast an keiner Stelle erkennen lassen, daß Du Dich mit Postfix auch
nur ansatzweise auseinandergesetzt hättest. Du hast mehrfach geäußert,
daß Du qmail für Mailinglisten empfiehlst, und das heißt doch, daß Du es
magst, und Du kennst qmail auch. In der ersten Diskussion war das Deine
endgültige Position. Verschiedentlich in diesem Thread kam etwas wie,
Dir wäre gleich, welche MTAs andere nähmen, und mehr als der Ausdruck,
daß Du qmail bevorzugst, es aber nicht begründen kannst (erst recht
nicht in Relation zu vorhandener Konkurrenz), ist nie übrig geblieben.
Mission? Keine. Ich gebe hier meine eigene Meinung preis. Das Ziel ist
an anderer Stelle im Thread genannt.
Gerrit Pape
>> >> >> Ueberfluessige Ressourcenverschwendung ist, wenn fuer alle
>> >> >> moeglichen Sonderfaelle Code in das Project integriert wird, der
>> >> >> dann bei den wenigsten Installation benoetigt wird, aber ueberall
>> >> >> vorhanden ist.
>
>> Du bist unglaublich. Lies noch einmal meinen Satz, die vier Zeilen oben.
>> Hast du etwas daran auszusetzen? Dann erklaere mir, wo darin die
>> Falschaussage ist, ansonsten ziehe deine falsche Anschuldigung zurueck.
> Der fragliche Abschnitt ist wiederholt zitiert.
> Aus dem Kontext heraus ergibt sich zweifelsfrei, daß Du dieses
> vermeintliche "Feature" (nämlich den defer_transports-Parameter in
> Postfix) als überflüssigen ressourcenverschwenderischen Code für alle
> möglichen Sonderfälle hältst.
Nein. Ich meine genau das, was ich schreibe. Lerne lesen. Ich habe dich auf
deine Fehlinterpretationen schon mehrfach aufwerksam gemacht[0], wenn du
etwas nicht verstehst, frage nach und setze nicht deine Interpretion voraus
und bezichtige andere der Falschaussage.
Du hast dir das schonmal gemacht:
http://groups.google.com/groups?selm=m33d6h6cy1.fsf%40emma1.emma.line.org ff.
und bis heute nicht verstanden, was ein 'Mailinglist Server, der an standard
smtp server ausliefert' ist.
Ich habe dir ordentlich dein Missverstaendnis aufgezeigt
http://groups.google.com/groups?selm=9mdbbe%242vq8%241%40FreeBSD.csie.NCTU.edu.tw
, was du scheinbar eingesehen hast:
http://groups.google.com/groups?selm=9mdl94%246nm%241%40FreeBSD.csie.NCTU.edu.tw
Darauf hin erdreistest du dich, nachdem du mich ueberheblich insentivst noch
einmal eine Nacht ueberlegen geschickt hast
http://groups.google.com/groups?selm=m3y9o9q9hk.fsf%40emma1.emma.line.org
diese Posting zu schicken:
http://groups.google.com/groups?selm=m3r8txjltb.fsf%40emma1.emma.line.org
Was 'und jetzt?'?? Willst du mir noch mehr Zeit klauen?
FUD - par excellence - von Matthias Andree.
-------------------------------------------
Das zum Thema Lernfaehigkeit und 'Profile, don't speculate'.
> Es ist eine Falschaussage, daß das Code für selten benötigte Sonderfälle
> ist.
Kann gut sein, ich habe das niemals behauptet.
[requote]
>>Matthias Andree <matthia...@gmx.de> wrote:
>>> qmail belastet mich nicht, Deine wiederholten unhaltbaren Behauptungen
>>> ueber qmail, das hier von Dir meilenweit ueber den Klee gelobt wird, sind
>> Wie bitte? Was fuer Drogen nimmst du? Zeige mir auch nur eine unhaltbare
>> Behauptung meinerseits ueber qmail auf!! Zitiere mich, wo ich qmail "ueber
>> den Klee lobe", mir ist nichts bekannt!! Du bist unverschaemt und wirst
>> wahrscheinlich wieder die falschen Beschuldigungen nicht
>> zuruecknehmen.
> Billige Polemik. Du empfiehlst qmail für fette Mailinglisten, kannst das
> aber nicht fundiert Begründen, nur durch Relativierung oder Ignorieren
> meiner Argumente.
Zusammangefasst: Du behauptest, ich wuerde wiederholte 'unhaltbare
Behauptungen ueber qmail' machen und qmail 'ueber den Klee' loben. Ich
fordere Dich auf, mir diese Vorwuerfe nachzuweisen, du weichst aus.
FUD von Matthias Andree.
------------------------
Wenn dir mein Ton nicht gefallen hat, ich versuche nur, mich anzupassen[1].
Die Forderung bleibt, ansonsten ziehe deine Beschuldigungen zurueck.
>> Weil ich keine Zeit und Lust, mit dir zu diskutieren, meine Erfahrungen
>> haben auch gezeigt, dass das wahrscheinlich nicht moeglich ist.
>> Fuer die, die es interessert: D J Bernstein, Author von qmail, hatte mal
>> eine persoenliche Auseinandersetzung mit Ben Greenbaum:
>> http://cr.yp.to/freebugtraq/greenbaum/01.txt , 02.txt, 03.txt, ...,
>> 10.txt
> Ich zitiere einfach meinen Abschnitt:
>> > Ob es Codeanalyse oder Empirie ist, Du bist keinem Argument zugaenglich.
>> > Du bist offenkundig lernresistent. Es empfiehlt sich fuer Dich, sich
>> > andere Mailer anzusehen, und dann zu entscheiden, ob qmail wirklich noch
>> > die erste Wahl ist oder es besser beim persoenlichen und objektiv nicht
>> > zu beanstandenden "ich mag qmail, weil ich's gut kenne" in Deinen
>> > Aeusserungen bleibt.
>>
>> Unverschaemt. Was ist deine Mission? Was hast du persoenlich mit mir zu tun?
>> Wer bist du, mir zu unterstellen, ich sei dies und das und
>> lernresistent?
> Du hast an keiner Stelle erkennen lassen, daß Du Dich mit Postfix auch
> nur ansatzweise auseinandergesetzt hättest. Du hast mehrfach geäußert,
Hallo! Aufwachen! Hast du eigentlich mitbekommen, Matthias Andree, dass ich
noch niemals mit dir ueber postfix diskutiert habe? Du bist der Einzige, der
diesen MTA immerwieder anfuehrt und in meinen Mund legt. Ich beanstande
gelegentlich dein falschen oder uebertriebenen Aeusserungen zu qmail.
Das zum Thema 'ueber den Tellerrand gucken'.
> daß Du qmail für Mailinglisten empfiehlst, und das heißt doch, daß Du es
> magst, und Du kennst qmail auch. In der ersten Diskussion war das Deine
> endgültige Position. Verschiedentlich in diesem Thread kam etwas wie,
> Dir wäre gleich, welche MTAs andere nähmen, und mehr als der Ausdruck,
> daß Du qmail bevorzugst, es aber nicht begründen kannst (erst recht
> nicht in Relation zu vorhandener Konkurrenz), ist nie übrig geblieben.
Huh?, parse error.
> Mission? Keine. Ich gebe hier meine eigene Meinung preis. Das Ziel ist
> an anderer Stelle im Thread genannt.
Du gibst hier deine Meinung ueber mich preis. Das interessiert wohl kaum
jemanden hier und es ist auch nicht die richtige Gruppe.
Warum? Was ist dein Mission?
Aus <m3wv2b2...@emma1.emma.line.org>:
Matthias Andree <matthia...@gmx.de> wrote:
> Nun hast Du das Profil, das alle DJB-Advokaten mit "profile, don't
> speculate" haben wollen, und es schmeckt Dir nicht, aber ich fuehle mich
> fuer den Erhalt Deines Weltbilds nicht verantwortlich.
FUD von Matthias Andree.
------------------------
Zeige mir entsprechende Diskussionen, die mir das
Profil "profile, don't speculate" zuschreiben oder ziehe deine
Unverschaemtheit zurueck.
Gerrit.
[0]
http://groups.google.com/groups?selm=9pko8o%2466i%241%40bolzen.all.de
[du] verdrehst Worte oder interpretierst sie falsch
http://groups.google.com/groups?selm=9mdk8h%245on%241%40FreeBSD.csie.NCTU.edu.tw
You just again scramble my words or just miss to understand them
[1]
http://groups.google.com/groups?selm=m3wv3457s0.fsf%40emma1.emma.line.org
Geh spielen, dein BSD langweilt sich.
http://groups.google.com/groups?selm=m3ofoj2r7k.fsf%40emma1.emma.line.org
Dan Schwadron J. Bernstein vergißt leider über seinem Rant gegen
RFC-1894, daß andere, verbreitet MTAs, zum Bleistift Sendmüll und
Postfix, es verwenden und daher Clients RFC-1894 lesen können
müssen. DJB erwartet nun aber, daß sich alle um den Einfall eines
kleinen Professors in Illinois scheren, dessen Hobby das Erfinden
überflüssiger Protokolle und Datenformate ist, und extra noch einen
Parser für das normwidrige QSBMF löten.
Gerrit Pape
> Gerrit Pape <pa...@smarden.org> wrote:
>>Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
>>> Gerrit Pape <pa...@smarden.org> wrote:
>>>>Deine Meinung. An die, die eine aktuelle Studie interessiert (3.10.):
>>>>http://cr.yp.to/surveys.html
>>
>>> Studien, die nicht unabhaengig sind, oder gar vom Hersteller selbst
>>> generiert wurden, sind nicht aussagekraeftig.
>>
>>http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/bench2.html ?
> Das ist ein Benchmark.
> Was genau willst du mit diesem Link aussagen? Und was hat er mit
> meiner Aussage, die du darueber quotest, zu tun?
Ich wollte nur zu denken geben, dass die Studien dieses Matthias Andrees
vielleicht auch nicht 'unabhaengig' sind:
http://groups.google.com/groups?selm=m3ofoj2r7k.fsf%40emma1.emma.line.org
(vorletzter Absatz). Ich bestehe darauf nicht und ziehe meine Frage zurueck.
>>>>Lists. Es gibt noch andere Faktoren als Schnelligkeit.
>>
>>> Welche Faktoren meinst du?
>>>>Matthias, ich habe keine Lust mit dir darueber zu diskutieren.
>>> Das ist Schade. Du stellst hier einigen Behauptungen auf, wo mich
>>> der Nachweis durchaus interessieren wuerde.
>>
>>Bitte, ich habe keine Behauptungen aufgestellt, nur eine Empfehlung fuer
>>qmail ausgesprochen. Mir ist es egal, was Ihr fuer einen MTA einsetzt.
> Also Eine Empfehlung ohne Begruendung der selben.
> Und du bist nicht bereit eine Begruendung auf Nachfrage zu liefern?
Vielleicht kann mir jemand helfen: Macht mal eine Aufwandsabschaetzung nach
den Erfahrungen aus den drei threads[0], was mich eine Verargumentierung
meiner Argumente hier kosten wuerde, und was mein Nutzen davon waere. Lohnt
es sich?
> Nungut, niemand kann dich dazu Zwingen, aber dann beschwer dich nicht,
> wenn jemand eine andere Empfehlung nimmt, oder deine grundlose
> Empfehlung anzweifelt, oder gegenargumente dazu bringt.
Das habe ich nie gemacht und werde ich auch nicht. Ich habe auch die meisten
Argumente des Matthias Andree nicht angezweifelt, sie reichen fuer mich nur
nicht aus, um meine Meinung zu aendern.
> Ueber Argumente laesst sich Diskutieren, alles andere ist FUD.
In <9prlmd$k9244$1...@ID-112179.news.dfncis.de> habe ich versucht zu zeigen,
dass es sich mit diesem Matthias Andree ueber Argumente kaum diskutieren
laesst.
>>> Aber wenn du keine Lust hast...
>>
>>Dieser Matthias Andree kosten mich hier schon genug Zeit, sorry.
> Immerhin liefert er Begruendungen und dazu Zahlen,
> die jeder fuer sich selbst ueberpruefen kann.
Wer hier Empfehlungen von verschiedenen Authoren liest, kann sich ein Bild
von dem Profil des Authors machen, Suchmaschinen sind die Freunde, ich
brauche mich vor meinem Profil nicht zu verstecken, ich habe nur wenig Zeit
fuer diese regionale Gruppe hier uebrig und die wird leider von diesem
Matthias Andree beansprucht.
Gerrit.
[0]
http://groups.google.com/groups?frame=right&rnum=21&thl=1124956343,1124119816,1124088089,1124041461,1123957946,1123684677,1122927511,1122923351,1122912027,1122537899,1122537897,1122527661&seekm=9mdc99%24o89%241%40mate.bln.innominate.de#link21
http://groups.google.com/groups?frame=right&th=af851bc2a352e4f&seekm=9phidc%24l12%241%40bolzen.all.de#link1
http://groups.google.com/groups?frame=right&th=af851bc2a352e4f&seekm=9phiu8%24l12%242%40bolzen.all.de#link21
Gerrit Pape
>> >> Weder betreibe ich FUD, noch falsche Beratung, unterlasse diese
>> >> falschen Unterstellungen, du hast mir schon genug Zeit gekostet.
>>
>> Ich _unterstreiche_ dieses nocheinmal, du hast mir etwas unterstellt, aber
>> darauf nicht geantwortet.
> Du hast die Belege wiederholt ignoriert, Diskussion ist müßig.
_FUD_ und _falsche Beratung_ wirfst du mir vor, welche Belege hast du
erbracht?
>> Der fuenfte Absatz listet ein paar sites, die qmail benutzen.
>> Ich habe auch niemals angezweifelt, dass es schnellere MTAs gibt, trotzdem
>> empfehle ich qmail gerade bei grossen Mailaufkommen und Server fuer Mailing
>> Lists. Es gibt noch andere Faktoren als Schnelligkeit.
> Das mag sein, doch keine davon sind relevant, schon gar nicht, wenn sie
> nicht genannt werden. Du hast Dich den sachlichen (technischen)
> Argumenten verschlossen und schiebst jetzt diffuse andere Argumente mit
> ins Feld, kannst aber keines meiner Argumente, warum Postfix /besser/
> geeignet ist, sachlich widerlegen.
Hallo! Aufwachen! Hast du eigentlich mitbekommen, Matthias Andree, dass ich
noch niemals mit dir ueber postfix diskutiert habe? Du bist der Einzige, der
diesen MTA immerwieder anfuehrt und in meinen Mund legt. Ich beanstande
gelegentlich dein falschen oder uebertriebenen Aeusserungen zu qmail.
>> Matthias, ich habe keine Lust mit dir darueber zu diskutieren.
>> Matthias, wenn du jetzt noch irgendwelche sachlichen Einwaende zu meine
>> original Posting <9phidc$l12$1...@bolzen.all.de> hast, meinetwegen sprich,
>> sonst bitte schweig, ich habe mit dir persoenlich nichts zu tun und will es
>> auch nicht.
> Ich habe Dir Argumente geliefert (die übrigens jedem, der hingucken
> will, auch hinlänglich bekannt sind), warum (daß) durch großes
> Mailaufkommen die Performance gerade bei qmail nicht steigt. Daß "Bei
> grossen Mailaufkommen [...] die Sicherheit steigt, da kein Code zum
> parsen[sic] von RCPT TO existiert", ist offenkundig Schwachsinn.
Wenn das fuer dich 'offenkundig Schwachsinn' ist, bitte, weniger noch als
ueber MTAs, denke ich, kann man mit dir ueber Sicherheit diskutieren, z.B.:
http://groups.google.com/groups?selm=9m5bs8%242f9q%241%40FreeBSD.csie.NCTU.edu.tw
'[...] Postfix is safe on async file systems with a current Linux 2.4
with current ext3fs (I asked at the time 0.9.5 was current, the first
synchronous operation triggers all pending updates, asynchronous or not)
[...]'
zeigt, wie du mit Releases und Beta Versionen umgehst, aber du empfiehlst ja
auch postfix snapshots fuer produktiven Einsatz (glaube ich), aber das ist
deine Sache, ueber Empfehlungen einzelner Personen soll sich jeder selbst ein
Bild machen. Releases gehen durch eine Qualitaets Sicherung.
Gerrit.
Matthias Andree
> In <9prlmd$k9244$1...@ID-112179.news.dfncis.de> habe ich versucht zu zeigen,
> dass es sich mit diesem Matthias Andree ueber Argumente kaum diskutieren
> laesst.
Alles, was Du bisher gezeigt hast, ist, daß Du Dich mit gegebenen
Argumenten nicht auseinandersetzt, sondern an Deiner Position ohne
Begründung festhältst.
Matthias Andree
> > Es ist eine Falschaussage, daß das Code für selten benötigte Sonderfälle
> > ist.
>
> Kann gut sein, ich habe das niemals behauptet.
Hast Du, hier im Thread. Wenn Du ohnehin schwammige Aussagen machst, von
denen Du nicht willst, daß sie Bestand haben, schreib' das dazu, dann
spart man sich die Antwort.
> > Du hast an keiner Stelle erkennen lassen, daß Du Dich mit Postfix auch
> > nur ansatzweise auseinandergesetzt hättest. Du hast mehrfach geäußert,
>
> Hallo! Aufwachen! Hast du eigentlich mitbekommen, Matthias Andree, dass ich
> noch niemals mit dir ueber postfix diskutiert habe? Du bist der Einzige, der
> diesen MTA immerwieder anfuehrt und in meinen Mund legt. Ich beanstande
> gelegentlich dein falschen oder uebertriebenen Aeusserungen zu qmail.
Wenn sie denn falsch wären, denn meine Äußerungen zu qmail sind
belegt. Du hast - wenn ich Eigenschaften von Postfix beschrieben habe -
mit diffusen Erwiderungen hantiert, die Du im Nachhinein als nicht auf
Postfix bezogen haben willst, relativierst oder abstreitest.
> Zeige mir entsprechende Diskussionen, die mir das
> Profil "profile, don't speculate" zuschreiben oder ziehe deine
> Unverschaemtheit zurueck.
Warum sollte ich? Du bist derjenige, der seine "Argumente" nicht
behauptet, im Nachhinein dann aber relativiert und abstreitet.
Ich werde die Belege, die ich angeführt habe, nicht hier wiederholen, Du
scheinst ja zu wissen, wie man groups.google.com benutzt.
Du kannst Deine eigene Meinung zu MTAs haben, solange die nicht haltbar
ist, wirst Du mit ebenso öffentlich geäußerten anderen Meinungen leben
müssen.
Matthias Andree
> _FUD_ und _falsche Beratung_ wirfst du mir vor, welche Belege hast du
> erbracht?
Frag' google. Belege sind genügend vorhanden. Benchmarks, Analysen.
> '[...] Postfix is safe on async file systems with a current Linux 2.4
> with current ext3fs (I asked at the time 0.9.5 was current, the first
> synchronous operation triggers all pending updates, asynchronous or not)
> [...]'
Was verstehst Du daran nicht?
> zeigt, wie du mit Releases und Beta Versionen umgehst, aber du
> empfiehlst ja auch postfix snapshots fuer produktiven Einsatz (glaube
> ich), aber das ist deine Sache, ueber Empfehlungen einzelner Personen
> soll sich jeder selbst ein Bild machen. Releases gehen durch eine
> Qualitaets Sicherung.
Offenbar redest Du wieder von Sachen, die Du nicht kennst, und
unterstellst folglich, die snapshots wären keine gute Qualität.
Auch Postfix-Snapshots sind getestet, es sind nicht irgendwelche
automatisch gebackenen CVS-Extrakte, die laufen oder nicht oder
nichtmals compilieren, sondern Versionen, die sich einige Zeit (nach
Ermessen des Maintainers) im Produktionseinsatz bewährt haben.