majordomo o.ä. einrichten
Matthias Andree
> ich möchte auf einer Unix-Maschine eine mailingliste einrichten. Es ist
> gedacht das Teil als normale mailingliste und eventuell als Forum
> einzurichten.
...
> Es muß auch nichts sonderlich aufwendiges sein, da wir nur ca. 40 Teilnehmer
> haben.
> Allerdings sollte die Bedienung recht einfach sein.
Mailman, Listar.
X-Post & F'Up 2 dcs.mailserver.
--
Matthias Andree
Robin S. Socha
> Mailman
Ich bin auf tux.org gezwungen, mit Mailman zu arbeiten. Mailman ist aus
der Sicht des Admin *ganz* großer Dreck. Ich weiß nicht, wer sich dieses
hirntote Web-Interface ausgedacht hat, aber es war *keine* gute
Idee. Ansonsten hat das Teil auf seiner Todo-Liste eine verdammte Menge
Dinge, die bei ezmlm Standard sind. Schon sehr lange.
Ich bleibe dabei: Mailman ist im Vergleich zu ezmlm Tonnenware. Und zu
exim sage ich lieber auch nichts.
Detlef Neubauer
> * Matthias Andree <matthia...@gmx.de> writes:
>
> > Mailman
>
> Mailman ist aus der Sicht des Admin *ganz* großer Dreck.
Für meine Listenadmins ist Mailman mit seinem schönen bunten klicki
Admininterface genau das Richtige. Teilweise sind sie sogar damit
schon überfordert.
Oder habe ich dich falsch verstanden und du meinst mit Admin den
Mailmanadmin?
MfG
Detlef Neubauer
--
.oO GnuPG Key auf http://germany.keyserver.net/ Oo.
Ralf Hildebrandt
> Ich bin auf tux.org gezwungen, mit Mailman zu arbeiten. Mailman ist aus
> der Sicht des Admin *ganz* großer Dreck. Ich weiß nicht, wer sich dieses
> hirntote Web-Interface ausgedacht hat, aber es war *keine* gute
> Idee. Ansonsten hat das Teil auf seiner Todo-Liste eine verdammte Menge
> Dinge, die bei ezmlm Standard sind. Schon sehr lange.
Ja, manchmal NERVT das GUI, besonders wenn man approven will...
Fixed im aktuellen Alpha (?) Release.
> Ich bleibe dabei: Mailman ist im Vergleich zu ezmlm Tonnenware.
Problem: Der durchschnittliche Deutsche Lamer-User ist nicht in der
Lage, ezmlm zu bedienen (weder als Listenadmin, noch als User): Die
entspringen einer Klickibunti Kultur...
--
ralf.hil...@innominate.com innominate AG
Technical Consultant Don't be afraid of what you see -
Diplom-Informatiker be afraid of what you don't see!
tel: +49.(0)7000.POSTFIX fax: +49.(0)30.308806-77
Robin S. Socha
> "Robin S. Socha" <robin-dated-99...@socha.net> writes:
>> Mailman ist aus der Sicht des Admin *ganz* großer Dreck.
> Für meine Listenadmins ist Mailman mit seinem schönen bunten klicki
> Admininterface genau das Richtige. Teilweise sind sie sogar damit
> schon überfordert.
Ach ja? Dann möchte ich die mal sehen, wenn sie ein paar hundert oder
tausen Messages discarden müssen. Bockmist.
> Oder habe ich dich falsch verstanden und du meinst mit Admin den
> Mailmanadmin?
Parse error. Ach so. Äh... beide. Genau. Beide. So.
Robin S. Socha
> On 20 Aug 2001 03:39:36 -0500, Robin S. Socha
> <robin-dated-99...@socha.net> wrote:
>> Ich bin auf tux.org gezwungen, mit Mailman zu arbeiten. Mailman ist
>> aus der Sicht des Admin *ganz* großer Dreck. Ich weiß nicht, wer sich
>> dieses hirntote Web-Interface ausgedacht hat, aber es war *keine*
>> gute Idee. Ansonsten hat das Teil auf seiner Todo-Liste eine
>> verdammte Menge Dinge, die bei ezmlm Standard sind. Schon sehr lange.
> Ja, manchmal NERVT das GUI, besonders wenn man approven will... Fixed
> im aktuellen Alpha (?) Release.
Ach ja? Na supi. Ich hatte einmal eine Alpha release. Nie wieder.
>> Ich bleibe dabei: Mailman ist im Vergleich zu ezmlm Tonnenware.
> Problem: Der durchschnittliche Deutsche Lamer-User ist nicht in der
> Lage, ezmlm zu bedienen (weder als Listenadmin, noch als User): Die
> entspringen einer Klickibunti Kultur...
Pardon? Täusche ich mich, oder sind dir qmailadmin und ezmlm-web unbekannt?
Detlef Neubauer
> * Detlef Neubauer <detlef....@charite.de> writes:
> > "Robin S. Socha" <robin-dated-99...@socha.net> writes:
>
> >> Mailman ist aus der Sicht des Admin *ganz* großer Dreck.
>
> > Für meine Listenadmins ist Mailman mit seinem schönen bunten klicki
> > Admininterface genau das Richtige. Teilweise sind sie sogar damit
> > schon überfordert.
>
> Ach ja? Dann möchte ich die mal sehen, wenn sie ein paar hundert oder
> tausen Messages discarden müssen. Bockmist.
Klar ist das Mist. Da stimme ich dir voll zu. Es wäre schön, wenn
Mailman beides bieten würde. Webinterface und Steuermails nicht nur
für die User sondern auch für den Listenadmin. Soll ja dann in 2.1
möglich sein. Solange werde ich hier mit einem Update warten. Die
Alphaversion kommt mir jedenfalls nicht hier rauf.
Leider ist es aber so, dass der Durchschnitts-DAU-Listenadmin (-user)
gerade so bei der Bedienung mittels Webinterface durchblickt.
Dem jetzt noch zu verklickern, dass er das auch mittels Steuermail
machen kann. Sinnloses Unterfangen.
Ralf Hildebrandt
>> Problem: Der durchschnittliche Deutsche Lamer-User ist nicht in der
>> Lage, ezmlm zu bedienen (weder als Listenadmin, noch als User): Die
>> entspringen einer Klickibunti Kultur...
>
> Pardon? Täusche ich mich, oder sind dir qmailadmin und ezmlm-web unbekannt?
^^^^^^^^^
aha
Gibts doch. Gerrit wusste nix von einem Webinterface zu ezmlm-web.
Ralf Hildebrandt
> Klar ist das Mist. Da stimme ich dir voll zu. Es wäre schön, wenn
> Mailman beides bieten würde. Webinterface und Steuermails nicht nur
> für die User sondern auch für den Listenadmin. Soll ja dann in 2.1
> möglich sein. Solange werde ich hier mit einem Update warten. Die
> Alphaversion kommt mir jedenfalls nicht hier rauf.
Habe ich auch gar nicht zum Laufen bekommen (ist allerding schon 4
Wochen her)
Matthias Andree
> Ich bleibe dabei: Mailman ist im Vergleich zu ezmlm Tonnenware. Und zu
> exim sage ich lieber auch nichts.
ezmlm bedingt qmail und ist daher erst recht keine Option. Wer sich das
kranke qmail-queue-Interface ausgedacht hat, gehört standrechtlich
erschossen.
--
Matthias Andree
Robin S. Socha
> <robin-dated-99...@socha.net> wrote:
>>> Problem: Der durchschnittliche Deutsche Lamer-User ist nicht in der
>>> Lage, ezmlm zu bedienen (weder als Listenadmin, noch als User): Die
>>> entspringen einer Klickibunti Kultur...
>>
>> Pardon? Täusche ich mich, oder sind dir qmailadmin und ezmlm-web
>> unbekannt?
> ^^^^^^^^^
> aha
> Gibts doch. Gerrit wusste nix von einem Webinterface zu ezmlm-web.
Bitte wie meinen? Aber egal, da ist noch mehr:
http://qmail.org/top.html#ezmlm
Robin S. Socha
> ezmlm bedingt qmail und ist daher erst recht keine Option.
Umgekehrt wird das was, Bruder Matthias.
> Wer sich das kranke qmail-queue-Interface ausgedacht hat, gehört
> standrechtlich erschossen.
http://cr.yp.to/qmail/guarantee.html - so einfach ist das. *harrump*
Matthias Andree
> * Matthias Andree <matthia...@gmx.de> writes:
>
> > ezmlm bedingt qmail und ist daher erst recht keine Option.
>
> Umgekehrt wird das was, Bruder Matthias.
NAK. ezmlm läuft nicht ohne qmail und ist daher keine Option.
> > Wer sich das kranke qmail-queue-Interface ausgedacht hat, gehört
> > standrechtlich erschossen.
>
> http://cr.yp.to/qmail/guarantee.html - so einfach ist das. *harrump*
Schönes Herumgeblende, Postfix ist auch sicher und hat essentielle
Features, die qmail nichtmals mit Wrappern und Patches haben kann, und
hat Bugs nicht, die qmail hat. Die Diskussion ist aber müßig, weil Du
passend indoktriniert wurdest.
--
Matthias Andree
Gerrit Pape
> Features, die qmail nichtmals mit Wrappern und Patches haben kann, und
> hat Bugs nicht, die qmail hat. Die Diskussion ist aber müßig, weil Du
> passend indoktriniert wurdest.
Zur Klarstellung dieser Falschaussage:
Es sind keine Bugs in qmail-1.03 bekannt, und das seit 1998.
Gerrit.
--
pa...@innominate.com
innominate AG
tel: +49.30.308806-0 fax: -77 http://www.innominate.com
Daniel Roesen
> Es sind keine Bugs in qmail-1.03 bekannt, und das seit 1998.
Mein hello_world.c hat auch keine bekannten Bugs, und das seit 1987.
--
Ich finde, scharfe Waffen und "Feuern nach eigenem Ermessen" sollte zum
Adminjob dazugehören. [Lars Marowsky-Bree in d.a.s.r]
Marc Haber
>Es sind keine Bugs in qmail-1.03 bekannt, und das seit 1998.
Es ist ein qmail-1.03 aber mit heutigem Anforderungsprofil nicht
betreibbar, und was djb zu einem auf heutige Anwendung gepatchten
qmail sagt, hat er gerade heute morgen auf bugtraq erneut
eindrucksvoll bewiesen.
Er soll zurück in den Elfenbeinturm gehen.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Gerrit Pape
> Gerrit Pape <pa...@innominate.com> wrote:
>>Es sind keine Bugs in qmail-1.03 bekannt, und das seit 1998.
> Es ist ein qmail-1.03 aber mit heutigem Anforderungsprofil nicht
> betreibbar, und was djb zu einem auf heutige Anwendung gepatchten
Auch das ist falsch.
Aus welchem Grunde sollte ein Mailinglist Server mit qmail-1.03 und ezmlm
nach 'heutigem Anforderungsprofil' nicht betreibbar sein?
Matthias Andree
> Matthias Andree <matthia...@gmx.de> wrote:
> > Features, die qmail nichtmals mit Wrappern und Patches haben kann, und
> > hat Bugs nicht, die qmail hat. Die Diskussion ist aber müßig, weil Du
> > passend indoktriniert wurdest.
>
> Zur Klarstellung dieser Falschaussage:
>
> Es sind keine Bugs in qmail-1.03 bekannt, und das seit 1998.
^ sicherheitsrelevanten
"Bug" ist ein dehnbarer Begriff. Ich halte die Bandbreitenverschwendung,
die es auch ohne VERP betreibt, für eine Sachbeschädigung und damit für
einen Bug.
--
Matthias Andree
Matthias Andree
> Es ist ein qmail-1.03 aber mit heutigem Anforderungsprofil nicht
> betreibbar, und was djb zu einem auf heutige Anwendung gepatchten
> qmail sagt, hat er gerade heute morgen auf bugtraq erneut
> eindrucksvoll bewiesen.
Hast Du den URL des Archivs zur Hand? Ich hab' seit dem 17. nur 2 Mails
auf Bugtraq bekommen.
--
Matthias Andree
Matthias Andree
> Aus welchem Grunde sollte ein Mailinglist Server mit qmail-1.03 und ezmlm
> nach 'heutigem Anforderungsprofil' nicht betreibbar sein?
SMTP-Bandbreite, schnelle Filesysteme etc.
qmail ist nur einsetzbar, wenn man nicht nach Volumen bezahlt und eine
wirklich heftig böse schnelle Festplatte hat, bevorzugt 15.000/min,
sonst bricht es sich an seinen vielen synchronen Schreibzugriffen das
Genick.
Von Features und dem Umstand reden wir besser gar nicht erst.
--
Matthias Andree
Marc Haber
Ich habe Dir den kurzen Artikel von DJB zugemailt. Er sagte im prinzip
nur, was wir alle schon wissen, nämlich dass alle Patches, die
heutzutage notwendig sind, um qmail zu einem halbwegs
featurekompletten MTA zu machen, von ihm nicht autorisiert sind und er
sie für "garbage" hält.
Was er nicht schrieb, was ich aber mit an Sicherheit grenzender
Wahrscheinlichkeit annehme, ist, dass seine "guarantee" nur für ein
ungepatchtes, also in heutigem Rahmen unbrauchbares qmail gilt.
Matthias Andree
> Was er nicht schrieb, was ich aber mit an Sicherheit grenzender
> Wahrscheinlichkeit annehme, ist, dass seine "guarantee" nur für ein
> ungepatchtes, also in heutigem Rahmen unbrauchbares qmail gilt.
Du kriegst eh keine $$$ mehr, wenn Du eine Sicherheitslücke findest.
Das Fehlen von Sicherheitslücken ist notwendige, aber nicht hinreichende
Bedingung.
Sein Artikel ist übrigens als
http://www.securityfocus.com/archive/1/205875 verfügbar.
Wietse Venema ist bezüglich vergleichbarer Features in Postfix aber auch
reserviert, was sich aber darin begründet, daß die verwendete SASL
ziemlich fett und möglicherweise verbuggt ist.
--
Matthias Andree
Ralf Hildebrandt
> Wietse Venema ist bezüglich vergleichbarer Features in Postfix aber auch
> reserviert, was sich aber darin begründet, daß die verwendete SASL
> ziemlich fett und möglicherweise verbuggt ist.
Aber DJB ist kryptomaessig doch wohl recht/sehr fit -- da koennte er
ja mal ne Lib basteln (hat er schon?!) und die in qmail reinfrickeln.
Oder es ist ein qmail2 Feature.
Gerrit Pape
>> Aus welchem Grunde sollte ein Mailinglist Server mit qmail-1.03 und ezmlm
>> nach 'heutigem Anforderungsprofil' nicht betreibbar sein?
> SMTP-Bandbreite, schnelle Filesysteme etc.
> qmail ist nur einsetzbar, wenn man nicht nach Volumen bezahlt und eine
> wirklich heftig böse schnelle Festplatte hat, bevorzugt 15.000/min,
> sonst bricht es sich an seinen vielen synchronen Schreibzugriffen das
> Genick.
Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
_Mailinglist_ Server sinnvoller ist.
Dein 'Festplatten'-Argument ist haltlos. Hardware muss den Anforderungen
angepasst werden. Niemand bricht sich das Genick. qmail's queue handling
bringt meist Performance Vorteile. Belege Deine Behauptungen oder behalte
Sie fuer Dich.
Matthias Andree
> Aber DJB ist kryptomaessig doch wohl recht/sehr fit -- da koennte er
> ja mal ne Lib basteln (hat er schon?!) und die in qmail reinfrickeln.
>
> Oder es ist ein qmail2 Feature.
qmail2 gibt's seit 3 Jahren schon nicht. So what.
--
Matthias Andree
Ralf Hildebrandt
> Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
> _Mailinglist_ Server sinnvoller ist.
Bei Postfix gibts VERP und multi-RCPT. Und so laeufts (wieder) bei
bugtraq.com
Matthias Andree
> Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
> _Mailinglist_ Server sinnvoller ist.
Eine vernünftige VERP-Standardisierung und -Implementierung, VERP sollte
Sache des MX der Empfängerdomain sein.
> Dein 'Festplatten'-Argument ist haltlos. Hardware muss den Anforderungen
> angepasst werden. Niemand bricht sich das Genick. qmail's queue handling
> bringt meist Performance Vorteile. Belege Deine Behauptungen oder behalte
> Sie fuer Dich.
Nein, das Argument ist nicht haltlos, sondern nachweisbar.
"Meist Performance Vorteile". Wem gegenüber? Ich seh' keine.
Fakten:
1. http://cr.yp.to/qmail/faq/reliability.html#filesystems verbietet
schnelle Dateisysteme wie ext2, ext3, reiserfs, ffs+softupdates. Über
ufs+logging oder VxFS denke ich jetzt nicht nach, die kenn' ich zu
wenig.
2. qmail wirft mit synchronen Schreibzugriffen und temporären Files
regelrecht um sich (drei dauerhafte Files pro Mail)
Postfix zum Beispiel schreibt ein File je Mail und erlaubt
softupdates => 1 sychroner Schreibzugriff (2 ohne softupdates) für
das Einstellen in die Queue.
"Profile, don't speculate". Der Test zielt auf's Queue-Handling.
Rechner:
K6-2/300 im Tyan Trinity 100AT (S1590S), 1 MB L2-Cache, 100 MHz
128 MB SDRAM in 2 64 MB Modulen
Tekram DC-390 (AMD Am53C974 "PCscsi II")
Micropolis 4345WS (UWSCSI, 7200/min, 4.3 GB, Write Cache abgeschaltet)
3C900 Combo
FreeBSD 4.3-STABLE mit Port-Collection von Heute.
qmail-1.03_1 mit tcpserver-qmail-smtpd gemäß /var/qmail/doc/FAQ
postfix-20010525_3
/ und /usr sind ffs + softupdates
/var ist ffs, KEINE Softupdates, sofern nicht anders angegeben.
Test:
smtp-source -c -l 3000 -t emma+...@emma1.emma.line.org \
-s 5 -m 1000 localhost
Das verschickt aus 5 Prozessen gleichzeitig Mails an die angegebene
Adresse, die Mails bekommen 3000 Byte Payload, ein Zähler läuft mit
(-c), es werden 1000 Mails per SMTP an localhost verschickt.
syslogd läuft und loggt ebenfalls nach /var, was einen beträchtlichen
Teil der Schreibzugriffe ausmacht, aber das ist ja in der Praxis
so. (syslogd schreibt außerdem übers Netz)
Empfänger:
Der Empfänger ist ein Duron/700 im Gigabyte 7ZXR, 320 MB in 1 256 und
1 64 MB-Modul, Promise 20265R mit Western Digital WDC 420400D
(5400/min, 20 GB, Schreibcache abgeschaltet), Postfix
Snapshot-20010714, Linux 2.4.9 + ext3 0.9.6, 3C900 Combo.
Der Empfänger stellt DNS (dnscache + tinydns 1.05), syslog fürs ganze
LAN.
Ergebnis: (best viewed with fixed-width font)
inject = Zeit, bis smtp-source beendet ist
deliver = Zeit, bis letzte Mail zugestellt worden ist
w/sync und w/async = writes:-Counter aus mount -v
mail/s ist das offensichtliche.
TEST inject deliver w/sync w/async mail notes
UNIT s s 1 1 mail/s -
---------------------------------------------------------------------
qmail-1.03 153 313 14138 16696 3,2 *1
postfix-20010525_3 111 158 6086 7798 6,3 -
postfix, soft-updates 75 87 2158 4789 11,5 -
---------------------------------------------------------------------
*1 nach 50 Sekunden schaltet inetd den in.identd wegen "looping" ab.
qmail wurde wegen #1 oben nicht mit softupdates getestet, da es unsicher
wäre. Postfix ist mit softupdates sicher.
Ich hätt' gern noch exim, sendmail, zmailer gegengetestet, dafür hab'
ich aber jetzt keine Zeit.
--
Matthias Andree
begin dont_click_this_virus.exe
end
Site of the day: http://piology.org/ILOVEYOU-Signature-FAQ.html
Matthias Andree
> Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
> _Mailinglist_ Server sinnvoller ist.
Eine vernünftige VERP-Standardisierung und -Implementierung, VERP sollte
Sache des MX der Empfängerdomain sein.
> Dein 'Festplatten'-Argument ist haltlos. Hardware muss den Anforderungen
> angepasst werden. Niemand bricht sich das Genick. qmail's queue handling
> bringt meist Performance Vorteile. Belege Deine Behauptungen oder behalte
> Sie fuer Dich.
Nein, das Argument ist nicht haltlos, sondern nachweisbar.
"Meist Performance Vorteile". Wem gegenüber? Ich seh' keine.
Fakten:
1. http://cr.yp.to/qmail/faq/reliability.html#filesystems verbietet
schnelle Dateisysteme wie ext2, ext3, reiserfs, ffs+softupdates. Über
ufs+logging oder VxFS denke ich jetzt nicht nach, die kenn' ich zu
wenig.
2. qmail wirft mit synchronen Schreibzugriffen und temporären Files
regelrecht um sich (drei dauerhafte Files pro Mail)
Postfix zum Beispiel schreibt ein File je Mail und erlaubt
softupdates weniger sychrone Schreibzugriffe (noch weniger mit
softupdates) für das Einstellen in die Queue.
"Profile, don't speculate". Der Test zielt auf's Queue-Handling.
Rechner:
K6-2/300 im Tyan Trinity 100AT (S1590S), 1 MB L2-Cache, 100 MHz
128 MB SDRAM in 2 64 MB Modulen
Tekram DC-390 (AMD Am53C974 "PCscsi II")
Micropolis 4345WS (UWSCSI, 7200/min, 4.3 GB, Write Cache abgeschaltet)
3C900 Combo
FreeBSD 4.3-STABLE mit Port-Collection von heute.
Matthias Andree
> Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
> _Mailinglist_ Server sinnvoller ist.
Eine vernünftige VERP-Standardisierung und -Implementierung, VERP sollte
Sache des MX der Empfängerdomain sein.
> Dein 'Festplatten'-Argument ist haltlos. Hardware muss den Anforderungen
> angepasst werden. Niemand bricht sich das Genick. qmail's queue handling
> bringt meist Performance Vorteile. Belege Deine Behauptungen oder behalte
> Sie fuer Dich.
Nein, das Argument ist nicht haltlos, sondern nachweisbar.
Fakten:
Rechner:
Test:
Empfänger:
1 64 MB-Modul, VIA KT133 mit Western Digital WDC 420400D
Matthias Andree
> Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
> _Mailinglist_ Server sinnvoller ist.
Eine vernünftige VERP-Standardisierung und -Implementierung, VERP sollte
Sache des MX der Empfängerdomain sein.
> Dein 'Festplatten'-Argument ist haltlos. Hardware muss den Anforderungen
> angepasst werden. Niemand bricht sich das Genick. qmail's queue handling
> bringt meist Performance Vorteile. Belege Deine Behauptungen oder behalte
> Sie fuer Dich.
Nein, das Argument ist nicht haltlos, sondern nachweisbar.
Fakten:
Rechner:
Test:
Empfänger:
Die Testergebnisse liegen auf http://mandree.home.pages.de/postfix/vsqmail.html
Gerrit Pape
einer internationalen Mailing List (postfix-users) als 'bogus claims' zu
bezeichnen: http://groups.yahoo.com/group/postfix-users/message/40628
Ich distanziere mich deutlich von einem solchen Verhalten.
Ich bin in diesen thread hineingesprungen wegen 'bogus claims' about qmail:
Matthias Andree <matthia...@gmx.de> wrote:
> Features, die qmail nichtmals mit Wrappern und Patches haben kann, und
> hat Bugs nicht, die qmail hat. Die Diskussion ist aber müßig, weil Du
> passend indoktriniert wurdest.
Wir sind uns wohl einig geworden, dass qmail-1.03 keine bekannten bugs hat.
Matthias Andree <matthia...@gmx.de> wrote:
>> Aus welchem Grunde sollte ein Mailinglist Server mit qmail-1.03 und ezmlm
>> nach 'heutigem Anforderungsprofil' nicht betreibbar sein?
> SMTP-Bandbreite, schnelle Filesysteme etc.
> qmail ist nur einsetzbar, wenn man nicht nach Volumen bezahlt und eine
> wirklich heftig böse schnelle Festplatte hat, bevorzugt 15.000/min,
> sonst bricht es sich an seinen vielen synchronen Schreibzugriffen das
> Genick.
Matthias 'benchmark' Test zeigt eindeutig, dass qmail-1.03 einsetzbar ist.
Mein Beduerfnis ist es nur, Unwahrheiten klarzustellen, die hier verbreitet
werden.
Ich fuehre keinen Kampf gegen postfix, wie Matthias Andree gegen qmail.
Entweder sein Claims sind richtig und begruendet, oder er muss sich eine
Berichtigung seiner Aussagen gefallen lassen.
Matthias Andree <matthia...@gmx.de> wrote:
> Gerrit Pape <pa...@innominate.com> writes:
> Eine vernünftige VERP-Standardisierung und -Implementierung, VERP sollte
> Sache des MX der Empfängerdomain sein.
>> Dein 'Festplatten'-Argument ist haltlos. Hardware muss den Anforderungen
>> angepasst werden. Niemand bricht sich das Genick. qmail's queue handling
>> bringt meist Performance Vorteile. Belege Deine Behauptungen oder behalte
>> Sie fuer Dich.
> Nein, das Argument ist nicht haltlos, sondern nachweisbar.
> "Meist Performance Vorteile". Wem gegenüber? Ich seh' keine.
> Fakten:
Zu diesen Fakten bitte das Followup zu o.g.
http://groups.yahoo.com/group/postfix-users/message/40628 lesen, dass ich
heute Mittag abgeschickt habe, aber unerklaerlicher Weise noch nicht
zugestellt wurde:
2001-08-23 12:12:23.658720500 info msg 275505: bytes 3543 from
<pa...@innominate.com> qp 2161 uid 507
2001-08-23 12:12:23.661677500 starting delivery 9: msg 275505 to remote
postfi...@postfix.org
2001-08-23 12:12:23.661691500 status: local 0/10 remote 1/20
2001-08-23 12:12:24.944281500 delivery 9: success:
168.100.1.4_accepted_message./Remote_host_said:_250_Ok:_queued_as_3864328C82/
2001-08-23 12:12:24.944298500 status: local 0/10 remote 0/20
Matthias Andree
>
> Matthias Andree hat es fuer noetig gehalten, eine meiner Aussagen auf
> einer internationalen Mailing List (postfix-users) als 'bogus claims' zu
> bezeichnen: http://groups.yahoo.com/group/postfix-users/message/40628
> Ich distanziere mich deutlich von einem solchen Verhalten.
Du kannst Dich distanzieren, wovon Du willst, Du kannst aber nicht
belegen, daß qmails Queue-Verwaltung Performancevorteile bringt, was
auch durch den Benchmark belegt wurde.
> Mein Beduerfnis ist es nur, Unwahrheiten klarzustellen, die hier verbreitet
> werden.
Dann fang' mal bitte an, Deine eigenen Behauptungen zu belegen, die ich
als unwahr bezeichnet habe. qmail IST NICHT schnell. Es ist vielleicht
schneller als Sendmail-8.8.x aus der Kiste, das aktuell war, als
qmail-1.0x herauskam.
> Ich fuehre keinen Kampf gegen postfix, wie Matthias Andree gegen qmail.
Ich führe keinen Kampf gegen qmail. Du solltest nur akzeptieren, daß
qmail von anderen Mailern überholt worden ist. Was Features angeht, was
Geschwindigkeit angeht (beides zugleich), und ohne, daß die Sicherheit
darunter leiden muß.
> Entweder sein Claims sind richtig und begruendet, oder er muss sich eine
> Berichtigung seiner Aussagen gefallen lassen.
Drum. Wo sind die Beweise, daß qmail's umständliche Queue-Handhabung
Performancevorteile bringt? Es gibt keine. Ich hab' sendmail und Exim
noch nicht im Vergleich gehabt, gehe jedoch davon aus, daß deren
Queue-Handling auch weniger I/O erzeugt als das von qmail.
Daß Dan nix um softupdates gibt, zeigt allenfalls, daß er die Paper
nicht gelesen hat, die sich damit befassen, oder es aus unerfindlichen
Gründen nicht für nötig hält, ein qmail-1.04 herauszugeben, das sicher
ist mit softupdates. Zur weiteren Diskussion sei auf die Archive der
Postfix- und Linux-Kernel-Mailingliste verwiesen.
--
Matthias Andree
Matthias Andree
>
> Matthias Andree hat es fuer noetig gehalten, eine meiner Aussagen auf
> einer internationalen Mailing List (postfix-users) als 'bogus claims' zu
> bezeichnen: http://groups.yahoo.com/group/postfix-users/message/40628
> Ich distanziere mich deutlich von einem solchen Verhalten.
Du kannst Dich distanzieren, wovon Du willst, Du kannst aber nicht
belegen, daß qmails Queue-Verwaltung Performancevorteile bringt, was
auch durch den Benchmark belegt wurde.
> Mein Beduerfnis ist es nur, Unwahrheiten klarzustellen, die hier verbreitet
> werden.
Dann fang' mal bitte an, Deine eigenen Behauptungen zu belegen, die ich
als unwahr bezeichnet habe. qmail IST NICHT schnell. Es ist vielleicht
schneller als Sendmail-8.8.x "aus der Kiste", das aktuell war, als
qmail-1.0x herauskam.
> Ich fuehre keinen Kampf gegen postfix, wie Matthias Andree gegen qmail.
Ich führe keinen Kampf gegen qmail. Du solltest nur akzeptieren, daß
qmail von anderen Mailern überholt worden ist. Was Features angeht, was
Geschwindigkeit angeht (beides zugleich), und ohne, daß die Sicherheit
darunter leiden muß.
> Entweder sein Claims sind richtig und begruendet, oder er muss sich eine
> Berichtigung seiner Aussagen gefallen lassen.
Drum. Wo sind die Beweise, daß qmails umständliche Queue-Handhabung
Performancevorteile bringt? Es gibt keine. Ich hab' sendmail und Exim
noch nicht im Vergleich gehabt, gehe jedoch davon aus, daß deren
Queue-Handling auch weniger I/O erzeugt als das von qmail.
Daß Dan nichts um softupdates gibt, zeigt allenfalls, daß er die Paper
nicht gelesen hat, die sich damit befassen, oder es aus unerfindlichen
Gründen nicht für nötig hält, ein qmail-1.04 herauszugeben, das sicher
zu verwenden ist mit softupdates -- diesbezüglich habe ich keine Zahlen,
denke jedoch, daß qmail in ähnlichem Maße wie Postfix von softupdates
profitieren würde. Zur weiteren Diskussion sei auf die Archive der
Gerrit Pape
> On 22 Aug 2001 12:37:38 GMT, Gerrit Pape <pa...@innominate.com> wrote:
>> Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
>> _Mailinglist_ Server sinnvoller ist.
> Bei Postfix gibts VERP und multi-RCPT. Und so laeufts (wieder) bei
> bugtraq.com
Das kann bei einem Mailinglist Server, der an standard smtp server
ausliefert, nicht funktionieren.
Gerrit Pape
> Gerrit Pape wrote:
>>
>> Matthias Andree hat es fuer noetig gehalten, eine meiner Aussagen auf
>> einer internationalen Mailing List (postfix-users) als 'bogus claims' zu
>> bezeichnen: http://groups.yahoo.com/group/postfix-users/message/40628
>> Ich distanziere mich deutlich von einem solchen Verhalten.
>> Mein Beduerfnis ist es nur, Unwahrheiten klarzustellen, die hier verbreitet
>> werden.
> Dann fang' mal bitte an, Deine eigenen Behauptungen zu belegen, die ich
> als unwahr bezeichnet habe. qmail IST NICHT schnell. Es ist vielleicht
> schneller als Sendmail-8.8.x "aus der Kiste", das aktuell war, als
> qmail-1.0x herauskam.
Du machst Dich langsam laecherlich. Ich habe ueberhaupt keinen Bedarf, hier
die Performance von qmail zu diskutieren, hiermit ziehe ich meine
'wagemutige' Behauptung
"qmail's queue handling bringt meist Performance Vorteile."
zurueck. I apologize.
Meine Aussage war so nichtssagend, dass man sie garnicht belegen kann.
Deine Aussagen, gegen die ich eingesprochen habe, waren nicht nichtssagend:
[postfix] "hat Bugs nicht, die qmail hat."
[ein Mailinglist Server mit qmail-1.03 und ezmlm ist nach 'heutigem
Anforderungsprofil' nicht betreibbar, wegen] "SMTP-Bandbreite, schnelle
Filesysteme etc."
Dein nichtrepraesentativer Test (s.a.
http://groups.yahoo.com/group/postfix-users/message/40703) widerlegt
letzteres eindeutig.
Aus scheinbar kindischem Trotz haeltst du dich an dem einen Satz meinerseits
fest und greift mich sogar in einer internationalen Mailing-Liste
(postfix-users), die mit diesem thread ueberhaupt garnicht zu tun hat,
persoenlich an und noetigst mich somit, dort ein Statement abzugeben.
Ich habe hier nicht einmal das Wort 'postfix' benutzt.
Du stiehlst mir meine Zeit, bitte lass uns diesen thread endlich beenden.
Matthias Andree
> Ralf Hildebrandt <Ralf.Hil...@innominate.com> wrote:
> > On 22 Aug 2001 12:37:38 GMT, Gerrit Pape <pa...@innominate.com> wrote:
>
> >> Nonsens. Multi-RCPT breaks VERP, ueberleg Dir mal was fuer einen
> >> _Mailinglist_ Server sinnvoller ist.
>
> > Bei Postfix gibts VERP und multi-RCPT. Und so laeufts (wieder) bei
> > bugtraq.com
>
> Das kann bei einem Mailinglist Server, der an standard smtp server
> ausliefert, nicht funktionieren.
Warum nicht? Postfix erzeugt die VERPs erst bei der Zustellung, nicht
schon in der Queue, wie qmail das macht, kann ich den Logfiles nicht
entnehmen, die sind nicht ausführlich genug, und ich halte jetzt nicht
die Welt an, um das herauszufinden.
Du solltest Dir wirklich mal VERP_README aus Postfix durchlesen, bevor
Du sagst "kann nicht gehen": Es geht.
qmail wird zur /Auslieferung/ von ezmlm-(idx?)-Listen nicht mehr
benötigt, Postfix-Snapshots seit AFAIR Juli bringen einen VERP-fähigen
QMQP-Server mit, man braucht nur ezmlm beizubringen, qmail-qmqpc zu
benutzen statt qmail-queue, und das ist trivial.
Matthias Andree
> "qmail's queue handling bringt meist Performance Vorteile."
>
> zurueck. I apologize.
Danke.
> [postfix] "hat Bugs nicht, die qmail hat."
> [ein Mailinglist Server mit qmail-1.03 und ezmlm ist nach 'heutigem
> Anforderungsprofil' nicht betreibbar, wegen] "SMTP-Bandbreite, schnelle
> Filesysteme etc."
>
> Dein nichtrepraesentativer Test (s.a.
> http://groups.yahoo.com/group/postfix-users/message/40703) widerlegt
> letzteres eindeutig.
Deswegen sah sich also auch Securityfocus genötigt, qmail als
SMTP-Client zu ersetzen, wegen erdrückender Systemlast?
> Aus scheinbar kindischem Trotz haeltst du dich an dem einen Satz meinerseits
> fest und greift mich sogar in einer internationalen Mailing-Liste
> (postfix-users), die mit diesem thread ueberhaupt garnicht zu tun hat,
> persoenlich an und noetigst mich somit, dort ein Statement abzugeben.
> Ich habe hier nicht einmal das Wort 'postfix' benutzt.
Brauchst Du auch nicht, es ist das einfachste Gegenbeispiel zu Deiner
inzwischen zurückgezogenen Behauptung gewesen. Eins genügt.
Es geht mir nicht darum, qmail oder einzelne Personen zu diskreditieren,
sondern zu belegen, daß die Performance-Vorteile von qmails Queue-Format
nicht gegeben sind. Daß VERP /derzeit noch/ Bandbreitensauerei erster
Güte ist, läßt sich nicht vermeiden, wer jedoch einen MLM ohne VERP
benutzt, ist mit qmail schlecht beraten.
Gerrit Pape
> Gerrit Pape <pa...@innominate.com> writes:
>> Ralf Hildebrandt <Ralf.Hil...@innominate.com> wrote:
>>
>> > Bei Postfix gibts VERP und multi-RCPT. Und so laeufts (wieder) bei
>> > bugtraq.com
>>
>> Das kann bei einem Mailinglist Server, der an standard smtp server
>> ausliefert, nicht funktionieren.
> Warum nicht? Postfix erzeugt die VERPs erst bei der Zustellung, nicht
> schon in der Queue, wie qmail das macht, kann ich den Logfiles nicht
> entnehmen, die sind nicht ausführlich genug, und ich halte jetzt nicht
> die Welt an, um das herauszufinden.
Matthias, Du scheinst verwirrt zu sein.
> Du solltest Dir wirklich mal VERP_README aus Postfix durchlesen, bevor
> Du sagst "kann nicht gehen": Es geht.
VERP_README ist im aktuellen Release nicht enthalten, habe es im
snapshot-20010808 gefunden.
Das README beschreibt _empfaengerseitiges_ VERP.
Das kann bei einem Mailinglist Server, der an _standard smtp server_
ausliefert, nicht funktionieren.
"standard smtp server" != postfix snapshot-20010808
Ich hoffe, Du hast verstanden.
> qmail wird zur /Auslieferung/ von ezmlm-(idx?)-Listen nicht mehr
> benötigt, Postfix-Snapshots seit AFAIR Juli bringen einen VERP-fähigen
> QMQP-Server mit, man braucht nur ezmlm beizubringen, qmail-qmqpc zu
> benutzen statt qmail-queue, und das ist trivial.
Schoen, was hat das mit dem Thema zu tun?
Gerrit Pape
Matthias Andree <matthia...@gmx.de> wrote:
> Gerrit Pape <pa...@innominate.com> writes:
>> [postfix] "hat Bugs nicht, die qmail hat."
>> [ein Mailinglist Server mit qmail-1.03 und ezmlm ist nach 'heutigem
>> Anforderungsprofil' nicht betreibbar, wegen] "SMTP-Bandbreite, schnelle
>> Filesysteme etc."
>>
>> Dein nichtrepraesentativer Test (s.a.
>> http://groups.yahoo.com/group/postfix-users/message/40703) widerlegt
>> letzteres eindeutig.
> Deswegen sah sich also auch Securityfocus genötigt, qmail als
> SMTP-Client zu ersetzen, wegen erdrückender Systemlast?
Ich denke, "nach 'heutigem Anforderungsprofil' nicht betreibbar" ist
unmissverstaendlich. qmail-1.03 + ezmlm wird heutzutage eingesetzt.
>> Aus scheinbar kindischem Trotz haeltst du dich an dem einen Satz meinerseits
>> fest und greift mich sogar in einer internationalen Mailing-Liste
>> (postfix-users), die mit diesem thread ueberhaupt garnicht zu tun hat,
>> persoenlich an und noetigst mich somit, dort ein Statement abzugeben.
>> Ich habe hier nicht einmal das Wort 'postfix' benutzt.
> Brauchst Du auch nicht, es ist das einfachste Gegenbeispiel zu Deiner
> inzwischen zurückgezogenen Behauptung gewesen. Eins genügt.
Du hast den Kommentar zum Rueckzug meiner Behauptung nicht verstanden:
"Meine Aussage war so nichtssagend, dass man sie garnicht belegen kann."
Genauso wenig kann man sie widerlegen, ein Gegenbeispiel ist nichtig.
Genauso wenig kann man sie als 'bogus claim' bezeichnen.
Ich hoffe, Du hast verstanden und wir koennen diese Farce endlich beenden.
> Es geht mir nicht darum, qmail oder einzelne Personen zu diskreditieren,
Dem widersprechen Deine Aussagen, qmail-1.03 haette bugs, sei heute nicht
mehr betreibbar und "Since Gerrit Pape made bogus claims about qmail
performance".
Ralf Hildebrandt
> VERP_README ist im aktuellen Release nicht enthalten, habe es im
> snapshot-20010808 gefunden.
Er hat auch snapshot gesagt, nicht release!
Matthias Andree
> Ich denke, "nach 'heutigem Anforderungsprofil' nicht betreibbar" ist
> unmissverstaendlich. qmail-1.03 + ezmlm wird heutzutage eingesetzt.
...sprach's und ließ alle übrigen Kriterien außer acht. Sendmail +
majordomo werden auch eingesetzt. Eine Qualitätsauszeichnung ist das
sicher nicht.
> Du hast den Kommentar zum Rueckzug meiner Behauptung nicht verstanden:
> "Meine Aussage war so nichtssagend, dass man sie garnicht belegen
> kann."
Ich hab's mir beim letzten Mal verkniffen, sei jetzt nachgeholt: wenn
Dir Deine Aussage nicht mehr gefällt, wird ihre Relevanz wegdiskutiert?
Oder wird hier "Hase und Igel" bemüht?
> Genauso wenig kann man sie widerlegen, ein Gegenbeispiel ist nichtig.
Nein, es ist real existent und belegt, daß qmails Queue-Handling bei "5
Leute schieben 1000 1-to-1-mailings rein" PerformanceNACHTEILE gegenüber
anderen etablierten Verfahren hat.
Wenn Du ein Beispiel findest, bei dem qmails Queue schneller als
Postfix' Queue ist, und das nachvollziehbar ist, werde ich Deinen
Benchmark in meinem verlinken.
> Genauso wenig kann man sie als 'bogus claim' bezeichnen.
Warum trifft Dich Dans Lieblingsformulierung so hart?
> > Es geht mir nicht darum, qmail oder einzelne Personen zu diskreditieren,
>
> Dem widersprechen Deine Aussagen, qmail-1.03 haette bugs, sei heute nicht
> mehr betreibbar und "Since Gerrit Pape made bogus claims about qmail
> performance".
Hat jemand anders als Gerrit Pape diese Behauptungen aufgestellt?
Waren sie nicht öffentlich?
Ist qmail nicht ohne VERP ein Bandbreitenschwein allererster Güte?
Ist nicht deutlich genug geworden, daß qmail deutlich langsamer als
mindestens ein anderer, gängiger, MTA ist?
Was daran eine persönliche Diskreditierung sein soll, müßtest Du mir
erklären, aber bitte nicht öffentlich, das interessiert hier niemanden.
qmail erfüllt diverse Anforderungen nicht, sei das nun
Adreßumschreibung/Masquerading (qmail-inject zählt nicht, nützt auf
Gateways nicht), sei es die Möglichkeit, Mail für unbekannte Nutzer
direkt im smtpd abzuweisen, um Bandbreite zu sparen, sei es nativer
UUCP-Transport ohne .qmail-default-Kludges oder triviale Adreßprüfungen,
von CNAME abgesehen, seien es RFC-konforme Bounces.
Bei genauer Betrachtung von http://cr.yp.to/qmail.html auch über den
Tellerrand hinaus fällt auf, daß viele der dort dargebotenen
Anpreisungen nicht exklusiv sind bzw. inzwischen von anderen MTAs besser
erfüllt werden. Die Seite ist historische Übertreibung, die qmail nicht
verdient hat, dazu ist es zu solide.
Ich kann nicht guten Gewissens Behauptungen stehen lassen, ein
Queuesystem, das allein zum Einstellen in die Queue (ohne Cleanups) 13
synchrone Transaktionen erzeugt und schließlich drei Dateien hinterläßt,
das ganze nur auf synchronen Dateisystemen (außer reine Filedaten, die
asynchron sein dürfen), wäre für die Performance von Vorteil.
Damit wir uns nicht falsch verstehen: qmail ist kein Problem, Du darfst
qmail solange benutzen, wie Du damit glücklich bist, es erfüllt aber
gängige Anforderungen nicht, und weil ich die nicht für ausgefallen
halte, und sehe, daß von dem, was qmail einst gegenüber sendmail-8.8
ausgezeichnet hat, im Vergleich z. B. mit Postfix nicht viel geblieben
ist, kann ich nicht guten Gewissens qmail anderen für Neuinstallationen
empfehlen, dazu ist der Folgeaufwand zu groß.
Matthias Andree
> VERP_README ist im aktuellen Release nicht enthalten, habe es im
> snapshot-20010808 gefunden.
> Das README beschreibt _empfaengerseitiges_ VERP.
Was ist denn ein QMQP- oder SMTP-Server, wenn kein Mailempfänger? Warum
liest Du nicht, daß man dazu snapshot Juli 2001 oder neue braucht?
> Das kann bei einem Mailinglist Server, der an _standard smtp server_
> ausliefert, nicht funktionieren.
>
> "standard smtp server" != postfix snapshot-20010808
>
> Ich hoffe, Du hast verstanden.
Du hast immer noch nicht verstanden, weil Du nicht hingesehen hast oder
von qmail's "ich bau mir ein qmail-queue" geblendet bist. Schlaf'
drüber, reib' Dir am nächsten Morgen den Schlaf aus den Augen und guck'
nochmal hin.
Daniel Roesen
> Was er nicht schrieb, was ich aber mit an Sicherheit grenzender
> Wahrscheinlichkeit annehme, ist, dass seine "guarantee" nur für ein
> ungepatchtes, also in heutigem Rahmen unbrauchbares qmail gilt.
Diese "Security guarantee" ist sowieso sie Albernheit schlechthin.
Wenn ich einen Einbruch auf einem MTA-System habe, ist allein der
Aufwand zur Post-Mortem-Analyse und Wiederherstellung des System
WEIT teurer als seine paar Piepen da. Ganz zu schweigen von sonstigen
Schaeden durch Ausfallzeit und/oder ausspionierte Daten oder gar
von der geknackten Kiste aus gefuehrten Angriffe. Da fallen $500 mehr
oder weniger nicht im Geringsten auf.
Aber das ist wie bei SLAs... Schmerzen verursachen sie dem Anbieter
allermeistens nicht wirklich. Reine Marketingmassnahme... Und DJB
braucht halt "spektakulaeres" Marketing. Seine Software spricht wohl
nicht genug fuer sich selbst.
Gruss,
Daniel
--
Ich finde, scharfe Waffen und "Feuern nach eigenem Ermessen" sollte zum
Adminjob dazugehören. [Lars Marowsky-Bree in d.a.s.r]
Daniel Roesen
> Aber DJB ist kryptomaessig doch wohl recht/sehr fit -- da koennte er
> ja mal ne Lib basteln (hat er schon?!) und die in qmail reinfrickeln.
Koennte. Tut er aber nicht. Er umschifft sowohl in Qmail als auch in
djbdns die Implementation saemtlicher Features, die etwas komplexer
werden und die Gefahr von Fehlern rapide steigt. Er baut ein paar FUD-
Gebaeude um sich davor zu druecken und ueberlaesst das dann anderen,
deren Patches er dann oeffentlich als "garbage" bezeichnen kann.
> Oder es ist ein qmail2 Feature.
Ich hab seit qmail 1.03 noch nix neues gesehen.
Robin S. Socha
>> Aber DJB ist kryptomaessig doch wohl recht/sehr fit -- da koennte er
>> ja mal ne Lib basteln (hat er schon?!) und die in qmail reinfrickeln.
> Koennte. Tut er aber nicht. Er umschifft sowohl in Qmail als auch in
> djbdns die Implementation saemtlicher Features, die etwas komplexer
> werden und die Gefahr von Fehlern rapide steigt.
Er schreibt Software für den Hausgebrauch und erlaubt Dir, sie zu
benutzen. Wenn Du kommerziellen Software haben willst, kannst Du
sendmail und BIND kaufen.
Daniel Roesen
>> Koennte. Tut er aber nicht. Er umschifft sowohl in Qmail als auch in
>> djbdns die Implementation saemtlicher Features, die etwas komplexer
>> werden und die Gefahr von Fehlern rapide steigt.
>
> Er schreibt Software für den Hausgebrauch und erlaubt Dir, sie zu
> benutzen.
Seine Software reicht nichtmal fuer meinen Hausgebrauch, geschweigedenn
fuer meine bisherigen kommerziellen Anwendungen.
> Wenn Du kommerziellen Software haben willst, kannst Du sendmail und
> BIND kaufen.
Weder sendmail noch BIND sind kommerzielle Software, nur weil es
kommerzielle Derivate davon gibt.
Aber du musst ja deinem Hohepriester in seiner "BIND company" Predikt
folgen. Reflektieren von Fakten ist so anstrengend...
Und ich bin mit meiner freien Software (Postfix, BIND) hochzufrieden,
also warum sollte ich Geld aus dem Fenster werfen...
Ralf Hildebrandt
> Er schreibt Software für den Hausgebrauch und erlaubt Dir, sie zu
> benutzen. Wenn Du kommerziellen Software haben willst, kannst Du
> sendmail und BIND kaufen.
Das stimmt allerdings. Man hat manchmal den EIndruck BIND und Sendmail
seien so komplex, um Support zu verkaufen...
Gerrit Pape
>> Das kann bei einem Mailinglist Server, der an _standard smtp server_
>> ausliefert, nicht funktionieren.
>>
>> "standard smtp server" != postfix snapshot-20010808
>>
>> Ich hoffe, Du hast verstanden.
> Du hast immer noch nicht verstanden, weil Du nicht hingesehen hast oder
> von qmail's "ich bau mir ein qmail-queue" geblendet bist. Schlaf'
> drüber, reib' Dir am nächsten Morgen den Schlaf aus den Augen und guck'
> nochmal hin.
Umm, http://groups.yahoo.com/group/postfix-users/message/40766 .
>> VERP_README ist im aktuellen Release nicht enthalten, habe es im
>> snapshot-20010808 gefunden.
>> Das README beschreibt _empfaengerseitiges_ VERP.
> Was ist denn ein QMQP- oder SMTP-Server, wenn kein Mailempfänger? Warum
Huh?, verstehe ich nicht, warum Du diese Frage stellst.
> liest Du nicht, daß man dazu snapshot Juli 2001 oder neue braucht?
Weil ich mich schon die ganze Zeit wunderte, warum Du mein 'meistens' mit
einem postfix snapshot widerlegen willst, weil ich nicht davon ausgehe, dass
bugtraq mit einem postfix snapshot betrieben wird (siehe weiter oben in
diesem thread), Sorry, deswegen habe ich uebersehen, dass Du weiter unten
von einem snapshot schreibst.
Daniel Roesen
> Weil ich mich schon die ganze Zeit wunderte, warum Du mein 'meistens' mit
> einem postfix snapshot widerlegen willst, weil ich nicht davon ausgehe, dass
> bugtraq mit einem postfix snapshot betrieben wird (siehe weiter oben in
> diesem thread),
Da muss ich Dich leider enttaeuschen. Bugtraq _wird_ mit einem
Postfix Snapshot betrieben. Warum auch nicht, die Snapshots haben
production quality.
GRuss,
Daniel
Ralf Hildebrandt
> Da muss ich Dich leider enttaeuschen. Bugtraq _wird_ mit einem
> Postfix Snapshot betrieben. Warum auch nicht, die Snapshots haben
> production quality.
Das war der ganze Grund der Aktion: bugtraq war so ungluecklich mit
listserv && postfix (eher mit listserv), sodass wieder auf qmail und
ezmlm zureuckgewechselt wurde.
Dann waren sie wieder gluecklich mit ezmlm, aber nicht mit qmail -
weil die Sende Performance runtergegangen ist, aber das Bouncehandling
wieder gut war.
http://groups.yahoo.com/group/postfix-users/message/28387
Dann hat Wietse the qmqp in Postfix reingefrickelt und das ganz
securityfocus zum Testen gegeben. Und so laeufts wohl noch?!
Matthias Andree
> Dann hat Wietse the qmqp in Postfix reingefrickelt und das ganz
> securityfocus zum Testen gegeben. Und so laeufts wohl noch?!
Vor einer Woche zumindest.
Matthias Andree
> > Du hast immer noch nicht verstanden, weil Du nicht hingesehen hast oder
> > von qmail's "ich bau mir ein qmail-queue" geblendet bist. Schlaf'
> > drüber, reib' Dir am nächsten Morgen den Schlaf aus den Augen und guck'
> > nochmal hin.
>
> Umm, http://groups.yahoo.com/group/postfix-users/message/40766 .
Und jetzt? Erklärung ist an die Postfix-Users-Mailingliste gegangen. Du
redest von Mailinglistensoftware, die sofort remote abkippt und deswegen
VERP durch single-RCPT ersetzt. Ich rede von Mailinglistensoftware, die
lokal den MTA mit VERP-(Multi-RCPT)-Mail zukippt, die der dann
wegbaggert.
Ich habe in meinem Benchmark[1] inzwischen das "verbotene" (weil
unsichere) qmail+softupdates, exim 3.33 und sendmail 8.11.3 ebenfalls
nachgetragen. In Defaultkonfiguration laufen alle schneller als qmail -
Postfix 11,5 Mails/s, Exim 8,8 Mails/s, Sendmail 6,2 Mails/s, qmail
würde mit softupdates ca. 5 Mails/s durchschieben, darf es aber nicht,
weil unsicher, und ohne Softupdates schafft's 3,2 Mails/s. Man muß hier
zugestehen, daß nicht alle MTA derart exzessives Queue-Handling wie
qmail betreiben und insbesondere Sendmail und Exim synchron zuzustellen
scheinen, und der Rechner nie so belastet war, daß man von Parallelität
in Postfix oder qmail hätte profitieren können.
[1] http://mandree.home.pages.de/postfix/vsqmail.html
> > Was ist denn ein QMQP- oder SMTP-Server, wenn kein Mailempfänger? Warum
>
> Huh?, verstehe ich nicht, warum Du diese Frage stellst.
Der lokale SMTP oder QMQP-Server ist der einzige, mit dem die
Mailinglistensoftware reden sollte, darum interessieren die Fähigkeiten
fremder SMTPDS von der Stange die Mailingliste nicht.
> Weil ich mich schon die ganze Zeit wunderte, warum Du mein 'meistens' mit
> einem postfix snapshot widerlegen willst, weil ich nicht davon ausgehe, dass
> bugtraq mit einem postfix snapshot betrieben wird
Wird es aber, weil nur die Snapshots VERP und QMQP reden.
Die allermeisten Postfix-Snapshots sind nicht schlechter als
Beta-Releases oder die Release. In den Ausnahmefällen, an die ich mich
erinnere, war nach 3 Tagen spätestens der nächste Snapshot da.
Ralf Hildebrandt
> Ich habe in meinem Benchmark[1] inzwischen das "verbotene" (weil
> unsichere) qmail+softupdates, exim 3.33 und sendmail 8.11.3 ebenfalls
> nachgetragen. In Defaultkonfiguration laufen alle schneller als qmail -
> Postfix 11,5 Mails/s, Exim 8,8 Mails/s, Sendmail 6,2 Mails/s, qmail
> würde mit softupdates ca. 5 Mails/s durchschieben, darf es aber nicht,
> weil unsicher, und ohne Softupdates schafft's 3,2 Mails/s.
Ich kann mich dunkel daran erinnern, dass Wietse mal daran gezweifelt
hat, dass Sendmail Queuehandling "safe" ist. D.h. es wuerde alles
async schreiben, und waere daher so schnell...
Claus Aßmann
: Ich habe in meinem Benchmark[1] inzwischen das "verbotene" (weil
: unsichere) qmail+softupdates, exim 3.33 und sendmail 8.11.3 ebenfalls
: nachgetragen. In Defaultkonfiguration laufen alle schneller als qmail -
: Postfix 11,5 Mails/s, Exim 8,8 Mails/s, Sendmail 6,2 Mails/s, qmail
: würde mit softupdates ca. 5 Mails/s durchschieben, darf es aber nicht,
: weil unsicher, und ohne Softupdates schafft's 3,2 Mails/s. Man muß hier
: zugestehen, daß nicht alle MTA derart exzessives Queue-Handling wie
: qmail betreiben und insbesondere Sendmail und Exim synchron zuzustellen
: scheinen, und der Rechner nie so belastet war, daß man von Parallelität
: in Postfix oder qmail hätte profitieren können.
sendmail startet per Default einen neuen Prozess um Mail zu verschicken
(Background mode). Siehe DeliveryMode in doc/op/op.*. Wenn Du das
auf 'i' setzt bekommst Du hoechstwahrscheinlich ca. 40% bessere
Werte. Wenn Du 8.12 benutzt, wird es nochmals schneller...
Ich bekomme auf einem PC mit 450MHz AMD K6 und IDE Disks
16 - 25 msg/s mit sendmail 8.12, je nach Konfiguration.
: [1] http://mandree.home.pages.de/postfix/vsqmail.html
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.
Claus Aßmann
> Ich kann mich dunkel daran erinnern, dass Wietse mal daran gezweifelt
> hat, dass Sendmail Queuehandling "safe" ist. D.h. es wuerde alles
> async schreiben, und waere daher so schnell...
FUD?
Ich glaube nicht, dass Wietse so etwas geschrieben hat.
Er verbreitet selten Unwahrheiten.
1. sendmail's queue handling ist per Default sicher.
Siehe queueup() in queue.c: fsync() nach dem Schreiben und fsync()
nach rename() fuer Softupdates.
2. sendmail <= 8.11 ist nicht schnell.
3. 8.12 kann sogar sicher mit ReiserFS u.ae. umgehen... (fsync()
fuer das Queue-Directory).
Ralf Hildebrandt
> FUD?
Nee, ich weiss es echt nicht mehr. Ich muesste jetzt im Archiv graben :|
Gerrit Pape
> Gerrit Pape <pa...@innominate.com> writes:
>> Ich denke, "nach 'heutigem Anforderungsprofil' nicht betreibbar" ist
>> unmissverstaendlich. qmail-1.03 + ezmlm wird heutzutage eingesetzt.
> ...sprach's und ließ alle übrigen Kriterien außer acht. Sendmail +
> majordomo werden auch eingesetzt. Eine Qualitätsauszeichnung ist das
> sicher nicht.
ok. Danke, dass du deine Behauptung in <m3hev2k...@emma1.emma.line.org>
zuruecknimmst, qmail-1.03 sei nicht mehr betreibbar.
>> Du hast den Kommentar zum Rueckzug meiner Behauptung nicht verstanden:
>> "Meine Aussage war so nichtssagend, dass man sie garnicht belegen
>> kann."
>> Genauso wenig kann man sie widerlegen, ein Gegenbeispiel ist nichtig.
> Nein, es ist real existent und belegt, daß qmails Queue-Handling bei "5
> Leute schieben 1000 1-to-1-mailings rein" PerformanceNACHTEILE gegenüber
> anderen etablierten Verfahren hat.
>> Genauso wenig kann man sie als 'bogus claim' bezeichnen.
Zitiere nochmal meine Worte, die Du in postfi...@postfix.org
(http://groups.yahoo.com/group/postfix-users/message/40628?threaded=1) als
'bogus claims' bezeichnet hast, ohne relvante Textpassagen aus diesem
Posting zu kuerzen.
>> Dem widersprechen Deine Aussagen, qmail-1.03 haette bugs, sei heute nicht
>> mehr betreibbar und "Since Gerrit Pape made bogus claims about qmail
>> performance".
> Hat jemand anders als Gerrit Pape diese Behauptungen aufgestellt?
> Waren sie nicht öffentlich?
> Ist qmail nicht ohne VERP ein Bandbreitenschwein allererster Güte?
> Ist nicht deutlich genug geworden, daß qmail deutlich langsamer als
> mindestens ein anderer, gängiger, MTA ist?
Uff, keine dieser Behauptungen, die hier aufgefuehrt sind, habe ich
aufgestellt.
Matthias Andree
> 3. 8.12 kann sogar sicher mit ReiserFS u.ae. umgehen... (fsync()
> fuer das Queue-Directory).
Das braucht nur ReiserFS 3.5, nicht 3.6. ReiserFS 3.6 wird benutzt wie
Softupdates, i. e. fsync() wirft z. B. auch ein vorangegangenes rename
auf die Platte.
Ich denke, in dem Kontext ist es viel wichtiger, daß die Platten ihre
Schreibcaches abgeschaltet bekommen, sonst kann man das ganze Geraffel
mit fsync() auf Dateisystem vergessen.
Für Linux zum Beispiel für die erste Platte am Interface:
IDE: Beim Booten: hdparm -W0 /dev/hda
SCSI: scsi-config /dev/sda, cache control page anklicken.
FreeBSD 4.x:
IDE: sysctl -w hw.ata.wc=0
SCSI: camcontrol sd0 modepage -m 8 -e -P 3
Dann WCE: auf 0 ändern, Editor speichern und verlassen
Alternativ können natürlich die Tools des Festplattenherstellers benutzt
werden, sofern der Festplattenadapter Treiber hat (das ist bei IBM-Tools
z. B. NICHT der Fall für Promise-Adapter).
--
Matthias Andree
begin dont_click_this_virus.exe
end
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
Matthias Andree
> : Ich habe in meinem Benchmark[1] inzwischen das "verbotene" (weil
> : unsichere) qmail+softupdates, exim 3.33 und sendmail 8.11.3 ebenfalls
> : nachgetragen. In Defaultkonfiguration laufen alle schneller als qmail -
> : Postfix 11,5 Mails/s, Exim 8,8 Mails/s, Sendmail 6,2 Mails/s, qmail
> : würde mit softupdates ca. 5 Mails/s durchschieben, darf es aber nicht,
> : weil unsicher, und ohne Softupdates schafft's 3,2 Mails/s. Man muß hier
> : zugestehen, daß nicht alle MTA derart exzessives Queue-Handling wie
> : qmail betreiben und insbesondere Sendmail und Exim synchron zuzustellen
> : scheinen, und der Rechner nie so belastet war, daß man von Parallelität
> : in Postfix oder qmail hätte profitieren können.
>
> sendmail startet per Default einen neuen Prozess um Mail zu verschicken
> (Background mode). Siehe DeliveryMode in doc/op/op.*.
Sieht in /etc/mail/sendmail.cf so aus, ja:
O DeliveryMode=background
> Wenn Du das auf 'i' setzt bekommst Du hoechstwahrscheinlich ca. 40%
> bessere Werte. Wenn Du 8.12 benutzt, wird es nochmals schneller...
Glaub' ich gerne, das Ziel war jedoch, einen Releaseversion des MTA aus
der Kiste und _ohne Tuning_ zu vermessen. Das deshalb, weil ich
z. B. Exim nicht tunen kann, weil ich's nicht kenne.
Wenn ich /var von RAM-Disk mounte, dürften alle MTA den Zielrechner bis
zum Anschlag fahren, aber dann hab' ich die praktisch relevante
Queue-Latenzzeit, die ich eigentlich messen wollte, vom Test
ausgeschlossen.
> Ich bekomme auf einem PC mit 450MHz AMD K6 und IDE Disks
> 16 - 25 msg/s mit sendmail 8.12, je nach Konfiguration.
Mag schon sein, es haben mir mehrere Leute gesagt "Deine Zahlen sind
sehr niedrig". Die Platte ist, wie dort beschrieben, eine alte
Micropolis 4345WS, die ist nicht der Ausbund an Geschwindigkeit, aber
sie ist nunmal in meinem K6-2, und für SuSE-Linux (Duron mit IBM DTLA
und DJNA) ist die qmail- oder Exim-Installation nunmal viel aufwendiger
als für FreeBSD :-)
--
Matthias Andree
begin dont_click_this_virus.exe
end
Matthias Andree
> > ...sprach's und ließ alle übrigen Kriterien außer acht. Sendmail +
> > majordomo werden auch eingesetzt. Eine Qualitätsauszeichnung ist das
> > sicher nicht.
>
> ok. Danke, dass du deine Behauptung in <m3hev2k...@emma1.emma.line.org>
> zuruecknimmst, qmail-1.03 sei nicht mehr betreibbar.
Woraus schließt Du das? Daß ich feststelle, daß es eingesetzt wird?
Outlook Express wird auch eingesetzt, und ist nicht betreibbar, siehe
die ILOVEYOU-Signature-FAQ von Boris Piwinger, die hat eine Bugliste.
qmail ist der MTA mit der ineffizientesten Queue-Handhabung, mit dem
ineffizientesten Bandbreiteneinsatz (den Platz wird wohl Sendmail holen,
wenn's PIPELINING beherrscht) und mit den wenigsten Features, und zählt
zu denjenigen mit der aufwendigsten Installation. Es beherrscht keine
RFC-1894-konformen Bounces. Es lehnt Mail für unbekannte lokale Benutzer
nicht ab, sondern nimmt sie an und bounct sie. Es ist nicht
sendmail-kompatibel (sendmail -D geht baden zum Beispiel).
Warum sollte man so etwas weiterbetreiben und vor allem neu einrichten
wollen?
> > Nein, es ist real existent und belegt, daß qmails Queue-Handling bei "5
> > Leute schieben 1000 1-to-1-mailings rein" PerformanceNACHTEILE gegenüber
> > anderen etablierten Verfahren hat.
>
> >> Genauso wenig kann man sie als 'bogus claim' bezeichnen.
>
> Zitiere nochmal meine Worte, die Du in postfi...@postfix.org
> (http://groups.yahoo.com/group/postfix-users/message/40628?threaded=1) als
> 'bogus claims' bezeichnet hast, ohne relvante Textpassagen aus diesem
> Posting zu kuerzen.
| Message-ID: <9lrqeb$1fnl$1...@wrath.news.nacamar.de>
| From: Marc Haber <mh+use...@zugschlus.de>
| Date: Mon, 20 Aug 2001 22:03:23 +0200
| [...]
| Es ist ein qmail-1.03 aber mit heutigem Anforderungsprofil nicht
| betreibbar, und was djb zu einem auf heutige Anwendung gepatchten
| qmail sagt, hat er gerade heute morgen auf bugtraq erneut
| eindrucksvoll bewiesen.
|
| Er soll zurück in den Elfenbeinturm gehen. [...]
und
| Message-ID: <9m092i$viv$1...@mate.bln.innominate.de>
| From: Gerrit Pape <pa...@innominate.com>
| Date: 22 Aug 2001 12:37:38 GMT
| [...]
| Matthias Andree <matthia...@gmx.de> wrote:
| [...]
| > qmail ist nur einsetzbar, wenn man nicht nach Volumen bezahlt und eine
| > wirklich heftig böse schnelle Festplatte hat, bevorzugt 15.000/min,
| > sonst bricht es sich an seinen vielen synchronen Schreibzugriffen das
| > Genick.
| [...]
| Dein 'Festplatten'-Argument ist haltlos. Hardware muss den Anforderungen
> angepasst werden. Niemand bricht sich das Genick. qmail's queue handling
> bringt meist Performance Vorteile. Belege Deine Behauptungen oder behalte
| Sie fuer Dich. [...]
> >> Dem widersprechen Deine Aussagen, qmail-1.03 haette bugs, sei heute nicht
> >> mehr betreibbar und "Since Gerrit Pape made bogus claims about qmail
> >> performance".
>
> > Hat jemand anders als Gerrit Pape diese Behauptungen aufgestellt?
> > Waren sie nicht öffentlich?
> > Ist qmail nicht ohne VERP ein Bandbreitenschwein allererster Güte?
> > Ist nicht deutlich genug geworden, daß qmail deutlich langsamer als
> > mindestens ein anderer, gängiger, MTA ist?
>
> Uff, keine dieser Behauptungen, die hier aufgefuehrt sind, habe ich
> aufgestellt.
Durchaus nicht, Du hast aber auch die Mühe der Beantwortung der Fragen
gescheut. Du hast nach einem Beleg für das Festplatten-Argument gefragt
und einen bekommen, der hat Dir nicht gefallen.
Ich verstehe ja, daß es bitter ist, wenn der Lieblings-MTA derart
demontiert wird, aber für denjenigen, der hier unbedarft fragt, ist
qmail wirklich keine gute Empfehlung mehr, weil es bezüglich der drei
anderen großen MTA doch in ziemlich jeder Disziplin abfällt, und einzig
das "keine Release-Version hat CERT-Anncouncements gesehen"-Argument
steht. Das teilt qmail aber mit Postfix und Exim, nur sendmail fällt da
unangenehm auf, wobei man ihm zugute halten muß, daß in 8.11 bisher
keine remote exploits bekannt sind.
--
Matthias Andree
begin dont_click_this_virus.exe
end
Claus Aßmann
> qmail ist der MTA mit der ineffizientesten Queue-Handhabung, mit dem
> ineffizientesten Bandbreiteneinsatz (den Platz wird wohl Sendmail holen,
> wenn's PIPELINING beherrscht) und mit den wenigsten Features, und zählt
Was meinst Du damit: "ineffizientesten Bandbreiteneinsatz
(den Platz wird wohl Sendmail holen, wenn's PIPELINING beherrscht)"
?
8.12 kann PIPELINING. Das aendert nichts am MX-Piggybacking
(was in 8.12 nochmals verbessert wurde) oder am Verwenden
von mehreren RCPTs per Transaktion.
Claus Aßmann
> Claus Aßmann
> > 3. 8.12 kann sogar sicher mit ReiserFS u.ae. umgehen... (fsync()
> > fuer das Queue-Directory).
> Das braucht nur ReiserFS 3.5, nicht 3.6. ReiserFS 3.6 wird benutzt wie
> Softupdates, i. e. fsync() wirft z. B. auch ein vorangegangenes rename
> auf die Platte.
Welche Version ist in den aktuellen Linux-Distributionen?
Unsere Beta-Tester haben uns gesagt man muesste fsync(directory)
verwenden und das war auch die letzte Auskunft von Hans R.
Wir haben zwar versucht ihn zu ueberzeugen das zu aendern,
aber "damals" (vor einigen Wochen) meinte er nur dass alle es
so machen sollten wie er...
Hast Du zufaellig eine URL wo diese Aenderung dokumentiert ist?
Danke!
Matthias Andree
> 8.12 kann PIPELINING. Das aendert nichts am MX-Piggybacking
> (was in 8.12 nochmals verbessert wurde) oder am Verwenden
> von mehreren RCPTs per Transaktion.
Ja, http://www.sendmail.org/ redet aber von 8.12.0beta9. Mind the
"beta". Ich rede von 8.12, sobald's eine Release gibt, aber laßt Euch
davon nicht drängen ;-)
Matthias Andree
<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
> Matthias Andree wrote:
> > Claus Aßmann
>
> > > 3. 8.12 kann sogar sicher mit ReiserFS u.ae. umgehen... (fsync()
> > > fuer das Queue-Directory).
>
> > Das braucht nur ReiserFS 3.5, nicht 3.6. ReiserFS 3.6 wird benutzt wie
> > Softupdates, i. e. fsync() wirft z. B. auch ein vorangegangenes rename
> > auf die Platte.
>
> Welche Version ist in den aktuellen Linux-Distributionen?
Kernel 2.2 hat ReiserFS 3.5
Kernel 2.4 hat ReiserFS 3.6, das auch ReiserFS-3.5-Format mounted. Man
kann's auf 3.6-Format aufbohren und hat dann large file support, kann es
aber nicht mehr mit 2.2 (ReiserFS 3.5) mounten.
Welche Distribution welchen Kernel hat, mußt Du selbst ausgraben. SuSE
7.0 hat 2.2, 7.1 bietet beide an, bei 7.2 und den übrigen Distributionen
weiß ich's nicht, juckt mich auch nicht.
> Unsere Beta-Tester haben uns gesagt man muesste fsync(directory)
> verwenden und das war auch die letzte Auskunft von Hans R.
Für ReiserFS 3.5 ist Euer Weg der richtige, inoffiziell wird's nicht
gebraucht, offiziell noch (s. URL unten).
Für ext2 muß man das sowieso machen, wenn man nicht für
/var/spool/mqueue chattr +S setzen will.
Bei aktuellen ext3 in Linux 2.4 (0.9.5+) ist's über, weil bei denen
fsync() das komplette Filesystem synct. Hört sich übel an, relativiert
sich bei "mount -t ext3 -o data=journal /dev/bla /blubb" aber ganz
schnell, weil fsync() nur ins journal schreibt - das ist lineares
Schreiben, praktisch also 10 ms warten und >= 20 MB/s wegschreiben.
Es schadet sicher nicht, wenn fsync() auf die noch offene Datei
(Softupdates) das Verzeichnis schon rausgeschrieben hat, wenn fsync()
aufs Directory kommt, tut der neuerliche fsync() halt einfach
nichts. Bis auf den syscall-overhead und das Nachsehen, ob dirty blocks
ausstehen, ist das geschenkt.
Ich frag' mich eher, wieviel fsync(directory) bei anderen OS kostet,
z. B. *BSD.
> Hast Du zufaellig eine URL wo diese Aenderung dokumentiert ist?
Ob da eine Änderung zugrunde liegt, weiß ich nicht, meine Auskunft
beruht auf http://marc.theaimsgroup.com/?l=reiserfs&m=99703452321440&w=2
HTH,
Claus Aßmann
> Claus Aßmann
> > 8.12 kann PIPELINING. Das aendert nichts am MX-Piggybacking
> > (was in 8.12 nochmals verbessert wurde) oder am Verwenden
> > von mehreren RCPTs per Transaktion.
> Ja, http://www.sendmail.org/ redet aber von 8.12.0beta9. Mind the
> "beta". Ich rede von 8.12, sobald's eine Release gibt, aber laßt Euch
> davon nicht drängen ;-)
Du redest doch auch von postfix snapshots :-)
BTW: Es ist Beta19.
BTW2: es draengeln schon genuegend Leute, deshalb aendere ich
meine Releasekriterien aber trotzem nicht...
Aber egal, meine eigentliche Frage hast Du leider weggelassen:
! Matthias Andree wrote:
! > qmail ist der MTA mit der ineffizientesten Queue-Handhabung, mit dem
! > ineffizientesten Bandbreiteneinsatz (den Platz wird wohl Sendmail holen,
! > wenn's PIPELINING beherrscht) und mit den wenigsten Features, und zählt
! Was meinst Du damit: "ineffizientesten Bandbreiteneinsatz
! (den Platz wird wohl Sendmail holen, wenn's PIPELINING beherrscht)"
! ?
Willst Du damit irgendwie sagen, dass sendmail Bandbreite verschwendet
wenn es PIPELING kann? Wieso?
Matthias Andree
> Du redest doch auch von postfix snapshots :-)
Das ist wahr, die queuen aber nicht anders als die Release.
> BTW: Es ist Beta19.
Meinethalben :-)
> BTW2: es draengeln schon genuegend Leute, deshalb aendere ich
> meine Releasekriterien aber trotzem nicht...
Vernünftig.
> Aber egal, meine eigentliche Frage hast Du leider weggelassen:
>
> ! Matthias Andree wrote:
>
> ! > qmail ist der MTA mit der ineffizientesten Queue-Handhabung, mit dem
> ! > ineffizientesten Bandbreiteneinsatz (den Platz wird wohl Sendmail holen,
> ! > wenn's PIPELINING beherrscht) und mit den wenigsten Features, und zählt
>
> ! Was meinst Du damit: "ineffizientesten Bandbreiteneinsatz
> ! (den Platz wird wohl Sendmail holen, wenn's PIPELINING beherrscht)"
> ! ?
>
> Willst Du damit irgendwie sagen, dass sendmail Bandbreite verschwendet
> wenn es PIPELING kann? Wieso?
Blödsinn hab' ich da geschrieben. Da fehlt ein "NICHT" oder
"entgegengesetzten", oder "des effizientesten Bandbreiteneinsatzes".
Wenn Sendmail PIPELINING kann, wird es im Gegenteil Bandbreite sparen,
und da es sowieso schon connection caching macht, wird es wohl zu den
MTAs gehören, die den geringsten Overhead im Netzwerk erzeugen
(Paketzahl zum Beispiel).
Die Idee bei PIPELINING ist doch, den kompletten Envelope für mehrere
Empfänger in möglichst wenige (1) Pakete zu kleben und zu verschicken,
damit Overhead und RTT-Latenzen zu sparen.
qmail kopiert doch Mails wie blöde, selbst, wenn Du 100 Empfänger in
derselben Domain und auf demselben MX hast, gibt's nur einen RCPT, da
kann man sich PIPELINING auch sparen ;-)
--
Matthias Andree
Matthias Andree
> qmail IST NICHT schnell. Es ist vielleicht schneller als
> Sendmail-8.8.x "aus der Kiste", das aktuell war, als qmail-1.0x
> herauskam.
Ich hab' noch einen Benchmark,
<URL:http://mandree.home.pages.de/postfix/bench2.html> - eine
Randbeobachtung dabei war, daß qmail durch preprocessing erheblich Zeit
verliert, und qmail insgesamt derjenige MTA ist, der für dieselbe
Aufgabe mit Abstand am meisten Schreiboperationen veranlaßt.
Exim zeigt an einigen Stellen eigenwilliges Verhalten, so werden die
11. und folgende Mail derselben SMTP-Verbindung nur noch gequeuet, und
Exim kommt im Gegensatz zu anderen Mailern überhaupt nicht mit einer
größeren Anzahl von Clients klar.
So schade es ist, die Luft um qmail ist dünn geworden in den letzten
Jahren.
Ralf Hildebrandt
> Ich hab' noch einen Benchmark,
><URL:http://mandree.home.pages.de/postfix/bench2.html> - eine
> Randbeobachtung dabei war, daß qmail durch preprocessing erheblich Zeit
> verliert, und qmail insgesamt derjenige MTA ist, der für dieselbe
> Aufgabe mit Abstand am meisten Schreiboperationen veranlaßt.
So, und jetzt muss mir bloss noch mal einer den genauen Unterschied
zwischen qmgr und nqmgr erklaeren. Scheinbar macht nqmgr keinen
Unterscheid, bei keinem der Benchmarks.
Thomas Hochstein
> Exim zeigt an einigen Stellen eigenwilliges Verhalten, so werden die
> 11. und folgende Mail derselben SMTP-Verbindung nur noch gequeuet, [...]
Konfigurationssache:
http://www.exim.org/exim-html-3.30/doc/html/spec_11.html#SEC366
-thh
--
Ich habe fast die Befürchtung, daß wir zu anspruchsvoll sind.
(Dieter Bohlen über "Modern Talking")
Matthias Andree
> So, und jetzt muss mir bloss noch mal einer den genauen Unterschied
> zwischen qmgr und nqmgr erklaeren. Scheinbar macht nqmgr keinen
> Unterscheid, bei keinem der Benchmarks.
Kein Wunder, die Zustellung um LAN schlägt während des Tests niemals
fehl, und es ist praktisch egal, in welcher Reihenfolge Mails an smtp
übergeben werden, da alle Slots, die diverse Daemons haben, gleichrangig
sind. Wenn Du allerdings ins Netz zustellst und Strato z. B. wieder
toter Mann spielt, kann es einen Unterschied machen. Mangels Masse
(Mailinglisten) kann ich das aber nicht testen.
Matthias Andree
> begin quoting [matthia...@gmx.de]
>
> > Exim zeigt an einigen Stellen eigenwilliges Verhalten, so werden die
> > 11. und folgende Mail derselben SMTP-Verbindung nur noch gequeuet, [...]
>
> Konfigurationssache:
> http://www.exim.org/exim-html-3.30/doc/html/spec_11.html#SEC366
Vielen Dank für den Hinweis, den werde ich aber nicht nehmen, um den
Test zu wiederholen, denn Exim macht, wenn's aus der Büchse ausgepackt
ist, solchen Mist.
ZMailer hab' ich hier nicht an den Start bekommen, daher fehlt der im
Test.
Ich tune den MTA nicht, ich laß' ihn nur per syslog loggen und stelle
passenden Kernel und Filesysteme und ggf. Daemon per Konfiguration (QMQP
in Postfix, SMTP für qmail), alles andere ist Problem des MTA.
Sonst könnte ich nämlich auch z. B. Ident-Lookups in tcpserver oder
sendmail unterdrücken o. ä. Das zählt aber nicht für meinen Test, denn
der MTA-Maintainer hat absichtlich derartiges Verhalten eingeführt, und
das soll sich im Benchmark auch niederschlagen.
Thomas Hochstein
> Vielen Dank für den Hinweis, den werde ich aber nicht nehmen, um den
> Test zu wiederholen, denn Exim macht, wenn's aus der Büchse ausgepackt
> ist, solchen Mist.
Yep. Die Konfiguration ist AFAIS generell eher "vorsichtig", d.h. mit
niedrigen Limits, für die bei "großen" Maschinen durchaus "abstellen"
oder "um Faktor 10ß raufsetzen" empfohlen wird.
-thh
--
Wenn Du von einem Thema keine Ahnung hast, darfst Du auch schweigen.
(Bernd Kaufmann, de.alt.soc.tierrechte, 19.8.1999)
Matthias Andree
> begin quoting [matthia...@gmx.de]
>
> > Vielen Dank für den Hinweis, den werde ich aber nicht nehmen, um den
> > Test zu wiederholen, denn Exim macht, wenn's aus der Büchse ausgepackt
> > ist, solchen Mist.
>
> Yep. Die Konfiguration ist AFAIS generell eher "vorsichtig", d.h. mit
> niedrigen Limits, für die bei "großen" Maschinen durchaus "abstellen"
> oder "um Faktor 10ß raufsetzen" empfohlen wird.
Naja, es steht ja dokumentiert, warum dieses Verhalten da ist, und da
exim und sendmail - beides Monolithen - auch durchaus sofort zustellen,
ist es in dem Fall auch geeignet, das Problem zu beschränken. Im Test
hätte ich den Parameter auf 0 setzen können, allerdings find' ich's auf
die Weise, die Queue manuell aufzutauen, angemessen, denn praktisch
würde so etwas auch passieren.
Ich habe nur den Eindruck, daß dieses Verhalten (forken und sofort
ausliefern) sehr ineffizient ist, ob der Initialisierungsoverhead da
hineinspielt, kann ich nach gegenwärtigem Wissensstand nicht beurteilen,
das können Leute, die mehr Ahnung von Sendmail oder Exim haben, sicher
besser.
Ich mußte z. B: für meinen zweiten Benchmark Sendmail beibringen, nicht
bei einer Load von 12 bzw. 18 seinen Dienst einzustellen.
Beide Mailer scheinen mit Bursts nicht gut klarzukommen, wie man auch an
der Akzeptanz eingehender Mail sieht, Exim geht bei 20 Clients
fürchterlich in die Knie, verglichen mit 5 Clients.
qmail zeigte im Test, daß es Mail zwar noch relativ gut annehmen kann
und vor allem dabei noch halbwegs skaliert (anders als Exim), die Zeit,
die es braucht, die Mail loszuwerden, ist jedoch nahezu konstant, qmail
ist da sehr mit I/O beschäftigt.
Flaschenhals scheint grundsätzlich die umständliche Vorverarbeitung der
Mail zu sein. Wenn man dann noch bedenkt, daß im praktischen Einsatz
sog. fixup-queues zum Einsatz kommen (müssen), die alle ausgehende Mail
an qmail-inject zustellt, weil qmail-smtpd bzw. qmail-qmqpd die Adressen
nicht qualifizieren, kann man davon ausgehen, daß der Durchsatz von
qmail nochmal auf gut die Hälfte sinkt, und Exim bzw. Sendmail schon
ohne Tuning vier- bis fünfmal so schnell wie qmail sind, Postfix rund
zehnmal so schnell.