qmail vs postfix
Daniel Wollschlaeger
und postfix hinsichtlich ihrer Sicherheit, sowohl konzeptuell als auch in
bezug auf die Implementation. Insbesondere interessiert mich, welche
Gründe es dafür geben könnte, eine funktionierende Installation der
letzten stabilen postfix Version gegen eine qmail Lösung auszutauschen
(und umgekehrt). Die Frage beinhaltet, daß ich leider nicht selbst dazu
in der Lage bin, mir anhand des Quellcodes ein eigenes Bild zu schaffen.
In dieser NG scheint insbesondere die Meinung zu postfix geteilt zu sein,
zumindest wurden zu dessen Sicherheit nebenbei unterschiedliche Ansichten
geäußert.
Was ich bei einer Suche im www zum Thema gefunden habe, fiel in eine
dieser drei Kategorien: 1) Hauptsache kein sendmail, qmail und postfix
sind beide sicherer. 2) Bernsteins Seiten und postings, die sich negativ
über Postfix und Venema äußern, wobei sich der sachbezogene Anteil auf ein
Problem zu beziehen schien, daß zeitlich zurück liegt. 3) Venemas
postings, die versuchen, qmail schlecht dastehen zu lassen (DoS).
Insgesamt fiel es da schwer, persönliche Feindschaft und sachliche
Argumentation voneinander zu trennen.
Danke! Daniel
Robin S. Socha
[...]
> Was ich bei einer Suche im www zum Thema gefunden habe, fiel in eine
> dieser drei Kategorien: 1) Hauptsache kein sendmail, qmail und postfix
> sind beide sicherer.
http://groups.google.com/groups?oi=djq&selm=an_432082346
http://cr.yp.to/qmail/guarantee.html
http://www.whitefang.com/sup/secure-faq.html
> 2) Bernsteins Seiten und postings, die sich negativ über Postfix und
> Venema äußern, wobei sich der sachbezogene Anteil auf ein Problem
> zu beziehen schien, daß zeitlich zurück liegt.
Meister Hildebrandt hat postfix sehr nett (aber selbstverständlich komplett
irreführend, weil postfix schon deswegen stinkt, weil sein Autor Holländer
ist[1]) hier beschrieben: http://innominate.org/~hildeb/postfix/postfix.pdf
DJB's Einstellung zu Venema ist bekannt (und IMO nicht wirklich weltfremd).
> 3) Venemas postings, die versuchen, qmail schlecht dastehen zu
> lassen (DoS).
Wietse Z. "tcpwrappers" Venema vs. Daniel J. "ucspi-tcp" Bernstein
- was erwartest Du?
> Insgesamt fiel es da schwer, persönliche Feindschaft und sachliche
> Argumentation voneinander zu trennen.
Das ist relativ einfach, wenn Du Dich an den Fakten orientierst. Venema
ist Holländer und Postfix hat zu viele Buchstaben. DJB tritt Theo in den
Arsch und qmail hat eine Mailingliste direkt aus der Hölle - eindeutige
Zeichen dafür, dass sich das Programm perfekt für den Einsatz in einem
professionellen Umfeld eignet.
Footnotes:
[1] Ja, ich bin Düsseldorfer. Ja, ich hasse Wohnwagen.
Robin S. Socha
>* Daniel Wollschlaeger <dw...@psychologie.uni-kiel.de> schrieb:
[fup2 de.comm.software.mailserver - das hat mit security nichts zu tun]
[...]
>> 3) Venemas postings, die versuchen, qmail schlecht dastehen zu
>> lassen (DoS).
> Nun, qmail ist eine Bandbreitensau,
Und der in der Postmasterei dilettierende Psychologe Daniel Wollschläger
ein Breitmaulschwätzer:
,----[ http://www.lifewithqmail.org/lwq.html#multi-rcpt ]
| Single RCPT delivery does use more bandwidth than multiple RCPT
| delivery, but the difference is often exaggerated. Most messages have,
| at most, a couple recipients, and they're usually on separate hosts, so
| multi-RCPT delivery buys them nothing. Even on a list server, where
| multi-RCPT delivery could help, the potential gains are small because
| SMTP uses only a fraction of the bandwidth over most links--HTTP usually
| gets the lion's share.
`----
Der behauptete trade-off in Bandbreite wird durch VERP mehr als
wettgemacht (und nicht nur dadurch).
> ist eigenwillig zu konfigurieren,
Ach Gott, ach Gott...
09:52:37]-[Thu Dec 6]-[~]
[robin@mail1] ls -l /var/qmail/control/*[!lock] | wc -l
12
Von den 12 bestehen 7 aus einer Zeile, 3 sind killfiles.
> ist seit 3,5 Jahren nicht mehr aktualisiert worden,
Hat sich in den 3,5 Jahren etwas getan, das ich verpaßt hättte? SMTPAUTH
wäre nett, aber sonst?
> benutzt proprietäre "extended message format[s]",
Huh?
> verwendet eigene Standards für Bounces (QSBMF)...
http://cr.yp.to/proto/qsbmf.txt - zund?
> Qmail ist wahrlich kein schlechter MTA. Bei Neuinstallationen würde
> ich aber zu Postfix greifen. Die Konfiguration ist angenehmer zu
> pflegen,
Sicher.
> es gibt bessere Debugmöglichkeiten,
Wozu will ich einen MTA debuggen? Das Ding schreibt logs, die lese ich
und dann ist gut.
> chroot ist trivial einzurichten,
Wozu brauche ich chroot?
> Bandbreiten werden effizient genutzt,
Du liest das da boen noch einmal, überlegst Dir dann, wann Du dieselbe
Nachricht an verschiedene Adressen verschickst und anschließend fragst
Du Dich dann ehrlich, ob Du lieber Majordomo oder ezmlm-idx willst.
> nützliche Features sind bereits eingebaut etc. pp.
Features, die nicht existieren, können keine Fehler haben.
> Naja, vielfach ist die Wahl des MTA' Geschmackssache.
Ja. Und Postfix ist kein schlechter Geschmack - aber Deine Argumente
sind schlecht. http://cr.yp.to/qmail/faq/orientation.html#reasons hat
ein paar gute für qmail.
Robin S. Socha
>* Daniel Wollschlaeger <dw...@psychologie.uni-kiel.de> schrieb:
[fup2 de.comm.software.mailserver - das hat mit security nichts zu tun]
[...]
>> 3) Venemas postings, die versuchen, qmail schlecht dastehen zu
>> lassen (DoS).
> Nun, qmail ist eine Bandbreitensau,
Und der in der Postmasterei dilettierende Heiko Schlenker ein
Breitmaulschwätzer:
,----[ http://www.lifewithqmail.org/lwq.html#multi-rcpt ]
| Single RCPT delivery does use more bandwidth than multiple RCPT
| delivery, but the difference is often exaggerated. Most messages have,
| at most, a couple recipients, and they're usually on separate hosts, so
| multi-RCPT delivery buys them nothing. Even on a list server, where
| multi-RCPT delivery could help, the potential gains are small because
| SMTP uses only a fraction of the bandwidth over most links--HTTP usually
| gets the lion's share.
`----
Der behauptete trade-off in Bandbreite wird durch VERP mehr als
wettgemacht (und nicht nur dadurch).
> ist eigenwillig zu konfigurieren,
Ach Gott, ach Gott...
09:52:37]-[Thu Dec 6]-[~]
[robin@mail1] ls -l /var/qmail/control/*[!lock] | wc -l
12
Von den 12 bestehen 7 aus einer Zeile, 3 sind killfiles.
> ist seit 3,5 Jahren nicht mehr aktualisiert worden,
Hat sich in den 3,5 Jahren etwas getan, das ich verpaßt hättte? SMTPAUTH
wäre nett, aber sonst?
> benutzt proprietäre "extended message format[s]",
Huh?
> verwendet eigene Standards für Bounces (QSBMF)...
http://cr.yp.to/proto/qsbmf.txt - und?
> Qmail ist wahrlich kein schlechter MTA. Bei Neuinstallationen würde
> ich aber zu Postfix greifen. Die Konfiguration ist angenehmer zu
> pflegen,
Sicher.
> es gibt bessere Debugmöglichkeiten,
Wozu will ich einen MTA debuggen? Das Ding schreibt logs, die lese ich
und dann ist gut.
> chroot ist trivial einzurichten,
Wozu brauche ich chroot?
> Bandbreiten werden effizient genutzt,
Du liest das da oben noch einmal, überlegst Dir dann, wann Du dieselbe
Felix von Leitner
> Hi, ich suche eine Darstellung der jeweiligen Vor- und Nachteile von qmail
> und postfix hinsichtlich ihrer Sicherheit, sowohl konzeptuell als auch in
> bezug auf die Implementation.
Vom Konzept her sind qmail und postfix ähnlich.
Von der Implementation her ist qmail vorbildlich und postfix stinkt.
> Insbesondere interessiert mich, welche Gründe es dafür geben könnte,
> eine funktionierende Installation der letzten stabilen postfix Version
> gegen eine qmail Lösung auszutauschen (und umgekehrt). Die Frage
> beinhaltet, daß ich leider nicht selbst dazu in der Lage bin, mir
> anhand des Quellcodes ein eigenes Bild zu schaffen.
Wenn das ein Spielserver ist, dann tauscht man das zum Lernen um.
Wenn das ein Produktivserver ist, dann tauscht man ohne guten Grund gar
nichts um.
> In dieser NG scheint insbesondere die Meinung zu postfix geteilt zu
> sein, zumindest wurden zu dessen Sicherheit nebenbei unterschiedliche
> Ansichten geäußert.
Postfix ist bei vergleichbarer Funktionalität mehr als drei mal so groß
wie qmail. Bei Sicherheitsfragen achtet man auf die Quellcode-Größe,
denn die Anzahl der Bugs ist erfahrungsgemäß proportional zur
Code-Große.
Postfix hat zusätzlich eine Tonne von überflüssiger
Spielkram-Funktionalität, die man bei qmail im Bedarfsfall über externe
Programme realisieren kann. Gleiches Argument: Nicht vorhandener Code
hat keine Sicherheitsprobleme.
> Was ich bei einer Suche im www zum Thema gefunden habe, fiel in eine
> dieser drei Kategorien: 1) Hauptsache kein sendmail, qmail und postfix
> sind beide sicherer. 2) Bernsteins Seiten und postings, die sich negativ
> über Postfix und Venema äußern, wobei sich der sachbezogene Anteil auf ein
> Problem zu beziehen schien, daß zeitlich zurück liegt. 3) Venemas
> postings, die versuchen, qmail schlecht dastehen zu lassen (DoS).
> Insgesamt fiel es da schwer, persönliche Feindschaft und sachliche
> Argumentation voneinander zu trennen.
Zusammenfassend hat sich Wietse mehr als lächerlich gemacht, während
Bernstein ihn in aller Ruhe ausgelacht hat. Das hat Wietse ihm auch
nach Jahren noch nicht verziehen und benimmt sich wie ein Kleinkind.
Das "DoS-Problem", das Wietse da konstruiert hatte, ist a) dokumentiert,
b) trivial vermeidbar, und c) so gewollt, damit der Admin das einstellen
kann, wie er möchte. Besonders pikant ist, daß postfix jetzt praktisch
das gleiche "Problem" auch hatte. Damit hat Wietse Bernsteins
Argumentation eindrucksvoll bestätigt, daß es konzeptionell Unsinn ist,
an hundert Stellen einzelne Checks einzubauen, wenn man Resource
Limits auch global erledigen kann.
Aber das ist Firlefanz. qmail und postfix sind per Default viel
sicherer als andere Lösungen. Wenn du die Wahl hast oder Purist bist,
nimm qmail. Wenn nicht, ist es auch nicht schlimm.
Felix
Felix von Leitner
> Falls Du in qmail Patches aus dritter Hand einspielst, weil Du
> bestimmte Features wie SMTP-Auth o.ä. benötigst, kann es mit der
> Sicherheit Essig sein.
SMTP-Auth ist ja auch totaler Bullshit. Wer roaming users hat, braucht
ein VPN und im Übrigen gibt es genau keinen Grund, wieso Clients ihre
Mail nicht selber zustellen sollten, anstatt Bandbreite zu verschwenden,
indem sie zu ihrem ISP am anderen Ende der Welt connecten, der das dann
am besten wieder zurück über den großen Teich pumpt.
> > 3) Venemas postings, die versuchen, qmail schlecht dastehen zu
> > lassen (DoS).
> Nun, qmail ist eine Bandbreitensau,
Ach jaaaa, schon wieder dieses lächerliche Schwachsinnsargument.
So ein Bullshit. In meiner persönlichen Mailstatistik haben deutlich
unter einem Promille der nicht-lokalen Emails mehr als einen Recipient
bei der gleichen Ziel-Domain.
Es gibt genau eine Art von Anwender, für die das anders aussieht:
Spammer. Richtig, für die ist qmail nicht zu empfehlen. Mein Herz
blutet.
> ist eigenwillig zu konfigurieren,
Klar, lieber ein nicht atomar von einem Shell Script aus updatebare
große Textdatei und keine saubere Methode zur Fernsteuerung. Man sieht,
daß deine Admin-Erfahrung nicht mehr als 10 Minuten beträgt. Knallkopp.
Naja, war ja nicht anders zu erwarten. gmx.net. Muhahaha.
> ist seit 3,5 Jahren nicht mehr aktualisiert worden,
Stimmt. Wenn du Disco-Software haben willst, die sich irgendwelchen
Modewellen unterwirft und auf Zuruf überflüssigen Bullshit
implementiert, dann bist du bei postfix besser aufgehoben. Fragt sich
allerdings, wieso du dann nicht gleich Exchange einsetzt. Da kriegst du
auch eine toll bunte Management Konsole mit Maus-Konfiguration. Genau
richtig für Schmalspur-Admins deines Kalibers.
> benutzt proprietäre "extended message format[s]", verwendet eigene
> Standards für Bounces (QSBMF)...
Klar, im krassen Gegensatz zu sendmail, die sich da irgendwelchen Müll
ausgedacht haben, und Exchange, die sich irgendwelchen Müll ausgedacht
haben, und Postfix, die sich irgendeinen anderen Müll ausgedacht haben,
und Lotus Notes, die sich noch einen anderen Müll ausgedacht haben...
Fakt: jeder macht das anders. Spezifiziert ist lediglich, woran man
einen Bounce erkennen kann, und das machen qmail und postfix richtig.
> Qmail ist wahrlich kein schlechter MTA. Bei Neuinstallationen würde
> ich aber zu Postfix greifen. Die Konfiguration ist angenehmer zu
> pflegen, es gibt bessere Debugmöglichkeiten, chroot ist trivial
> einzurichten, Bandbreiten werden effizient genutzt, nützliche
> Features sind bereits eingebaut etc. pp.
Du bist echt ein Knallfrosch sondergleichen.
> Naja, vielfach ist die Wahl des MTA' Geschmackssache.
Genau. Install du dir ruhig Postfix. Jeder hat die Krankheiten, die er
verdient hat. Du scheinst ja echt jede Propaganda-Scheiße zu fressen,
die man dir vorwirft... :-(
Daniel Wollschlaeger
> Meister Hildebrandt hat postfix sehr nett (aber selbstverständlich
> komplett irreführend, weil postfix schon deswegen stinkt, weil sein
> Autor Holländer ist[1]) hier beschrieben:
> http://innominate.org/~hildeb/postfix/postfix.pdf
Ich entnehme dem mal, daß die Entscheidung für qmail oder postfix an sich
kein grober Fehler ist und Sicherheitsproblemen ab da am ehesten durch
eigene Inkompetenz entstehen.
> Wietse Z. "tcpwrappers" Venema vs. Daniel J. "ucspi-tcp" Bernstein - was
> erwartest Du?
Keinen heiligen Krieg um so etwas profanes wie einen Mailserver? Außerdem
ist der sicherheitsrelevant, weswegen es für alle Beteiligten doch
eigentlich von Vorteil wäre, wenn ihre Sachargumente nicht automatisch
weniger beachtenswert werden, weil sie neben privaten Auseinandersetzungen
stehen. In a perfect world ...
Daniel
Daniel Wollschlaeger
> Postfix ist bei vergleichbarer Funktionalität mehr als drei mal so groß
> wie qmail. Bei Sicherheitsfragen achtet man auf die Quellcode-Größe,
[...]
> Postfix hat zusätzlich eine Tonne von überflüssiger
> Spielkram-Funktionalität, die man bei qmail im Bedarfsfall über externe
Das sind beides sehr allgemeine Argumente. Deshalb sind sie natürlich
nicht weniger richtig, aber zumindest scheint es damit nicht einen Fall zu
geben in der Art von 'Im Quellcode von Mailserver a wird
Programmiertechnik b an unzähligen Stellen unsicher verwendet. Dadurch hat
es schon oft Sicherheitsprobleme gegeben, und es ist nur eine Frage der
Zeit, bis es wieder soweit ist.' Immerhin!
> Aber das ist Firlefanz. qmail und postfix sind per Default viel
> sicherer als andere Lösungen. Wenn du die Wahl hast oder Purist bist,
> nimm qmail. Wenn nicht, ist es auch nicht schlimm.
Mailserver sind nicht gerade meine erste Leidenschaft. Zeit und Neugier
vorausgesetzt kann ich immer noch ohne Eile tauschen, aber erstmal bin ich
damit zufrieden, daß offenbar zwei ausreichend sichere Lösungen zur
Verfügung stehen, und ich die nehmen kann, mit der ich besser zurecht
komme. Wenn es Probleme gibt, bin am ehesten ich dran Schuld, und das engt
die Fehlersuche angenehm ein.
Daniel
Daniel Wollschlaeger
> Falls Du in qmail Patches aus dritter Hand einspielst, weil Du
> bestimmte Features wie SMTP-Auth o.ä. benötigst, kann es mit der
> Sicherheit Essig sein.
Ok, aber das betrifft qmail nur indirekt.
>> In dieser NG scheint insbesondere die Meinung zu postfix geteilt zu
>> sein,
>
> Nanu? Hast Du Belege in Form von Message-IDs?
<3c09...@fefe.de> vs <slrna0jor...@fm.rz.fh-muenchen.de>
Daniel
Bernd Eckenfels
> wettgemacht (und nicht nur dadurch).
Das eine hat mit dem anderen nix zu tun. VERP fuer Mailinglisten hat nix
damit zu tun dass qmail massiv parallel mit SMTP Connections umgeht und
diese nicht recycled.
Ich persoenlich finde da exim wesentlich angenehmer zu konfigurieren (was
ich meinen mitmenschen und meiner netzanbindung antun will).
Gruss
Bernd
Bernd Eckenfels
> In wie fern und warum ist qmail eine "Bandbreitensau"? Also, was ist bei
> qmail dahingehend anders (nein, ich bin nicht an qmail Bashing
> interessiert sondern lediglich daran, was gemeint ist)?
qmail macht fuer jede mail eine smtp/tcp verbindung. und unter umstaenden
auch zig gleichzeitig zum selben host.
gruss
bernd
Felix von Leitner
> In wie fern und warum ist qmail eine "Bandbreitensau"? Also, was ist bei
> qmail dahingehend anders (nein, ich bin nicht an qmail Bashing
> interessiert sondern lediglich daran, was gemeint ist)?
Wenn du in qmail eine Mail an f...@bar.com und b...@bar.com schreibst,
dann macht qmail dafür zwei SMTP-Verbindungen auf. sendmail und postfix
machen das über eine TCP-Verbindung und geben mehrere rcpt to an.
In der Praxis spielt das genau keine Rolle, außer du bist ein Spammer
oder hast eine kaputte Mailingliste. Echte Mailinglisten benutzen
nämlich VERPs, d.h. pro Empfänger einen anderen Absender, damit bei
Bounces zuverlässig erkannt werden kann, wer jetzt gebounced hat. Wenn
man das macht (und das ist für den Betrieb einer wartungsarmen
Mailingliste essentiell), funktioniert der postfix- und sendmail-Ansatz
nicht mehr, einen Absender und mehrere Empfänger für die gleiche Email
zu benutzen.
Als Unterschied bleibt in diesem Fall also, daß du eine statt zwei
TCP-Verbindungen hast. Was daran Bandbreitenverschwendung ist, würde
dir Heiko erklären, wenn er über das Problem mal nachgedacht hätte,
anstatt hier nur tumbe Propaganda aus dem Postfix-Lager vorzubringen.
> Felix, was ich nicht ganz verstehe ist, warum Du Heiko dermassen
> anfauchst.
Weil er unreflektierten Propaganda-Müll wiedergegeben hat, der genau so
schon zig mal von anderen Knallköppen auf diversen Mailinglisten und in
diversen Diskussionen und Newsgroups angebracht wurde und schon immer
Quatsch war.
Fakt ist, daß Schrott-MTAs wie sendmail und Exchange gerne mal
zusammenbrechen, wenn jemand echt viele Verbindungen zu ihnen aufbaut.
Diese Schrott-Server haben ein Problem damit, wenn eine Mailingliste
unter qmail ihnen 100 Mails parallel zustellen will. Warum? Weil die
MTAs schlecht sind. Mit dem Finger auf qmail zu zeigen ist lächerlich
und kindisch.
> Das er Unrecht hat mag ja sein, aber Heiko ist doch in der
> Vergangenheit nicht gerade durch Trolltum und/oder Lernresistenz
> aufgefallen.
Dieses stumpfe qmail-Bashing aus dem Postfix-Lager ist mehr als
peinlich und macht das umgehend wieder wett.
Felix
Felix von Leitner
> Das eine hat mit dem anderen nix zu tun. VERP fuer Mailinglisten hat nix
> damit zu tun dass qmail massiv parallel mit SMTP Connections umgeht und
> diese nicht recycled.
Auch Bernd äußert sich mal wieder zu Sachen, über die er nicht
nachgedacht hat :-(
man mailingliste (einziger Fall neben Spammern, wo der Fall "eine Mail
an n Empfänger beim gleichen MX" überhaupt auftritt), man VERP
(verhindert, daß man den Body nur einmal schicken kann. SMTP saugt
halt).
> Ich persoenlich finde da exim wesentlich angenehmer zu konfigurieren (was
> ich meinen mitmenschen und meiner netzanbindung antun will).
Exim. In der Tat.
Komisch, daß mich das gar nicht wundert.
Das Bloat-Monster aus der Hölle. Man könnte meinen, der Autor steht
unter einem Geas eines finsteren Schwarzmagiers, der ihn zwingt, jeden
Scheiß einzubauen, wenn nur irgendein Depp auf der Mailingliste danach
fragt. :-(
Ach ja: und exim war auch der mit dem remote exploit über format
strings. Kurz: programmieren kann der Autor auch nicht anständig.
Ich kann Leute nicht ernstnehmen, die so einen Müll einsetzen.
Bernd Eckenfels
Es geht um mehrer verschiedene mails an den gleichen mx, Felix.
Wenn du mal nachdenken wuerdest statt flamen wuerdest du dich nicht immer
wieder laecherlich machen.
VERP kann man mit jedem Mailserver einsetzen. Im Prinzip macht das sowieso
die meiste Mailinglisten Software, man nennt es "personalisierter Content".
Gruss
Bernd
Bernd Eckenfels
> Frage: Das pro Mail bei qmail eine extra TCP Verbindung aufgebaut wird,
> passiert nur, wenn man _die selbe_ Mail an mehrere Empfaenger _eines_
> MXes schickt?
qmail kann nur eine mail pro verbindung.
Sebastian Posner
>>> In wie fern und warum ist qmail eine "Bandbreitensau"? Also, was ist bei
>>> qmail dahingehend anders (nein, ich bin nicht an qmail Bashing
>>> interessiert sondern lediglich daran, was gemeint ist)?
>> Wenn du in qmail eine Mail an f...@bar.com und b...@bar.com schreibst,
>> dann macht qmail dafür zwei SMTP-Verbindungen auf. sendmail und postfix
>> machen das über eine TCP-Verbindung und geben mehrere rcpt to an.
> Das habe ich (sollte ja nicht so schwer sein) nun verstanden. Danke.
>> In der Praxis spielt das genau keine Rolle, außer du bist ein Spammer
>> oder hast eine kaputte Mailingliste.
> Nun stell ich mir gerade mal vor, T-Online wuerde qmail einsetzen und
> nun mal eben ein paar zehntausend TCP Verbindungen zu gmx aufmachen
> (zusaetzlich zu den TCP Verbindungen, die GMX auch so bedient).
> Ob das wirklich so toll ist? Und mit Spam hat das auch nichts zu tun.
> Oder verstehe ich dich da jetzt vollkommen falsch?
Hm. Wenn du *ein und dieselbe* Mail an mehrere Empfänger derselben
Domain schickst macht qmail eben für jeden Empfänger eine Connection auf
und postfix eine pro Domain und schickt dann mehrere RCTP-TOs.
Wenn viele verschiedene Mails an viele verschiedene Empfänger auf
derselben Domain anliegen, machen wenn ich das richtig verstanden habe
*alle* eine Connection pro Mail/Empfänger auf, was auch eigentlich nicht
anders geht, ansonsten müßte die TCP-Connection am sendenden Server
evtl. zwischen den verschiedenen MTA-Threads "herumgereicht" werden,
was sich nicht wirklich wie eine gute Idee anhört.
Und (wie oben beschrieben) ein und dieselbe Mail an viele verschiedene
Empfänger bei derselben Domain verschicken entweder (wie Fefe sagte)
dysfunktionale/nicht optimale Mailinglisten oder eben Spammer.
[...]
>> Als Unterschied bleibt in diesem Fall also, daß du eine statt zwei
>> TCP-Verbindungen hast. Was daran Bandbreitenverschwendung ist, würde
>> dir Heiko erklären, wenn er über das Problem mal nachgedacht hätte,
>> anstatt hier nur tumbe Propaganda aus dem Postfix-Lager vorzubringen.
> Naja, "eine statt zwei" ist harmlos aber was ist bei mehreren
> zehntausend oder mehr?
Bei echtem "Mail-Individualverkehr" (Verschiedene Sender, verschiedene
Empfänger) geht es nicht anders als mit so vielen Connections. Der
Verkehrsvergleich ist IMHO nicht schlecht: Sie die TCP-Conn als ein Fahrzeug.
Sender und Empfänger sind Anfangs- und Endpunkt der Reise, der Passagier
ist die Mail. Wenn von einer Adresse (z.B. Bushaltestelle) viele Mails
zur gleichen Domain an verschiedene Empfänger (z.B. verschiedene
Geschäfte in einem Einkaufszentrum) wollen, kann man die Bandbreite
(Straße) und Ports (Parkplätze vor der Mall) besser ausnutzen als wenn
für jede Mail (Reisender) eine eigene Conn aufgebaut wird (-> jeder
fährt mit seinem eigenen Auto). Wenn nun aber von vielen verschiedenen
Absendern Mails an viele verschiedene Empfänger sollen, ist das mit
einer Connection nicht machbar. Auf das PNV-Modell übertragen müßte der
Bus bei allen, die wegfahren wollen zuhause vor der Haustür vorbeifahren
und jeden einzelnen zu der Adresse fahren, wo sie hinwollen.
Sebastian
--
Dieser Artikel ging an folgende Newsgroups: de.comp.security.misc
Er wurde am Friday, dem 07. December im Jahre des Herrn 2001 verfaßt.
Sebastian Posner
>>> Das eine hat mit dem anderen nix zu tun. VERP fuer Mailinglisten hat nix
>>> damit zu tun dass qmail massiv parallel mit SMTP Connections umgeht und
>>> diese nicht recycled.
[...]
>> man mailingliste (einziger Fall neben Spammern, wo der Fall "eine Mail
>> an n Empfänger beim gleichen MX" überhaupt auftritt),
> Frage: Das pro Mail bei qmail eine extra TCP Verbindung aufgebaut wird,
> passiert nur, wenn man _die selbe_ Mail an mehrere Empfaenger _eines_
> MXes schickt?
Nein. Wenn *dieselbe* Mail an *viele* Empfänger geht, macht postfix
*nicht* eine Connection pro Empfänger auf. Sonst gibt es *immer(?)* eine
Connection pro Mail. Das recyclen der Connection ist die Ausnahme, nicht
die Einmal-Wegwerf-Connection.
>> man VERP
>> (verhindert, daß man den Body nur einmal schicken kann. SMTP saugt
>> halt).
> Das habe ich nicht ganz kapiert. Sorry.
Pro SMTP-Mail kann man zwar beliebig viele to, cc und bcc angeben, aber
nur einen From, steht AFAIK so in den RFCs. Und VERP generiert für jede
Empfängeradresse eine eigene From-Adresse. Und da es nicht die Option
gibt, den Body zu cachen und dann bei der nächsten Mail (eingeleitet
durch das From, in mbox-Files dient daher auch die From:-Zeile als
Mailtrenner) zu sagen "recycle-body" oder so, muß man eben für jeden
Emfänger den Body einzeln schicken.
Wenn alle Empfänger die Mail mit *demselben* Absender erhalten sollen,
schickt man per SMTP den From, dann die 100.000 to/cc/bcc-Adressen
der Empfänger, und dann *einmal* den Body.
Wenn alle Empfänger die Mail mit *verschiedenem* Absender erhalten
sollen, schickt man per SMTP dem From, dann die Adresse den Empfängers,
dann den Body, und wiederholt das ganze 100.000 mal mit identischem
Body und verschiedener From- und To-Adresse.
Lutz Donnerhacke
>Hm. Wenn du *ein und dieselbe* Mail an mehrere Empfänger derselben
>Domain schickst macht qmail eben für jeden Empfänger eine Connection auf
>und postfix eine pro Domain und schickt dann mehrere RCTP-TOs.
Das ist freundliches Verhalten.
>Wenn viele verschiedene Mails an viele verschiedene Empfänger auf
>derselben Domain anliegen, machen wenn ich das richtig verstanden habe
>*alle* eine Connection pro Mail/Empfänger auf, was auch eigentlich nicht
>anders geht, ansonsten müßte die TCP-Connection am sendenden Server
>evtl. zwischen den verschiedenen MTA-Threads "herumgereicht" werden,
>was sich nicht wirklich wie eine gute Idee anhört.
Falsch. Man kann nach einer übertragenen Mail die nächste senden, ohne die
Verbindung hinzuwerfen. Das ist freundliches Verhalten.
>Und (wie oben beschrieben) ein und dieselbe Mail an viele verschiedene
>Empfänger bei derselben Domain verschicken entweder (wie Fefe sagte)
>dysfunktionale/nicht optimale Mailinglisten oder eben Spammer.
Ich mache pro MX eine Verbindung auf und schicke dann alle Mails, die an
diesem MX anstehen in einem Ritt.
Daniel Schmidt
>Thus spake Bernd Eckenfels (ec...@lina.inka.de):
>> Ich persoenlich finde da exim wesentlich angenehmer zu konfigurieren
>> (was ich meinen mitmenschen und meiner netzanbindung antun will).
>
>Exim. In der Tat.
>Komisch, daß mich das gar nicht wundert.
>Das Bloat-Monster aus der Hölle. Man könnte meinen, der Autor steht
>unter einem Geas eines finsteren Schwarzmagiers, der ihn zwingt, jeden
>Scheiß einzubauen, wenn nur irgendein Depp auf der Mailingliste danach
>fragt. :-(
Da ich auch exim in meinem privaten Hausnetz verwende, interessiert mich
dieser Thread nun auch.
Generell bin ich natürlich auch an meiner persönlichen Sicherheit
interessiert, wenn ich schon Verbindung zum Internet habe; allerdings
verlasse ich mich auf die Hersteller meiner Distribution (Debian 2.2r4),
was Vorschläge für Systemdienste angeht. Bei Debian wurde exim als MTA
vorgschlagen, und da ich diese Distribution im Vergleich zu anderen (SuSE,
RedHat, Mandrake) für stabil und sicher halte, würde ich nun gerne wissen,
warum die Entwickler von Debian genau diesen MTA als Standard-MTA wählen,
wo doch qmail oder postfix sicherer sein sollen. Die Konfiguration von exim
fand ich jedenfalls ausgesprochen einfach.
>Ach ja: und exim war auch der mit dem remote exploit über format
>strings. Kurz: programmieren kann der Autor auch nicht anständig.
Ist das für einen MTA relevant, der im Heimnetz betrieben wird, nur an den
smtp-relay des Providers sendet, von fetchmail gefüttert wird, und von
seiner Konfiguration her nur Verbindungen aus dem LAN zulässt? Zusätzlich
lasse ich mit Ausnahme vom auth-Port überhaupt keine Verbindungsaufbauten
aus dem Internet zu meinem Rechner zu (ipchains).
>Ich kann Leute nicht ernstnehmen, die so einen Müll einsetzen.
Das Argument, eine Software nicht einzusetzen, weil der Programmierer nicht
anständig programmieren kann, ist für mich schon verständlich - leider kann
ich genau das nicht selbst überprüfen, da mir diesbezüglich tiefere
Programmierkenntnisse fehlen. Damit dürfte ich ja eigentlich überhaupt
keine Software einsetzen :-(.
Meine Auswahl von exim als MTA beruht einfach darauf, daß er einfach zu
konfigurieren ist, und genau das tut, was ich damit machen möchte.
Ich werde diese Diskussion jedenfalls weiterverfolgen, um evtl. doch auf
einen anderen MTA zu wechseln, wenn es mir notwendig erscheinen sollte.
mfg.,
-ds-
Florian Weimer
> Als Unterschied bleibt in diesem Fall also, daß du eine statt zwei
> TCP-Verbindungen hast. Was daran Bandbreitenverschwendung ist,
Es ist unfair gegenüber Solaris-Mailhubs, wegen der fork()-Kosten.
Aber das ist wirklich das Problem von Solaris.
Florian Weimer
>> In der Praxis spielt das genau keine Rolle, auÞ¿er du bist ein Spammer
>> oder hast eine kaputte Mailingliste.
>
> Nun stell ich mir gerade mal vor, T-Online wuerde qmail einsetzen und
> nun mal eben ein paar zehntausend TCP Verbindungen zu gmx aufmachen
> (zusaetzlich zu den TCP Verbindungen, die GMX auch so bedient).
Ja, und? Wenn qmail das hinbekommt (immerhin werden wahrscheinlich im
gleichen Zuge noch Dutzende anderer Hosts beliefert), wird T-Online
auch damit klarkommen. Durch die sequentielle Abarbeitung werden auch
keine wesentlichen Ressourcen frei, da das eigentlich Teure an der
Mailverarbeitung wohl kaum das Annehmen der Nachricht ist, sondern das
Weiterleiten und Speichern. AuÞ¿erdem steht es jedem Mailhost frei,
sequentielle Auslieferung zu erzwingen.
Ich hätte höchstens Probleme, falls schmalbandig angebundene Hosts
parallel einliefern, da dadurch wirklich Ressourcen gebunden werden.
> Naja, "eine statt zwei" ist harmlos aber was ist bei mehreren
> zehntausend oder mehr?
Die TCP-Verbindyngen sind nicht das Problem, es sind höchstens die
ProzeÞ¿erzeugungskosten auf manchen Systemen.
SchlieÞ¿lich erwartet auch niemand, daÞ¿ Provider HTTP-Requests
serialisieren.
Bernd Eckenfels
> Wenn viele verschiedene Mails an viele verschiedene Empf?nger auf
> derselben Domain anliegen, machen wenn ich das richtig verstanden habe
> anders geht, ansonsten m??te die TCP-Connection am sendenden Server
> evtl. zwischen den verschiedenen MTA-Threads "herumgereicht" werden,
Das geht sehr wohl. Man locked einfach pro MX und durchsucht die Datenbank
der noch auszuliefernen Mails nach weiteren Mails fuer den MX. Da nicht für
jede Mail im Spool ein Threa aktiv ist muss da nix herumgereicht werden.
Zugegebenermassen ist der Vorteil nicht sehr gross. Die Belastung des Ziel
SMTP Servers ist etwas geringer, und bei schlechtem Netz fällt der SlowStart
einer neuen TCP Verbindung weg. (Hat aber auch Nachteile, die hat glaube DJB
in einem Paper breitgetreten).
> Bei echtem "Mail-Individualverkehr" (Verschiedene Sender, verschiedene
> Empf?nger) geht es nicht anders als mit so vielen Connections.
Naja, da ich so ein wenig weiss, was so im Hintergrund abgeht wenn man die
MXe von T-Online, AOL, GMX nicht erreichbar waren (durch den jeweils
anderen), dann stehen da schnell hundertausende von Mails in der Queue. Wenn
dann eine Auslieferung von max_concurrency_remote=100 Threads von 10
out-smtp Servern auf 2 MXen auftreffen, dann sind die schoen am roedeln.
Genauso freuen sich dann noch die User der anderen Domains, dass derweilen
keine Mail zu Ihnen durchkommt.
Gruss
Bernd
Bernd Eckenfels
> Ich mache pro MX eine Verbindung auf und schicke dann alle Mails, die an
> diesem MX anstehen in einem Ritt.
Oder wenn man es ein wenig performanter haben will n Verbindungen. Ist bei
Exim ganz einfach zu konfigurieren.
Gruss
Bernd
Robin S. Socha
> Aus http://www.postfix.org/rate.html:
>| Building a high-performance mail delivery system is one thing;
>| building one that does not knock over other systems is a different
>| story. Some mailers suffer from the thundering herd syndrome: they
>| literally flood other systems with mail. Postfix tries to be a fast
>| mailer and a good neighbor at the same time.
http://cr.yp.to/qmail/faq/efficiency.html#concurrency und
http://cr.yp.to/qmail/faq/efficiency.html#dead-hosts Punkt 3. Könntest
Du bitte mit Deinem Halbwissen irgendwoanders nerven?
Robin S. Socha
> Robin S. Socha <robin-dated-10...@socha.net> wrote:
>> Der behauptete trade-off in Bandbreite wird durch VERP mehr als
>> wettgemacht (und nicht nur dadurch).
>
> Das eine hat mit dem anderen nix zu tun. VERP fuer Mailinglisten hat nix
> damit zu tun dass qmail massiv parallel mit SMTP Connections umgeht und
> diese nicht recycled.
Wo außer auf Mailinglisten ist das "Problem" einer Mail an viele
Empfänger relevant? Spammer sind höchstens dazu da, dass man an ihnen
seine Träume von lustvoller Gewalt auslebt.
> Ich persoenlich finde da exim wesentlich angenehmer zu konfigurieren (was
> ich meinen mitmenschen und meiner netzanbindung antun will).
"Exim, der nette MTA von nebenan". Hatte qmail schon einmal einen
lokalen root exploit?
Sebastian Posner
>> Und (wie oben beschrieben) ein und dieselbe Mail an viele verschiedene
>> Empfänger bei derselben Domain verschicken entweder (wie Fefe sagte)
>> dysfunktionale/nicht optimale Mailinglisten oder eben Spammer.
>
> Ich mache pro MX eine Verbindung auf und schicke dann alle Mails, die an
> diesem MX anstehen in einem Ritt.
Hm. Beim nochmaldrübernachdenken kei Problem. Einfach Queues anlegen die
geflusht werden wenn eine Connection aufgemacht wird...
Sebastian Posner
>> Wenn viele verschiedene Mails an viele verschiedene Empf?nger auf
>> derselben Domain anliegen, machen wenn ich das richtig verstanden habe
>> *alle* eine Connection pro Mail/Empf?nger auf, was auch eigentlich nicht
>> anders geht, ansonsten m??te die TCP-Connection am sendenden Server
>> evtl. zwischen den verschiedenen MTA-Threads "herumgereicht" werden,
>> was sich nicht wirklich wie eine gute Idee anh?rt.
> Das geht sehr wohl. Man locked einfach pro MX und durchsucht die Datenbank
> der noch auszuliefernen Mails nach weiteren Mails fuer den MX. Da nicht für
> jede Mail im Spool ein Threa aktiv ist muss da nix herumgereicht werden.
Hm, ja. Hab ja schon geschrieben daß das eher ein Schnellschuß war...
>> Bei echtem "Mail-Individualverkehr" (Verschiedene Sender, verschiedene
>> Empf?nger) geht es nicht anders als mit so vielen Connections.
> Naja, da ich so ein wenig weiss, was so im Hintergrund abgeht wenn man die
> MXe von T-Online, AOL, GMX nicht erreichbar waren (durch den jeweils
> anderen), dann stehen da schnell hundertausende von Mails in der Queue. Wenn
> dann eine Auslieferung von max_concurrency_remote=100 Threads von 10
> out-smtp Servern auf 2 MXen auftreffen, dann sind die schoen am roedeln.
> Genauso freuen sich dann noch die User der anderen Domains, dass derweilen
> keine Mail zu Ihnen durchkommt.
*g* Bei meinem ehemaligen AG stand ein Mailserver, der *des öfteren*
keine Mails mehr annehmen mochte. War aber "works aas configured". Die
Kiste hatte einfach ein recht kleines Limit an maximalen SMTP_in
Threads, da die Hardware nicht wirklich arb leistungsstark war (IIRC
eine SUN SS5 oder so).
Robin S. Socha
> Lutz Donnerhacke meinte kundzutun:
>>> Und (wie oben beschrieben) ein und dieselbe Mail an viele verschiedene
>>> Empfänger bei derselben Domain verschicken entweder (wie Fefe sagte)
>>> dysfunktionale/nicht optimale Mailinglisten oder eben Spammer.
>>
>> Ich mache pro MX eine Verbindung auf und schicke dann alle Mails, die an
>> diesem MX anstehen in einem Ritt.
>
> Hm. Beim nochmaldrübernachdenken kei Problem. Einfach Queues anlegen die
> geflusht werden wenn eine Connection aufgemacht wird...
Alles Schnickschnack: http://cr.yp.to/im2000.html
Lutz Donnerhacke
>Sebastian Posner <pos...@transcom.de> wrote:
>> Lutz Donnerhacke meinte kundzutun:
>>> diesem MX anstehen in einem Ritt.
>>
>> Hm. Beim nochmaldrübernachdenken kei Problem. Einfach Queues anlegen die
>> geflusht werden wenn eine Connection aufgemacht wird...
>
>Alles Schnickschnack: http://cr.yp.to/im2000.html
djb sollte seine Quellen erlernen. Markus Kuhn hat das 1998 bereits korrekt
gelöst. man X.400.
Mike Gerber
> Wenn du in qmail eine Mail an f...@bar.com und b...@bar.com schreibst,
> dann macht qmail dafür zwei SMTP-Verbindungen auf.
> In der Praxis spielt das genau keine Rolle,
Doch es spielt dann eine Rolle, wenn $USER ein gigantisches $WORDDOKUMENT
an f...@bar.com und b...@bar.com schickt.
Es scheint nur niemand einzusehen, dass nicht qmail hier die
Bandbreitensau ist.
Florian Weimer
> Alles Schnickschnack: http://cr.yp.to/im2000.html
Die letzte Firma, die das implemntierte, ist IIRC vor ein oder zwei
Jahren pleitegegangen.
Rainer Weikusat
Billigst mit heutiger Technik zu simulieren: WWW für
'Nachrichtenverteilung', Mail für Benachrichtigungen.
--
near
distant
Florian Weimer
> Es war von einem "remote _root_ exploit" die Rede. Das hast Du aber
> wirklich geschickt beim Quoten entfernt.
Die Probleme sind, wenn ich Exim richtig überblicke, nicht so weit
davon entfernt.
Bernd Eckenfels
> Wo au?er auf Mailinglisten ist das "Problem" einer Mail an viele
> Empf?nger relevant?
Das genau ist nicht das Problem. Es geht um mehrere Mails an den selben MX.
Gruss
Bernd
Felix von Leitner
> Das ist freundliches Verhalten.
Was ist daran freundlich?
Wer ist da zu wem freundlich?
Wenn ich nicht will, daß jemand mehr als eine Verbindung aufmacht, dann
nehme ich auf meinem Mailserver halt pro IP nur eine Verbindung entgegen
und gebe den anderen einen temporären Fehler und droppe sofort wieder.
Fakt ist also: der Empfänger kann das abschalten, wenn es ihn stört.
Wenn er es nicht tut, will er es also so. Oder er ist zu inkompetent
für seinen Job, in welchem Fall ich auch keinen Mitleid mit ihm habe.
> Falsch. Man kann nach einer übertragenen Mail die nächste senden, ohne die
> Verbindung hinzuwerfen. Das ist freundliches Verhalten.
Wieso das denn? So ein Quark. Was sparst du dadurch denn deiner
Meinung nach an Netzwerk-Traffic? Kaum meßbar, sehr nahe Null.
Pro Mail weniger als der Received-Header.
Was ist z.B. mit einer Monster-Mail mit Mega-MPEG-Attachment und drei
eiligen kleinen Mails? Und das ganze geht über eine Modem-Leitung raus?
Bei deinem Ansatz bleiben die eiligen kleinen Mails hängen, bis das
Mega-Attachment drüben ist. Und dein Unternehmen geht pleite, weil es
den wichtigen Auftrag nicht gekriegt hat. Dumm gelaufen.
Und warum? Weil Lutz "freundlich" sein wollte.
Fakt ist: der MTA kann das nicht entscheiden, also soll er es auch nicht
für mich entscheiden.
> >Und (wie oben beschrieben) ein und dieselbe Mail an viele verschiedene
> >Empfänger bei derselben Domain verschicken entweder (wie Fefe sagte)
> >dysfunktionale/nicht optimale Mailinglisten oder eben Spammer.
> Ich mache pro MX eine Verbindung auf und schicke dann alle Mails, die an
> diesem MX anstehen in einem Ritt.
Kunden mit zeitkritischen Daten hast du nicht, wie? Komisch, das kam
irgendwie anders rüber, als du hier von QoS und Shaping erzählt hast.
Felix
Felix von Leitner
> der noch auszuliefernen Mails nach weiteren Mails fuer den MX. Da nicht für
> jede Mail im Spool ein Threa aktiv ist muss da nix herumgereicht werden.
Datenbank? Threads?!
Bernd, das ist genau der Grund, wieso man qmail einsetzt: Weil es ohne
diesen überflüssigen Schnickschnack auskommt. Gut, daß Leute wie du
keine MTAs programmieren. Außer sie arbeiten bei Microsoft natürlich.
Gleich kommst du womöglich noch mit Design Patterns, UML und Extreme
Programming... :-(
> > Bei echtem "Mail-Individualverkehr" (Verschiedene Sender, verschiedene
> > Empf?nger) geht es nicht anders als mit so vielen Connections.
> Naja, da ich so ein wenig weiss, was so im Hintergrund abgeht wenn man die
> MXe von T-Online, AOL, GMX nicht erreichbar waren (durch den jeweils
> anderen), dann stehen da schnell hundertausende von Mails in der Queue. Wenn
> dann eine Auslieferung von max_concurrency_remote=100 Threads von 10
> out-smtp Servern auf 2 MXen auftreffen, dann sind die schoen am roedeln.
Excuse me? Du behauptest, du wüßtest, was bei T-Online, AOL und GMX im
Hintergrund abgeht, und kommst hier mit Ammenmärchen wie daß die bei 100
parallel einkommenden Mails ein Problem haben?! Mach dich doch nicht
schon wieder lächerlich, Bernd!
Fakt ist, daß sie bei dem von Lutz hier als "freundlich" hingestellten
Verfahren obiges Problem haben. Wenn man nämlich Mails an den gleichen
MX batcht, dann hat man kein anständiges Timeout- und Restart-Handling
und alle ausstehenden Mails schlagen auf einmal auf. Bei qmail werden
die Mails getrennt behandelt und schlagen auf, wenn ihr Timeout abläuft,
nicht wenn der MX wieder erreichbar ist. Dadurch wird obiger "mongolian
sendmail hordes" Effekt gerade vermieden. Lustigerweise ist also das
exakte Gegenteil von Lutzens Darstellung war. sendmails töten sich
regelmäßig gegenseitig, wenn mal ein Link oder ein Server down war.
Bei qmail passiert sowas nicht, weder auf Sender- noch auf
Empfängerseite.
> Genauso freuen sich dann noch die User der anderen Domains, dass
> derweilen keine Mail zu Ihnen durchkommt.
Ich weiß ja nicht, auf welchem Planeten du das mit qmail beobachten zu
können glaubtest, aber die Erde war es nicht.
Felix
--
Memory is like gasoline. You use it up when you are running. Of course
you get it all back when you reboot...
--Actual explanation obtained from the Micro$oft help desk.
Felix von Leitner
> > an n Empf?nger beim gleichen MX" ?berhaupt auftritt)
> Es geht um mehrer verschiedene mails an den gleichen mx, Felix.
Oh, Entschuldigung. Ich nahm an, daß du eine sinnvolle Aussage treffen
wolltest und interpretierte das dementsprechend. Soll nicht wieder
vorkommen.
In dem Fall spart man nämlich keine Bandbreite, und "Bandbreitensau" war
die Ansage.
> Wenn du mal nachdenken wuerdest statt flamen wuerdest du dich nicht
> immer wieder laecherlich machen.
Wer von uns beiden behauptet denn, daß T-Online und zwei MXe hat und bei
100 einkommenden parallelen Mails ein Problem hat?
> VERP kann man mit jedem Mailserver einsetzen.
Nur fällt dann das multi-rcpt-to Verfahren weg und alle brauchen die
gleiche Bandbreite. Schade, daß du mal wieder Müll postest, ohne vorher
zu denken.
> Im Prinzip macht das sowieso die meiste Mailinglisten Software, man
> nennt es "personalisierter Content".
Und schon wieder faselst du :-( Bernd, das ist wirklich anstrengend mit
dir. VERP heißt, daß der _Envelope Sender_ anders ist, damit der Bounce
am Envelope erkennen kann, wessen Mail bouncte. Wenn du vor dem Posten
nachgedacht hättest, wäre dir aufgefallen, daß Envelope != Content ist.
Schade, daß du das nicht getan hast. Seufz.
Felix
Felix von Leitner
> Generell bin ich natürlich auch an meiner persönlichen Sicherheit
> interessiert, wenn ich schon Verbindung zum Internet habe; allerdings
> verlasse ich mich auf die Hersteller meiner Distribution (Debian 2.2r4),
> was Vorschläge für Systemdienste angeht.
Debian ist da notorisch schlecht. Sie liefern eine Tonne unsicherer und
schlechter Software mit. Wenn Debian mal vor lauter religiöser Kriege
über eingedeutschte Fehlermeldungen, Paketdaten, standardisierter Pfade
und Lizenz-Bullshit dazu käme, tatsächlich sinnvolle Arbeit zu
erledigen, könnte es sogar eines Tages eine brauchbare Distribution
werden. Möglicherweise kriegen sie sogar eines Tages ihren Kopf weit
genug aus ihrem Hinterteil extrahiert, um kryptographische Signaturen zu
benutzen, damit man das Update-Feature auch benutzen kann.
Debian ist in meinen Augen eine große Lachnummer.
> Bei Debian wurde exim als MTA vorgschlagen, und da ich diese
> Distribution im Vergleich zu anderen (SuSE, RedHat, Mandrake) für
> stabil und sicher halte,
Debian ist weder stabil noch sicher. Bei Debian hast du die Wahl
zwischen "antik und wertlos" und "aktuell und kaputt".
> würde ich nun gerne wissen, warum die Entwickler von Debian genau
> diesen MTA als Standard-MTA wählen, wo doch qmail oder postfix
> sicherer sein sollen.
Weil sie doof sind? Frag sie doch einfach mal. Nimm dir ein paar
Wochen Urlaub für die Antworten.
> Die Konfiguration von exim fand ich jedenfalls ausgesprochen einfach.
Die von qmail ist auch ausgesprochen einfach.
> >Ach ja: und exim war auch der mit dem remote exploit über format
> >strings. Kurz: programmieren kann der Autor auch nicht anständig.
> Ist das für einen MTA relevant, der im Heimnetz betrieben wird, nur an den
> smtp-relay des Providers sendet, von fetchmail gefüttert wird, und von
> seiner Konfiguration her nur Verbindungen aus dem LAN zulässt?
Wenn du fetchmail einsetzt, ist es nicht so schlimm, weil fetchmail die
Mail möglicherweise wegwirft, bevor sie bei Exim ankommt. Ich kenne
niemanden, der fetchmail schon mal eingesetzt hat, und damit keine Mail
verloren hat. Diese Software gehört in einer Sondermülldeponie
fachgerecht entsorgt. Kein Wunder, daß Eric Raymond so auf Schußwaffen
steht. Wenn ich den Usern meiner Software mit so schöner Regelmäßigkeit
Mails löschen würde, wäre Selbstverteidigung auch ganz oben auf meiner
Liste.
> Zusätzlich lasse ich mit Ausnahme vom auth-Port überhaupt keine
> Verbindungsaufbauten aus dem Internet zu meinem Rechner zu (ipchains).
Setze lieber sichere Software ein, als unsichere Software zu firewallen.
Felix
Felix von Leitner
> djb sollte seine Quellen erlernen. Markus Kuhn hat das 1998 bereits korrekt
> gelöst. man X.400.
Wot? Markus Kuhn hat 1998 X.400 erfunden?
Ich hätte X.400 für älter gehalten. So kann man sich irren.
Und wenn X.400 eine "Lösung" sein soll, dann würde ich gerne das Problem
dazu kennen lernen. Mein bisheriger Kontakt mit X.400 legt nahe, daß es
außerirdischen Ursprungs ist.
Juergen P. Meier
>dazu kennen lernen. Mein bisheriger Kontakt mit X.400 legt nahe, daß es
>außerirdischen Ursprungs ist.
FdI?
Juergen
--
J...@lrz.fh-muenchen.de
"This World is about to be Destroyed!"
Florian Weimer
> Wenn du fetchmail einsetzt, ist es nicht so schlimm, weil fetchmail die
> Mail möglicherweise wegwirft, bevor sie bei Exim ankommt.
Das ist nicht das Hauptproblem, ganz im Gegenteil (auch wenn die
ersten paar Nachrichten natürlich grundsätzlich verloren gehen).
Fetchmail implementiert das POP3-Protokoll einfach falsch -- wenn
die Verbindung wegbricht, bevor das QUIT-Kommando geschickt wurde,
hat man beim nächsten mal einen Haufen Dupes, da fetchmail *vor* dem
QUIT-Kommando mit der Mail-Auslieferung beginnt.
Marc Haber
>eiligen kleinen Mails? Und das ganze geht über eine Modem-Leitung raus?
>Bei deinem Ansatz bleiben die eiligen kleinen Mails hängen, bis das
>Mega-Attachment drüben ist.
Nein, bis zum nächsten scheduled queue run [1]. Es können mehrere
queue runner gleichzeitig laufen. Und in Sonderfällen wie diesem ist
das auch sinnvoll.
Grüße
Marc
[1] üblicherweise alle halbe stunde. Und wenn eine Firma pleite geht,
weil eine Mail 29 Minuten länger als unbedingt notwendig unterwegs
war, wäre Mail eh' das falsche Medium für diese Informationen gewesen.
--
-----------------------------------------------------------------------------
" Mail ist unzuverlaessig, nicht vertrauenswuerdig. | Marc Haber
Aber wenn's funktioniert, ist's ganz nett. " | Mailadresse im Header
- Erik Weber, 05.12.1996 | Fax: *49 721 966 31 29
Marc Haber
>Wenn er es nicht tut, will er es also so. Oder er ist zu inkompetent
>für seinen Job, in welchem Fall ich auch keinen Mitleid mit ihm habe.
Wenn ich für jede kaputte Software "da draussen" Sonderregeln
einführen muss, habe ich einen Vollzeitjob. Und brauche ausserdem
einen MTA wie exim, den Du selbst als bloated bezeichnest.
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
Rainer Weikusat
> > Verbindung hinzuwerfen. Das ist freundliches Verhalten.
>
> Wieso das denn? So ein Quark. Was sparst du dadurch denn deiner
> Meinung nach an Netzwerk-Traffic?
Was sparst Du an x-fach wiederholten Versuchen von tcp, sie an die
Eigenheiten eines gegebenen Pfades immer wieder dann aufs neue
anzupassen, wenn es das gerade getan hat? Alles, was es da an Vefahren
gibt, ist darauf angelegt, 'vorsichtig' gegen einen unbekannten Wert
zu konvergieren, der über verschiedene Sorten von Testpaketen und
Annahmen bzgl der Ursachen anderer beobachteter Effekte allmählich (in
der Theorie) gut angenähert wird. Darüber nach Stop&Wait-Muster
mehr oder minder 'atomar' Datagramme auszutauschen, ist irgendwie eine
seltsame Idee ...
> Was ist z.B. mit einer Monster-Mail mit Mega-MPEG-Attachment und drei
> eiligen kleinen Mails? Und das ganze geht über eine Modem-Leitung raus?
> Bei deinem Ansatz bleiben die eiligen kleinen Mails hängen, bis das
> Mega-Attachment drüben ist.
Andernfalls bleiben sie vielleicht alle vier hängen, weil während der
Verarbeitung des 'Mega-MPEG-Attachments' leider die quota (wahlweise:
die Platte :->) vollgelaufen ist, und keine vollständig übertragen
werden konnte.
"Katastrophen kommen vor."
[...]
> > Ich mache pro MX eine Verbindung auf und schicke dann alle Mails,
> > die an diesem MX anstehen in einem Ritt.
>
> Kunden mit zeitkritischen Daten hast du nicht, wie?
<URL:http://www.ibiblio.org/mdma-release/http-prob.html>
Revers-HTTP/1.0 für Massentransfers von Daten, die _nicht_
zeitkritisch sind (sonst wären sie nämlich keine Mails) ist keine
besonders tolle Idee.
F'up2 wohin?
--
near
distant
Felix von Leitner
> >Was ist z.B. mit einer Monster-Mail mit Mega-MPEG-Attachment und drei
> >eiligen kleinen Mails? Und das ganze geht über eine Modem-Leitung raus?
> >Bei deinem Ansatz bleiben die eiligen kleinen Mails hängen, bis das
> >Mega-Attachment drüben ist.
> Nein, bis zum nächsten scheduled queue run [1]. Es können mehrere
> queue runner gleichzeitig laufen. Und in Sonderfällen wie diesem ist
> das auch sinnvoll.
OK, dann nehmen wir an, daß der Sender des MPEG Attachments bei
$EMPFÄNGER angerufen hat, ob es schon da ist, und es nochmal in die
Queue getan hat. Schon hängt auch der zweite Queue-Run.
Was du hier vorschlägst ist ein Kludge, keine Lösung.
> [1] üblicherweise alle halbe stunde. Und wenn eine Firma pleite geht,
> weil eine Mail 29 Minuten länger als unbedingt notwendig unterwegs
> war, wäre Mail eh' das falsche Medium für diese Informationen gewesen.
Deine Aufgabe als Installateur der Mail-Infrastruktur ist es nicht, die
Entscheidungen des Kunden in Frage zu stellen oder schlecht zu erfüllen,
weil du die Anforderungen für dämlich hälst. Deine Aufgabe ist, ein
zuverlässiges und funktionierendes Email-System einzurichten. Mit qmail
wäre obige Anforderung automatisch erfüllt gewesen, mit sendmail und
postfix nicht.
Felix
Felix von Leitner
> einführen muss, habe ich einen Vollzeitjob. Und brauche ausserdem
> einen MTA wie exim, den Du selbst als bloated bezeichnest.
Tolle Einstellung. Du hast bestimmt auch die Anzahl der Verbindungen an
deinen Webserver auf 3 limitiert. Wer mehr Verbindungen aufmacht, ist
ein Saboteur. Richtig?
Und Sicherheitspatches muß man auch nicht einspielen, denn das ist ja
nicht deine Schuld, wenn jemand deinen Rechner hackt. Der böse
Angreifer ist schuld, und überhaupt, das wäre ja ein Vollzeitjob, sich
anständig um seine Installationen zu kümmern...?!
Das war wohl nichts, Marc.
Felix von Leitner
> > Wieso das denn? So ein Quark. Was sparst du dadurch denn deiner
> > Meinung nach an Netzwerk-Traffic?
> Was sparst Du an x-fach wiederholten Versuchen von tcp, sie an die
> Eigenheiten eines gegebenen Pfades immer wieder dann aufs neue
> anzupassen, wenn es das gerade getan hat?
Das wird TCP eh tun, außer du hast eine dedizierte Leitung wo genau kein
anderer Traffic drüber läuft, und die dich ohne Umwege direkt mit deiner
Gegenseite verbindet.
> Alles, was es da an Vefahren gibt, ist darauf angelegt, 'vorsichtig'
> gegen einen unbekannten Wert zu konvergieren, der über verschiedene
> Sorten von Testpaketen und Annahmen bzgl der Ursachen anderer
> beobachteter Effekte allmählich (in der Theorie) gut angenähert wird.
> Darüber nach Stop&Wait-Muster mehr oder minder 'atomar' Datagramme
> auszutauschen, ist irgendwie eine seltsame Idee ...
Wieso? Hast du Grund zur Annahme, daß es dann nicht funktioniert?
Das ist ja gerade das Schöne an TCP. Es funktioniert. ;)
> "Katastrophen kommen vor."
Tolles Argument. Die Existenz von Windows als beispielhafte Katastrophe
motiviert dich also dazu, Schrott-MTAs einzusetzen, weil Katastrophen ja
eh vorkommen? Kann ich nicht nachvollziehen.
Felix
--
Emacs is a nice operating system, but I prefer UNIX.
--Tom Christiansen
Bernd Eckenfels
> gleiche Bandbreite. Schade, da? du mal wieder M?ll postest, ohne vorher
> zu denken.
Wenn ich mit Exim VERP einsetze, dann macht er trotzdem nicht pro Mail eine
TCP Verbindung auf. Die Belastung der Empfänger hängt dabei nicht nur von
der Bandbreite ab.
>> Im Prinzip macht das sowieso die meiste Mailinglisten Software, man
>> nennt es "personalisierter Content".
> Und schon wieder faselst du :-( Bernd, das ist wirklich anstrengend mit
> dir. VERP hei?t, da? der _Envelope Sender_ anders ist, damit der Bounce
> am Envelope erkennen kann, wessen Mail bouncte.
VERP alleine ist aber nicht der einzigew Grund warum eine mail an mehrere
Empfaenger unterschiedlichen Content/Envelop-From hat. Genaugenommen ist es
wesentlich seltener der Grund als personalisierter Content. Aber in deiner
verbohrten Flamewut interessiert dich glaube nicht, wenn dich jemand
forbilden will.
> nachgedacht h?ttest, w?re dir aufgefallen, da? Envelope != Content ist.
> Schade, da? du das nicht getan hast. Seufz.
Ich weiss dass VERP != Content ist, aber es ist unerhblich fuer die
Diskussion: Auch wenn man keine Mails an mehrere Empfaenger senden kann
können MTAs (ausser Qmail) Verbindungen zu MXen Recyclen. Und das ist
freundliche Nachbarschaft.
Dass du davon nichts weisst erkennt man aber schon an deiner Art zu posten.
Gruss
Bernd
Bernd Eckenfels
> hat man beim n?chsten mal einen Haufen Dupes, da fetchmail *vor* dem
> QUIT-Kommando mit der Mail-Auslieferung beginnt.
Natuerlich tut er das. Damit er die Nachrichten nicht persistent speichern
muss.
Gruss
Bernd
Bernd Eckenfels
> anderer Traffic dr?ber l?uft, und die dich ohne Umwege direkt mit deiner
> Gegenseite verbindet.
Also mein TCP macht leider immer Slow Start.
Gruss
Bernd
Bernd Eckenfels
> gleiche Bandbreite. Schade, dass du mal wieder Muell postest, ohne vorher
> zu denken.
Wenn ich mit Exim VERP einsetze, dann macht er trotzdem nicht pro Mail eine
TCP Verbindung auf. Die Belastung der Empaenger haengt dabei nicht nur
von der Bandbreite ab.
>> Im Prinzip macht das sowieso die meiste Mailinglisten Software, man
>> nennt es "personalisierter Content".
> Und schon wieder faselst du :-( Bernd, das ist wirklich anstrengend mit
> dir. VERP heisst, dass der _Envelope Sender_ anders ist, damit der Bounce
> am Envelope erkennen kann, wessen Mail bouncte.
VERP alleine ist aber nicht der einzigew Grund warum eine mail an mehrere
Empfaenger unterschiedlichen Content/Absender hat. Genaugenommen ist es
wesentlich seltener der Grund als personalisierter Content. Aber in deiner
verbohrten Flamewut interessiert dich glaube nicht, wenn dich jemand
fortbilden will.
Ich weiss dass VERP != Content ist, aber es ist unerhblich fuer die
Diskussion: Auch wenn man keine Mails an mehrere Empfaenger senden kann
koennen MTAs Verbindungen zu MXen Recyclen. Und das ist freundliche
Nachbarschaft. Ob es in langsamen und ausgelsteten Netzen etwas bringt habe
ich nicht nachgemessen. Subjektiv ist dies der Fall.
Dass du mit dem Begriff freundlichkeit nichts anfangen kannst, kann man
schon an deinen Postings erkennen, zum Glück schreibst du keine erfolgreiche
Internet Software.
Gruss
Bernd
Florian Weimer
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> hat man beim n?chsten mal einen Haufen Dupes, da fetchmail *vor* dem
>> QUIT-Kommando mit der Mail-Auslieferung beginnt.
>
> Natuerlich tut er das. Damit er die Nachrichten nicht persistent
Du meinst "temporär".
> speichern muss.
Damit wird aber das POP3-Protokoll verletzt, demzufolge erst nach dem
QUIT die Nachrichten persistent gespeichert werden dürfen.
Bernd Eckenfels
>> Natuerlich tut er das. Damit er die Nachrichten nicht persistent
Nein persistent. Auch temporaere Dateien sind "persistent" (i.e. einen
absturz/Reboot ueberlebend) wenn diese nicht grade im tmp Verzeichnis stehen
:). Temporaer=mit begrenzter Lebenszeit, Persistent=nicht fluechtig.
> Damit wird aber das POP3-Protokoll verletzt, demzufolge erst nach dem
> QUIT die Nachrichten persistent gespeichert werden d?rfen.
Das kann nicht sein. In dem Fall wueden die Nachrichten verlorengehen.
Man holt die Nachrichten, macht sie Persistent (z.b. in dem mann sie
speichert oder per SMTP weiterschickt) markiert sie als gelöscht und dann
commited man. Die dabei auftretenden Duplikate lassen sich in verteilten
Systemen nicht verhindern. Man muss da eine Prüfsummen/MsgId Datenbank
führen wenn man das vermeiden will.
Gruss
Bernd
Felix von Leitner
Warum hast du dann gerade das Gegenteil behauptet?
> aber es ist unerhblich fuer die Diskussion:
Die ganze Diskussion ist unerheblich.
Die Fakten liegen auf dem Tisch, aber ein Dummy haben Wietses dümmliche
und zigfach widerlegte Anti-qmail-Propaganda zitiert.
> Auch wenn man keine Mails an mehrere Empfaenger senden kann koennen
> MTAs Verbindungen zu MXen Recyclen. Und das ist freundliche
> Nachbarschaft.
Bist du auch zum Lesen zu dämlich? Der Gegenbeweis ist von mir bereits
hier angetreten worden. Weniger als 24 Stunden vorher.
Ach Bernd, was soll das bloß werden mit dir? Nicht nur, daß du Schrott
postest, du stehst nicht mal zu deinen Falschaussagen! Inkompetenz ist
verzeihbar, aber Lernresistenz nicht.
> Ob es in langsamen und ausgelsteten Netzen etwas bringt habe
> ich nicht nachgemessen. Subjektiv ist dies der Fall.
Es bringt in keinem Netz etwas. Denn Email ist kein synchroner
Echtzeit-Dienst. Wenn eine Email drei Sekunden später ankommt, spielt
das einfach mal genau gar keine Rolle.
> Dass du mit dem Begriff freundlichkeit nichts anfangen kannst, kann
> man schon an deinen Postings erkennen, zum Glück schreibst du keine
> erfolgreiche Internet Software.
Oh, das ist ja sogar für deine Verhältnisse niedrigstes Niveau!
Bernd, wenn du dich über deine eigene Inkompetenz ärgerst, dann ist das
richtige Verhalten, dir ein paar gute Bücher zu beschaffen und diese
langsam durchzuarbeiten, anstatt andere zu dir in den Schlamm zu ziehen
zu versuchen. Nur weil du zu dämlich zum Schreiben von Software bist,
mußt du dich nicht inadequat fühlen. Deine dämlichen _Äußerungen_ hier
sind ein guter Grund dafür, aber nicht jeder muß Programmierer sein.
Aber wenn du doch mal Programmieren willst: Visual Basic wäre eine
deinen Fähigkeiten angemessene Programmiersprache. Aber deiner
bisherigen "Arbeit" nach zu gehen stehst du eher auf Systeme mit einer
enormen Komplexität, damit die Wahrscheinlichkeit gering ist, daß sich
jemand damit genug viel besser auskennt und dein Geschwafel enttarnen
kann. Tja, muß dir nicht peinlich sein. Solche Leute gibt es viele.
Besonders bei Bürokraten und älteren Akademikern. Ärzte mit deinem
Problem werden gerne Naturheilkundler. Oder bewirb dich bei der
Computerwoche. Die haben nur so Schmalspur-Experten. Da paßt du
bestimmt prima rein.
Felix
Lutz Donnerhacke
[Grosse ISP]
>Fakt ist, daß sie bei dem von Lutz hier als "freundlich" hingestellten
>Verfahren obiges Problem haben. Wenn man nämlich Mails an den gleichen
>MX batcht, dann hat man kein anständiges Timeout- und Restart-Handling
>und alle ausstehenden Mails schlagen auf einmal auf. Bei qmail werden
>die Mails getrennt behandelt und schlagen auf, wenn ihr Timeout abläuft,
>nicht wenn der MX wieder erreichbar ist.
qmail verhaelt sich wie ein aggressives Stueck Schadsoftware. Ich mag das
nicht. Und das von Dir genannte Problem ist auch nicht existent, weil nur
ein Einlieferungskanal benutzt wird, der serverseitig geschlossen werden
kann, ohne dass der Server weiter belaestigt wird.
>Dadurch wird obiger "mongolian sendmail hordes" Effekt gerade vermieden.
>Lustigerweise ist also das exakte Gegenteil von Lutzens Darstellung war.
>sendmails töten sich regelmäßig gegenseitig, wenn mal ein Link oder ein
>Server down war.
Dann wundert mich, warum ich das nicht bemerke.
>Bei qmail passiert sowas nicht, weder auf Sender- noch auf Empfängerseite.
Bei qmail passiert nie was. ;-)
Lutz Donnerhacke
>> >Alles Schnickschnack: http://cr.yp.to/im2000.html
>> djb sollte seine Quellen erlernen. Markus Kuhn hat das 1998 bereits korrekt
>> gelöst. man X.400.
>
>Wot? Markus Kuhn hat 1998 X.400 erfunden?
Nein, er hat es zur Implementierung herangezogen. Genau genommen hat er
X.400 "Objekte" in verteilten X.500 "Datenbanken" abgelegt. Damit konnte er
unvollstaendige Adressangaben behandeln und hatte auch keinen Unterschied
zwischen lokaler und remote Zustellung mehr.
Felix von Leitner
> >Verfahren obiges Problem haben. Wenn man nämlich Mails an den gleichen
> >MX batcht, dann hat man kein anständiges Timeout- und Restart-Handling
> >und alle ausstehenden Mails schlagen auf einmal auf. Bei qmail werden
> >die Mails getrennt behandelt und schlagen auf, wenn ihr Timeout abläuft,
> >nicht wenn der MX wieder erreichbar ist.
> qmail verhaelt sich wie ein aggressives Stueck Schadsoftware.
Wie oben dargelegt ist das Gegenteil der Fall. qmail versucht, alle
Mails fair zu behandeln und zeitnah zuzustellen.
> Ich mag das nicht.
Das bleibt dir natürlich unbenommen.
> Und das von Dir genannte Problem ist auch nicht existent, weil nur
> ein Einlieferungskanal benutzt wird, der serverseitig geschlossen werden
> kann, ohne dass der Server weiter belaestigt wird.
Huh? Wenn das in deinem Szenario erlaubt ist, daß der Server unter Last
halt zumacht, dann invalidiert das deine Kritik an qmail vollständig,
weil der Server dann halt pro IP nur eine TCP-Verbindung annimmt, wenn
ihm die Last zu viel wird.
> >Dadurch wird obiger "mongolian sendmail hordes" Effekt gerade vermieden.
> >Lustigerweise ist also das exakte Gegenteil von Lutzens Darstellung war.
> >sendmails töten sich regelmäßig gegenseitig, wenn mal ein Link oder ein
> >Server down war.
> Dann wundert mich, warum ich das nicht bemerke.
Vielleicht weil du keinen Mail-Hub relevanter Größe fährst oder weil
deine Server nicht lange genug down sind und nicht große Mengen von
Mails von Servern empfangen, die über längere Perioden ausfallen?
Ist ja letztlich auch egal, genau dieses Problem hat AOL und t-online
dazu bewogen, mehr als drei MXen einzurichten. Denn ansonsten gab es
den Yoyo-Effekt: AOL down -> t-online batcht Mails -> AOL wieder oben ->
t-online stellt alle Mails an AOL auf einmal zu -> AOL bricht unter der
Last zusammen -> ad nauseam.
Felix
Claus Aßmann
> > >Dadurch wird obiger "mongolian sendmail hordes" Effekt gerade vermieden.
Hast Du irgendeinen Beleg fuer diese Aussage? Ist das nur Hoerensagen
oder kannst Du uns mitteilen unter welcher Konfiguration dieser
Effekt auftreten soll?
BTW: wenn Deine Argumentation auf Zitaten von DJB beruht, warum
sollte das besser sein als Zitate von anderen MTA Autoren?
--
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.
Andreas Ferber
> BTW: wenn Deine Argumentation auf Zitaten von DJB beruht, warum
> sollte das besser sein als Zitate von anderen MTA Autoren?
DJB ist im Gegensatz zu Wietse ein Gott.
SCNR, Andreas, F'up2p
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - a...@devcon.net - www.devcon.net
Denny Abraham
>Inkompetenz ist verzeihbar, aber Lernresistenz nicht.
"Über Faulheit kann man noch reden, aber Inkompetenz ist
unentschuldbar." - Felix von Leitner in de.comp.security.firewall,
(Message-ID: <3bf1...@fefe.de>)
Naja, ich persönlich bin froh, dass Du das mit der Inkompetenz jetzt
doch anders siehst. Oder vielleicht doch nur so lange, bis Du es für
Deine fachliche Argumentation zum Thema wieder anders herum brauchst ?
Dabei hast Du es doch wirklich nicht nötig, Dein Fachwissen mit
unsachlichen Unhöflichkeiten zu untermauern.
Denny
Marc Haber
>Dabei hast Du es doch wirklich nicht nötig, Dein Fachwissen mit
>unsachlichen Unhöflichkeiten zu untermauern.
s/untermauern/unterminieren/.
Felix ist unzweifelhaft fachlich ausserordentlich kompetent, die
sozialen Defizite (von denen ich auch welche habe, aber nicht in
dieser Ausprägung) machen ihn jedoch nicht zu jemandem mit dem ich
gerne zusammenarbeiten würde.
Felix von Leitner
> > > >Dadurch wird obiger "mongolian sendmail hordes" Effekt gerade vermieden.
> Hast Du irgendeinen Beleg fuer diese Aussage?
Ich habe das mehrfach mit eigenen Augen bei Uni-Servern gesehen, die
wegen Netzumbau ein paar Tage off-line waren und wo der secondary MX
smail fuhr und dann alle Mail auf einmal ablieferte, wenn der primary
wieder oben war. Wenn du dich ein paar Jahre zurück begibst und in
den einschlägigen Mailinglisten und Newsgroups nachschlägst, wirst du
das alle Nase lang auch bei anderen finden. Insbesondere AOL und
t-online, wie gesagt.
Aber das kannst du gerne selber recherchieren, ich bitte sogar darum.
Ich will nicht, daß man mir glaubt. Stellt das in Frage und verifiziert
es selber.
> Ist das nur Hoerensagen oder kannst Du uns mitteilen unter welcher
> Konfiguration dieser Effekt auftreten soll?
Du bist primary und dein secondary ist sendmail oder smail. Dort lagern
sich 40 Kilomails ab. Der sendmail merkt, daß du wieder oben bist.
> BTW: wenn Deine Argumentation auf Zitaten von DJB beruht, warum
> sollte das besser sein als Zitate von anderen MTA Autoren?
Huh?!
Felix
Felix von Leitner
> >Inkompetenz ist verzeihbar, aber Lernresistenz nicht.
> "Über Faulheit kann man noch reden, aber Inkompetenz ist
> unentschuldbar." - Felix von Leitner in de.comp.security.firewall,
> (Message-ID: <3bf1...@fefe.de>)
> Naja, ich persönlich bin froh, dass Du das mit der Inkompetenz jetzt
> doch anders siehst.
entschuldbar != verzeihbar.
Felix
Felix von Leitner
> sozialen Defizite (von denen ich auch welche habe, aber nicht in
> dieser Ausprägung) machen ihn jedoch nicht zu jemandem mit dem ich
> gerne zusammenarbeiten würde.
Zwingt dich ja auch niemand dazu.
Von mir hat niemand etwas zu befürchten, der sich höflich verhält.
Den meisten Leuten ist gar nicht klar, _wie_ beschissen sie sich hier
benehmen.
Wenn jemand in ein Meeting reinplatzt, sich neben mich stellt und mir
ständig mit blöden Fragen ins Wort fällt, dann hole ich
selbstverständlich auch im realen Leben den Wachschutz und lasse
denjenigen unsanft aus dem Gebäude entfernen. Ich bin mir sicher, daß
du das nicht anders handhaben würdest, bei Renitenz in dem hier
gewöhnlich vorliegenden Maßstab.
Felix
Juergen P. Meier
>> Konfiguration dieser Effekt auftreten soll?
>
>Du bist primary und dein secondary ist sendmail oder smail. Dort lagern
>sich 40 Kilomails ab. Der sendmail merkt, daß du wieder oben bist.
Und? der secondary kann genau so schnell und viel senden, wie mein primary
annimmt. Nicht mehr und nicht weniger.
Aber wenigstens bleiben diese 40k mails nicht *STUNDENLANG* auf dem secondary
rumliegen, obwohl mein primary laengst wieder annehmen koennte.
(was mit ein grund war, qmail bei einer bestimmten grossbank zu entsorgen und
doch wieder sendmail zu verwenden. Damals war das die einzig sinnvolle
Alternative, heute wuerde ich halt postfix nehmen)
Btw: Sendmail kann man natuerlich auch limitieren, was die maximale anzahl
der SMTP-deliver prozesse angeht. Und er macht connection-recycling (was
bei diesem Kunden durchaus viel gebracht hat, wegen vielen International
verteilten Toechtern u.a.)
Achja, mailstaus gab es dort natuerlich auch nach dem Umstieg hinundwieder,
aber nach Ursachenbehebung leerten sich die Queues innerhalb weniger Minuten
anstatt Stunden.
Auch das Transfervolumen fuer Rundschreiben/Infomails [exchange, frag nicht]
hilten sich ploetzlich in grenzen, weil statt 5000 einzelnen mails an
GMX, WebDE, Freemail und co nur noch jeweils eine uebertragen wurde.
Aber das ist ja Praxisfern und allerhoechstens ein Spezialfall ;)
Wenn du deinen Primary nicht so konfigurieren kannst, das er auch unter
Last nicht zusammenbricht, dann ist das alleine dein Problem.
Bernd Eckenfels
> wegen Netzumbau ein paar Tage off-line waren und wo der secondary MX
> smail fuhr und dann alle Mail auf einmal ablieferte, wenn der primary
> wieder oben war.
Du bist sicher, dass das smail war? Mein smail macht pro MX immer nur eine
Verbindung auf, und im Gegensatz zu Exim kann man das bei smail auch (leider)
nicht auf eine groessere Maximalanzahl stellen.
So ein Verhalten passt auch
mehr auf Qmail, der die armen Mail Server damit belaestigt, dass er sich
intern nicht merken will, wieviele Verbindungen er schon mit einem Host auf
hat. Was zu einer Reihe von Problemen fuehrt, die man nicht damit loesen
sollten die Anzahl der parallelen Delivers noch höher zu setzen. Zum Glueck
ist qmail so krank programmiert, und kann nur 256 gleichzeitig.
Gruss
Bernd
Mike Gerber
> Aber wenigstens bleiben diese 40k mails nicht *STUNDENLANG* auf dem secondary
> rumliegen, obwohl mein primary laengst wieder annehmen koennte.
Hier verhält sich qmail wirklich nachbarschaftlich (es versucht die Mails
in immer grösser werdenden Abständen auszuliefern, sofern der Ziel-MX
Timeouts zeigt) und ganz und gar nicht als "Sau" wie andere MTAs.
Ja, das macht Probleme, wenn der Ziel-MX eine Weile down war, dann wartet
es natürlich "stundenlang", bis es wieder versucht, den offensichtlich
kaputten MX wieder anzusprechen.
Ich finde, das Verhalten von qmail ist hier optimal.
Eins frage ich mich doch: Wenn man fähig war, den primären MX wieder in
Ordnung zu bringen, warum war man dann nicht fähig, die Timeout-Tabellen
(qmail-tcpto) zu löschen (qmail-tcpok) und die Auslieferung der Mails
manuell auszulösen?
Mike Gerber
> So ein Verhalten passt auch
> mehr auf Qmail, der die armen Mail Server damit belaestigt, dass er sich
> intern nicht merken will, wieviele Verbindungen er schon mit einem Host auf
> hat.
Verstehe ich das richtig: Dein MX nimmt Verbindungen an, die er nicht
handeln kann?
Bernd Eckenfels
> Verstehe ich das richtig: Dein MX nimmt Verbindungen an, die er nicht
> handeln kann?
Nein, meiner nicht.
Gruss
Bernd
Felix von Leitner
> > Ich habe das mehrfach mit eigenen Augen bei Uni-Servern gesehen, die
> > wegen Netzumbau ein paar Tage off-line waren und wo der secondary MX
> > smail fuhr und dann alle Mail auf einmal ablieferte, wenn der primary
> > wieder oben war.
> Du bist sicher, dass das smail war?
Ja, natürlich.
> Mein smail macht pro MX immer nur eine Verbindung auf, und im
> Gegensatz zu Exim kann man das bei smail auch (leider) nicht auf eine
> groessere Maximalanzahl stellen.
Ja und? Was hindert ihn daran, über eine LAN-Leitung einen monströsen
Haufen Mails von einer Vier-Prozessor Monster-IRIX-Kiste mit einem
Terabyte RAID und vier Gig RAM auf einer armen kleinen Sparc 10
abzupumpen? Gar nichts. Er tut es auch prompt. Natürlich trasht die
Platte auf der Sparc 10 vor sich hin und die Box ist absolut
unresponsiv. Aus Kostengründe war das "der Server", d.h. der hat auch
NIS und DNS gemacht und im Effekt war am Ende das gesamte Haus ohne
Internet. Wegen der Dämlichkeit von smail.
> So ein Verhalten passt auch mehr auf Qmail,
Bullshit. Ach Bernd, das macht keinen Spaß, sich von dir zum
hundertsten Mal Falschaussagen als Argumente präsentieren zu lassen.
Diese Behauptung ist zig mal widerlegt worden, hier und anderswo, von
mir und von anderen. Warum aktivierst du nicht mal vor dem Posten dein
Gehirn? Ist das so schwer? Kannst du das nicht?
> der die armen Mail Server damit belaestigt, dass er sich intern nicht
> merken will, wieviele Verbindungen er schon mit einem Host auf hat.
Sag mal, reicht dein mentaler Horizont nicht aus, die hier gebrachten
Argumente zu verstehen, wieso man das so haben will?
> Was zu einer Reihe von Problemen fuehrt, die man nicht damit loesen
> sollten die Anzahl der parallelen Delivers noch höher zu setzen. Zum
> Glueck ist qmail so krank programmiert, und kann nur 256 gleichzeitig.
Prima, daß Bernd sich immer so umfassend informiert vor dem Posten.
qmail kann _255_, nicht 256. Und das liegt nicht an qmail sondern an
select(). Und mehr als 256 remote deliveries machen auch keinen Sinn,
da stellt man lieber einen Cluster auf und benutzt smtprouten, um die zu
verteilen. Wenn man ernsthaft so viele haben will oder braucht. Klingt
mir nach einem klaren Fall von einer Masturbationsübung, Bernd. Tja, da
bist du bei qmail wirklich falsch. qmail ist ein MTA, keine
Wichsvorlage.
Felix
Felix von Leitner
> >Du bist primary und dein secondary ist sendmail oder smail. Dort lagern
> >sich 40 Kilomails ab. Der sendmail merkt, daß du wieder oben bist.
> Und? der secondary kann genau so schnell und viel senden, wie mein primary
> annimmt. Nicht mehr und nicht weniger.
Ist das so? Bei dir vielleicht. Bei der Uni war das nicht so. Da gab
es den ultra-monster-godzilla Mailserver im zentralen Rechenzentrum, der
für 20-30 Institute Relay spielte, und ein paar Institute haben sich da
ein bißchen Altmetall als internen Mailserver hingestellt und darauf
z.B. Lotus Notes oder Exchange installiert. Oder, wenn sie sich
auskannten, einen Unix-MTA.
> Aber wenigstens bleiben diese 40k mails nicht *STUNDENLANG* auf dem secondary
> rumliegen, obwohl mein primary laengst wieder annehmen koennte.
man manual queue run
> (was mit ein grund war, qmail bei einer bestimmten grossbank zu entsorgen und
> doch wieder sendmail zu verwenden. Damals war das die einzig sinnvolle
> Alternative, heute wuerde ich halt postfix nehmen)
Oh prima, da hat wieder jemand gehandelt, der sich wirklich mit der
Materie auskennt. Komisch, daß einem das so häufig bei MCSEs begegnet,
nicht? "Das muß alles raus, das funktioniert nicht. Stattdessen nehmen
wir das hier, damit kenne ich mich auch ein bißchen aus, das ist mal in
der Computerwoche erwähnt worden."
> Btw: Sendmail kann man natuerlich auch limitieren, was die maximale anzahl
> der SMTP-deliver prozesse angeht. Und er macht connection-recycling (was
> bei diesem Kunden durchaus viel gebracht hat, wegen vielen International
> verteilten Toechtern u.a.)
Was soll das denn gebracht haben?
> Achja, mailstaus gab es dort natuerlich auch nach dem Umstieg hinundwieder,
> aber nach Ursachenbehebung leerten sich die Queues innerhalb weniger Minuten
> anstatt Stunden.
Bis qmail bei _Stunden_ ist, vergeht einige Zeit. Offensichtlich war
der Admin (du?) ausgesprochen inkompetent, es so weit überhaupt kommen
zu lassen. Oder willst du mir jetzt erzählen, daß eine "Großbank" kein
Geld für ein Verfügbarkeits-Überwachungssystem hat?
> Auch das Transfervolumen fuer Rundschreiben/Infomails [exchange, frag nicht]
> hilten sich ploetzlich in grenzen, weil statt 5000 einzelnen mails an
> GMX, WebDE, Freemail und co nur noch jeweils eine uebertragen wurde.
Bulk Mailer sollen zahlen. Auch und insbesondere wenn es meine Kunden
sind. Die gesamte Spam-Problematik kommt überhaupt nur daher, daß Email
so billig ist. Ich bin hochzufrieden damit, daß qmail Spammern (jaja,
war bestimmt nur "opt-in" bei deiner Großbank, sicher doch...) Kosten
verursacht.
> Wenn du deinen Primary nicht so konfigurieren kannst, das er auch unter
> Last nicht zusammenbricht, dann ist das alleine dein Problem.
Besuch mich doch einfach mal. Ich gebe dir dann den Primary von damals,
eine Sparc 10 mit ultra-lahmer Schrotti-Platte, du tust da ein sendmail
drauf, und darfst tunen was du willst. Du darfst sogar SunOS 4
ersetzen, wenn du meinst, daß dir das was bringt. Und ich pumpe dann da
40k Mails drauf und wir stellen eine Webcam auf, die beweist, daß die
Kiste nicht unter der Last zusammenbricht. Muhahaha.
Merkst du eigentlich noch was?
Felix
Rainer Weikusat
> Thus spake Rainer Weikusat (weik...@students.uni-mainz.de):
> > > Wieso das denn? So ein Quark. Was sparst du dadurch denn deiner
> > > Meinung nach an Netzwerk-Traffic?
> > Was sparst Du an x-fach wiederholten Versuchen von tcp, sie an die
> > Eigenheiten eines gegebenen Pfades immer wieder dann aufs neue
> > anzupassen, wenn es das gerade getan hat?
>
> Das wird TCP eh tun, außer du hast eine dedizierte Leitung wo genau kein
> anderer Traffic drüber läuft, und die dich ohne Umwege direkt mit deiner
> Gegenseite verbindet.
Das wird es dann tun, falls sich die Charakteristiken der 'dezidierten
Leitung' die hier simuliert wird, entsprechend ändern. Andernfalls
ständig.
> > auszutauschen, ist irgendwie eine seltsame Idee ...
>
> Wieso? Hast du Grund zur Annahme, daß es dann nicht funktioniert?
Es ist häßlich.
> > "Katastrophen kommen vor."
>
> Tolles Argument. Die Existenz von Windows als beispielhafte Katastrophe
> motiviert dich also dazu, Schrott-MTAs einzusetzen, weil Katastrophen ja
> eh vorkommen?
Ich setze 'Schrott-MTAs' ein (Deine Diktion), weil ich Lust dazu habe
(und andere Probleme) und gehe ansonsten davon aus, das Du intelligent
genug bist, um verstanden zu haben, worauf ich hinauswollte.
Falls nicht, brauche ich das auch nicht zu erklären.
F'up2 poster
--
near
distant
Juergen P. Meier
>> Gegensatz zu Exim kann man das bei smail auch (leider) nicht auf eine
>> groessere Maximalanzahl stellen.
>
>Ja und? Was hindert ihn daran, über eine LAN-Leitung einen monströsen
>Haufen Mails von einer Vier-Prozessor Monster-IRIX-Kiste mit einem
>Terabyte RAID und vier Gig RAM auf einer armen kleinen Sparc 10
>abzupumpen? Gar nichts. Er tut es auch prompt. Natürlich trasht die
>Platte auf der Sparc 10 vor sich hin und die Box ist absolut
>unresponsiv. Aus Kostengründe war das "der Server", d.h. der hat auch
Dann wird derjenige gefeuert, der auf der Sparc 10 diesen MTA installiert
und derart falsch konfiguriert hat. Ganz einfach.
>NIS und DNS gemacht und im Effekt war am Ende das gesamte Haus ohne
>Internet. Wegen der Dämlichkeit von smail.
s/smail/dem Idioten, der zu daemlich war den MTA auf der Sparc 10\
korrekt zu konfigurieren/
>> So ein Verhalten passt auch mehr auf Qmail,
>
>Bullshit. Ach Bernd, das macht keinen Spaß, sich von dir zum
Ein daemlicher Idiot kann sich auch mit Qmail sehr schnell ins Bein schiessen.
Du wirst es beispielsweise nicht schaffen, meinen MTA zuhause mit irgendeinem
anderen MTA zuzumuellen, da ich ihn so konfiguriert habe, das er alles
was ueber die leitung kommen _kann_ problemlos verarbeitet.
(und er rechtzeitig aufhoert mails anzunehmen, bevor die spoolarea voll ist)
>> Was zu einer Reihe von Problemen fuehrt, die man nicht damit loesen
>> sollten die Anzahl der parallelen Delivers noch höher zu setzen. Zum
>> Glueck ist qmail so krank programmiert, und kann nur 256 gleichzeitig.
>
>Prima, daß Bernd sich immer so umfassend informiert vor dem Posten.
>qmail kann _255_, nicht 256. Und das liegt nicht an qmail sondern an
>select(). Und mehr als 256 remote deliveries machen auch keinen Sinn,
>da stellt man lieber einen Cluster auf und benutzt smtprouten, um die zu
Oder man nimmt einen MTA, der in einer einzigen Verbindung mehr als eine
mail verschieben kann.
>verteilen. Wenn man ernsthaft so viele haben will oder braucht.
Wenn man ernsthaft sowas braucht (oder wahrscheinlich nur haben will),
nimmt man halt keinen qmail.
Qmail verwende ich dort, wo es sinn macht, qmail zu verwenden.
Dort wo es sinn macht, postfix zu nehmen nehme ich postfix.
Und dann wenn es Sinn machen wuerde, sendmail zu verwenden, wuerde ich sogar
das machen. (wobei mir jetzt auf die schnelle kein beispiel dafuer einfaellt)
Claus Aßmann
> Thus spake Claus Aßmann (ca+se...@mine.informatik.uni-kiel.de):
> > > > >Dadurch wird obiger "mongolian sendmail hordes" Effekt gerade vermieden.
> > Hast Du irgendeinen Beleg fuer diese Aussage?
> Ich habe das mehrfach mit eigenen Augen bei Uni-Servern gesehen, die
> wegen Netzumbau ein paar Tage off-line waren und wo der secondary MX
> smail fuhr und dann alle Mail auf einmal ablieferte, wenn der primary
^^^^^
smail != sendmail.
sendmail (vor 8.12) liefert Mail rein sequentiell aus (von der
Queue). Das heisst, ueber eine offene Verbindung wird schoen
sequentiell Mail eingeliefert.
Du hast also keinen Beleg fuer Deine Aussage.
Desweiteren basieren mehrere Deiner Aussagen auf DJB's Webseiten,
die Du offenbar nicht selber ueberprueft hast. Z.B. beruecksichtigen
seine WWW Seiten bzgl. paralleler Auslieferung kein PIPELINING,
STARTTLS, oder AUTH. Da qmail 1.03 die meisten ESMTP Features nicht
implementiert, kann DJB den Effekt natuerlich auch nicht messen
selbst wenn er seine mehrere Jahre alten Aussagen ueberpruefen
wollte.
Ives Steglich
> Zwingt dich ja auch niemand dazu.
>
> Von mir hat niemand etwas zu befürchten, der sich höflich verhält.
> Den meisten Leuten ist gar nicht klar, _wie_ beschissen sie sich hier
> benehmen.
Nun, dann solltest du dich aber bei bestimmten Punkten an die eigene
Nase fassen. Wie man diversen Postings entnehmen kann, magst du Bernd
nicht und vermischst hier staendig fachliche und persoenliche
Auffassungen und Meinungen.
Das macht es fuer mich sehr schwer deine Postings zu lesen - da entweder
das fachliche zwischen unnoetigen persoenlichen Angriffen gegen Bernd
stehen oder die fachlichen Argumente mit persoenlichen Bermerkungen
versehen sind.
Ich habe deshalb schon ernsthaft ueberlegt Postings zu filtern bei denen
Bern auf dich oder du auf Bernd antwortest - da es mir langsam zu
anstrengend wird die Informationen darin zu suchen.
Tschau
Dalini
--
Der Fotograf muß ein Dieb sein, er muß Augenblicke der Zeit anderer
Menschen stehlen, um seine eigenen kleinen Ewigkeiten zu schaffen.
(Salman Rushdie)
Daniel Schmidt
> > Generell bin ich natürlich auch an meiner persönlichen Sicherheit
> > interessiert, wenn ich schon Verbindung zum Internet habe; allerdings
> > verlasse ich mich auf die Hersteller meiner Distribution (Debian 2.2r4),
> > was Vorschläge für Systemdienste angeht.
>
> Debian ist da notorisch schlecht. Sie liefern eine Tonne unsicherer und
> schlechter Software mit. Wenn Debian mal vor lauter religiöser Kriege
> über eingedeutschte Fehlermeldungen, Paketdaten, standardisierter Pfade
> und Lizenz-Bullshit dazu käme, tatsächlich sinnvolle Arbeit zu
> erledigen, könnte es sogar eines Tages eine brauchbare Distribution
> werden. Möglicherweise kriegen sie sogar eines Tages ihren Kopf weit
> genug aus ihrem Hinterteil extrahiert, um kryptographische Signaturen zu
> benutzen, damit man das Update-Feature auch benutzen kann.
Man muss ja nicht gleich jedes mitgelieferte Programm auch
mitinstallieren. Aber ein apt-get install $Programm bietet aus meiner
Perspektive immer noch deutliche Vorteile gegenueber anderen
Paketverwaltungssystemen. Kryptographische Signaturen waeren hierbei
natuerlich sehr zu begruessen.
> Debian ist in meinen Augen eine große Lachnummer.
Ich muss zugeben, dass das Getue der Entwickler und teilweise auch der
Anwender um diese Distribution zuweilen schon recht komisch anmutet.
Aber da ich nur meine Arbeit mit einem Linuxsystem verrichten moechte,
und das mit Debian sehr gut geht, interessiert mich das nicht so.
Punkte verliert Debian mit der Entscheidung, die naechste Version mit
"3.0" statt "2.4" zu bezeichnen ;-)
> > würde ich nun gerne wissen, warum die Entwickler von Debian genau
> > diesen MTA als Standard-MTA wählen, wo doch qmail oder postfix
> > sicherer sein sollen.
>
> Weil sie doof sind? Frag sie doch einfach mal. Nimm dir ein paar
> Wochen Urlaub für die Antworten.
Ich frag' besser nicht - im Urlaub habe ich anderes zu tun.
> > >Ach ja: und exim war auch der mit dem remote exploit über format
> > >strings. Kurz: programmieren kann der Autor auch nicht anständig.
> > Ist das für einen MTA relevant, der im Heimnetz betrieben wird, nur an den
> > smtp-relay des Providers sendet, von fetchmail gefüttert wird, und von
> > seiner Konfiguration her nur Verbindungen aus dem LAN zulässt?
>
> Wenn du fetchmail einsetzt, ist es nicht so schlimm, weil fetchmail die
> Mail möglicherweise wegwirft, bevor sie bei Exim ankommt. Ich kenne
> niemanden, der fetchmail schon mal eingesetzt hat, und damit keine Mail
> verloren hat. Diese Software gehört in einer Sondermülldeponie
> fachgerecht entsorgt. Kein Wunder, daß Eric Raymond so auf Schußwaffen
> steht. Wenn ich den Usern meiner Software mit so schöner Regelmäßigkeit
> Mails löschen würde, wäre Selbstverteidigung auch ganz oben auf meiner
> Liste.
Welche Alternative zu fetchmail hat man denn? Das Mailabholen durch den
MUA direkt erledigen zu lassen halte ich nicht fuer so toll, bei mir
holt nur mein lokaler Mailserver Mails ab und stellt diese bereit.
fetchmail kann man so einstellen, dass er die Mails auf dem Server nicht
loescht, und mit evtl. auftretenden Duplikaten kann ich ganz gut leben -
besser jedenfalls als mit aus Versehen geloeschten. Bislang habe ich
fetchmail auch nicht als eine so problematische Loesung betrachet.
Du meinst wirklich, ich sollte an dieser Stelle mal etwas weitergehend
recherchieren?
> Setze lieber sichere Software ein, als unsichere Software zu firewallen.
Natuerlich.
google-Suche nach "fetchmail" und "Alternative" hat mich allerdings nicht
sonderlich weitergebracht...
mfg.,
-ds-
Bernd Eckenfels
> Haufen Mails von einer Vier-Prozessor Monster-IRIX-Kiste mit einem
> Terabyte RAID und vier Gig RAM auf einer armen kleinen Sparc 10
> abzupumpen? Gar nichts.
Die Tatsache, dass er nur eine TCP Verbindung aufmacht und eine Mail erst dann
schickt wenn die vorherige angenommen wurde.
> Diese Behauptung ist zig mal widerlegt worden, hier und anderswo
Welche Behauptung ist genau von wem wiederlegt wurden?
Qmail macht bis zu concurrencyremote Verbindungen gleichzeitig zu einem MX
auf. Dabei interessiert es ihn nicht fuer welche anderen Hosts er noch mails
hat und wie Sinnvoll das ist. Es ist schleicht zu faul.
> Sag mal, reicht dein mentaler Horizont nicht aus, die hier gebrachten
> Argumente zu verstehen, wieso man das so haben will?
Wenn du welche bringst dann verstehe ich deine Argumente. Sie sind meistens
nicht sehr anspruchsvoll.
> Prima, da? Bernd sich immer so umfassend informiert vor dem Posten.
> qmail kann _255_, nicht 256. Und das liegt nicht an qmail sondern an
> select().
Zum glueck kennst du dich mit qmail und select() aus. Aber falls du wissen
willst wo dein Fehler ist schau mal hier, da findest du einen Patch der dem
armen qmail beibringt, dass qmail-send beibringt mehr als ein byte fuer die
Sitzungsnummer an qmail-xspn zurueckgeben zu koennen. Daraus ergibt sich fuer
mich deutlich, dass DJB nie damit gerechnet hat auf grossen Mail Servern
eingesetzt zu werden.
Nun ja, was die anzahl der FDs in select() angeht, so finde ich es
erschrecklich dass du beim zusammenkopieren einer libc nicht aufgepasst hast.
Das Limit fuer FD_SETSIZE ist unter Linux mit glibc 1024.
> Und mehr als 256 remote deliveries machen auch keinen Sinn,
Zum Glueck hast du hier ein Beleg dafuer gebracht wieso mehr als 256 Sessions
keinen Sinn machen.
> da stellt man lieber einen Cluster auf und benutzt smtprouten
Ja klar, man kann es sich auch schwierig machen. Nur weil qmail unsinnige
Begrenzungen in der Anzahl der Mails hat die es gleichzeitig ausliefern kann.
Einen weiteren Rechner kann ich durchaus verstehen, aber nur wenn die Hardware
am Limit ist, nicht die Software (oder die Vorstellungskraft des
Programmierers). Ich gehe davon aus dass deine Auftraggeber ueber deinen
unsinnigen Verbrauch von Rechnern sehr erfreut sind.
Gruss
Bernd
Bernd Eckenfels
> Zum glueck kennst du dich mit qmail und select() aus. Aber falls du wissen
> willst wo dein Fehler ist schau mal hier, da findest du einen Patch der dem
> armen qmail beibringt, dass qmail-send beibringt mehr als ein byte fuer die
> Sitzungsnummer an qmail-xspn zurueckgeben zu koennen. Daraus ergibt sich fuer
> mich deutlich, dass DJB nie damit gerechnet hat auf grossen Mail Servern
> eingesetzt zu werden.
http://www.qmail.org/big-concurrency.patch
Und dann natuerlich nicht vergessen den big-todo patch einzuspielen. Dem armen
Rechner geht sonst schnell die Luft aus...
Gruss
Bernd
Lutz Donnerhacke
>qmail kann _255_, nicht 256. Und das liegt nicht an qmail sondern an
>select().
Ich weiß nicht, was Du so trinkst, aber meine teergrube kann mit select 1023
Verbindungen handhaben. Mit poll deutlich mehr.
Claus Färber
> Wenn ich für jede kaputte Software "da draussen" Sonderregeln
> einführen muss, habe ich einen Vollzeitjob. Und brauche ausserdem
> einen MTA wie exim, den Du selbst als bloated bezeichnest.
Die Anzahl der maximal anzunehmenden TCP/IP-Verbindungen *pro*
Gegenstellen-IP einstellen zu können, ist doch wohl das mindeste.
Ansonsten hast du ein Scheunentor mit einem großen DoS-Attacken-
bitte-hier-Schild.
Claus
--
------------------------ http://www.faerber.muc.de/ ------------------------
OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0
Claus Färber
> Auch das Transfervolumen fuer Rundschreiben/Infomails [exchange,
> frag nicht] hilten sich ploetzlich in grenzen, weil statt 5000
> einzelnen mails an GMX, WebDE, Freemail und co nur noch jeweils
> eine uebertragen wurde.
Wie wartet man eigentlich eine Mailingliste mit 5000 Adressen,
wenn man keine VERPs hat?
Robin S. Socha
> Wie wartet man eigentlich eine Mailingliste mit 5000 Adressen,
> wenn man keine VERPs hat?
Mit Mailman, Netscape und einem Katzenfell am rechten Zeigefinger.
Claus Färber
> Die Tatsache, dass er nur eine TCP Verbindung aufmacht und eine
> Mail erst dann schickt wenn die vorherige angenommen wurde.
Und was hindert die arme Sparc, die ja offensichtlich nicht
richtig konfiguriert wurde, daran, mehr Mail anzunehmen als sie
ohne sich zu verschlucken bearbeiten kann?
> Daraus ergibt sich fuer mich deutlich, dass DJB nie damit
> gerechnet hat auf grossen Mail Servern eingesetzt zu werden.
Definiere "groß" in Nachrichten pro Tag.
Die 70000 Mails pro Tag bei Redhat soll zumindest laut DJB ein
486/66 ohne Probleme schaffen. Auch wenn qmail maximal 255
Nachrichten gleichzeitig ausliefern kann dürfte das kaum der
Flaschenhals sein.
Ulrich Eckhardt
> Von mir hat niemand etwas zu befürchten, der sich höflich verhält.
> Den meisten Leuten ist gar nicht klar, _wie_ beschissen sie sich hier
> benehmen.
Bitte nicht mit Gläsern im Steinhaus schmeissen[1]
Höflichkeit ist optional, aber Unhöflichkeit ebenfalls.
Bernd hatte zwar schon bessere Argumente, aber das
Geflame hat er echt nicht verdient. Und es ist furchbar
mühsam die Fakten zwischen deinem Geflame noch erkennen
zu können. Irgendwie schade drum.
Uli
--
Ulrich Eckhardt Tr@nscom
http://www.uli-eckhardt.de http://www.transcom.de
Lagerstraße 11-15 A8
64807 Dieburg Germany
Felix von Leitner
> >Haufen Mails von einer Vier-Prozessor Monster-IRIX-Kiste mit einem
> >Terabyte RAID und vier Gig RAM auf einer armen kleinen Sparc 10
> >abzupumpen? Gar nichts. Er tut es auch prompt. Natürlich trasht die
> >Platte auf der Sparc 10 vor sich hin und die Box ist absolut
> >unresponsiv. Aus Kostengründe war das "der Server", d.h. der hat auch
> Dann wird derjenige gefeuert, der auf der Sparc 10 diesen MTA installiert
> und derart falsch konfiguriert hat. Ganz einfach.
Klar, guter Plan. Welchen Teil von "Uni" hast du nicht verstanden?
Da gibt es kein Geld für Hardware und neues Personal gibt es auch nicht,
weil keiner so besoffen ist, freiwillig für lächerlich wenig Geld diesen
Scheiß ganztägig zu fressen. Aber wem sag ich das, du bist ja
offensichtlich selber an einer Uni, du müßtest die katastrophalen
Umstände ja aus erster Hand kennen.
Im Übrigen gehörst du für diese Darstellung gehauen. Um wie viel Geld
wollen wir wetten, daß du eine Sparcstation 10 mit einer vor 4 Jahren
üblichen SCSI-Platte nicht so konfigurieren kannst, daß ich sie nicht
mit Emails überfluten kann. Wohlgemerkt: 10 base T Ethernet. Entweder
du verlierst, weil ich das Ethernet saturiere, oder du verlierst, weil
deine Platte trasht. Oder beides.
> >NIS und DNS gemacht und im Effekt war am Ende das gesamte Haus ohne
> >Internet. Wegen der Dämlichkeit von smail.
> s/smail/dem Idioten, der zu daemlich war den MTA auf der Sparc 10\
> korrekt zu konfigurieren/
Du machst dich gerade so dermaßen lächerlich, das ist schon nicht mehr
feierlich.
> Du wirst es beispielsweise nicht schaffen, meinen MTA zuhause mit irgendeinem
> anderen MTA zuzumuellen, da ich ihn so konfiguriert habe, das er alles
> was ueber die leitung kommen _kann_ problemlos verarbeitet.
D.h. ich mache das Netz zu. Prima! Billig-DoS!
> (und er rechtzeitig aufhoert mails anzunehmen, bevor die spoolarea voll ist)
Cool, der DoSt sich selbst! Toller Plan!
> >Prima, daß Bernd sich immer so umfassend informiert vor dem Posten.
> >qmail kann _255_, nicht 256. Und das liegt nicht an qmail sondern an
> >select(). Und mehr als 256 remote deliveries machen auch keinen Sinn,
> >da stellt man lieber einen Cluster auf und benutzt smtprouten, um die zu
> Oder man nimmt einen MTA, der in einer einzigen Verbindung mehr als eine
> mail verschieben kann.
Welchen Teil der Begründungen, wieso das schlecht ist, hast du nicht
verstanden?
> Qmail verwende ich dort, wo es sinn macht, qmail zu verwenden.
> Dort wo es sinn macht, postfix zu nehmen nehme ich postfix.
Also gar nicht?
Felix
Felix von Leitner
> Und was hindert die arme Sparc, die ja offensichtlich nicht
> richtig konfiguriert wurde,
Wie bitte?!
Wo kommt dieses neunmalkluge Geschwätz her! Wenn jemand mit voller
Gewalt und viel mehr CPU, Bandbreite und Plattendurchsatz als du eine
echt große Anzahls Mails in deine Richtung pumpt, dann
1. raucht dein Server ab. Dann bist du ein Idiot als Admin, das ist
aber in diesem Fall nicht passiert.
2. nimmst du so viele Mails an, wie du annehmen kannst. Auf Systemen
ohne QoS im System (d.h. Bandbreite zur Platte für MTA reservieren)
wie Unix führt das zu schlechterem Service für alle anderen
Dienste. Das ist geschehen.
3. nimmst du weniger Mails an, als du annehmen könntest. Wäre nett,
ist aber im Allgemeinen keine gute Idee und wird dir den Haß deiner
User sichern.
In diesem Fall kann man nur verlieren. Daher ist er zu vermeiden, und
deshalb ist der sendende smail schuld und nicht der unterdimensionierte
MTA am anderen Ende.
Klar wäre es besser gewesen, für NIS einen eigenen Server zu haben und
mehrere Netzsegmente zu haben, um nicht durch die Netzsaturierung geDoSt
zu werden. Aber das ist eine Uni und die haben kein Geld für Hardware.
Die haben schon Probleme, ihren Profs (und Hausmeistern!) anständige
Gehälter zu zahlen.
> daran, mehr Mail anzunehmen als sie ohne sich zu verschlucken
> bearbeiten kann?
Er hat sich ja nicht verschluckt. Ist das für sendmail- und
Windoze-User so schwer zu verstehen, daß Rechner nicht notwendigerweise
abrauchen oder Mist machen, wenn man sie stark belastet, sondern daß die
dann einfach sehr langsam werden? Auch qmail und postfix sind auf
dieser Hardware nicht in der Lage, mit wire speed Emails
entgegenzunehmen, weil das Sun Dateisystem bis zum Mond und zurück
stinkt und die Platten damals echt langsam waren.
Felix
Felix von Leitner
Das ist systemabhängig. Bernstein hat da sogar noch einen Check drin,
der guckt, ob FD_SET weniger als 255 sind, weil das auf manchen Systemen
so ist. Linux hat dieses Problem nicht.
Bernstein hat intern ein paar Protokolle zwischen den qmail-Prozessen
noch so designed, daß er da nur ein Byte überträgt, daher kommt 255 als
hartes Limit, aber wie der vorhandene Patch zeigt, ist der Fix ziemlich
simpel.
Aber ich gebe Bernstein recht, daß der Patch nicht notwendig ist. Wer
so eine Monster-Concurrency braucht, sollte sich lieber nen Mail-Cluster
installieren oder sich eine anständige Betätigung statt Spammen besorgen.
Felix
Felix von Leitner
> > > > > >Dadurch wird obiger "mongolian sendmail hordes" Effekt gerade vermieden.
> > > Hast Du irgendeinen Beleg fuer diese Aussage?
> > Ich habe das mehrfach mit eigenen Augen bei Uni-Servern gesehen, die
> > wegen Netzumbau ein paar Tage off-line waren und wo der secondary MX
> > smail fuhr und dann alle Mail auf einmal ablieferte, wenn der primary
> ^^^^^
> smail != sendmail.
Ja und? Der Effekt ist nach sendmail benannt, weil sendmail als
EMPFANGENDER MTA unter der Last zusammenbricht.
> sendmail (vor 8.12) liefert Mail rein sequentiell aus (von der
> Queue). Das heisst, ueber eine offene Verbindung wird schoen
> sequentiell Mail eingeliefert.
Und? Es kommen in kürzester Zeit echt viele Mails rein, das ist das
Problem. Ob die jetzt parallel oder sequentiell reinkommen spielt genau
keine Rolle, weil Sites wie AOL, GMX, Hotmail und T-Online natürlich von
echt vielen Leuten Mails kriegen, wenn sie mal ne Weile offline waren.
> Du hast also keinen Beleg fuer Deine Aussage.
Du hast nicht verstanden.
> Desweiteren basieren mehrere Deiner Aussagen auf DJB's Webseiten,
Nein.
> Z.B. beruecksichtigen seine WWW Seiten bzgl. paralleler Auslieferung
> kein PIPELINING, STARTTLS, oder AUTH. Da qmail 1.03 die meisten ESMTP
> Features nicht implementiert, kann DJB den Effekt natuerlich auch
> nicht messen selbst wenn er seine mehrere Jahre alten Aussagen
> ueberpruefen wollte.
Claus, warum laberst du hier mit stumpfem djb-Flaming rum?
Einige dich doch einfach auf eine Teil meiner Aussage, den du
bestreitest, und ich belege ihn dann gerne.
Fakt ist: ob ich jetzt eine oder 20 Verbindungen benutze, um 10
Meg Emails abzugeben, bei dir müssen 10 Meg Emails über das Netz
gelutscht und auf die Platte geschrieben werden. DAS ist eine
invariante Last. Es ist wahr, daß sendmail ein gewaltiges
Performance-Problem hat, wenn man damit echt viele kleine Mails kriegt,
aber das auf qmail zu schieben ist wirklich unter aller Sau.
Dieses ganze Pipelining-Gewäsch bringt in der Praxis nur bei kaputten
MTAs wie sendmail überhaupt meßbare Performancegewinne. Das liegt
daran, daß auf modernen Betriebssystemen fork und exec einfach mal keine
Last erzeugen und der IP Stack echt performant ist. Miß doch einfach
mal mit und ohne HTTP Keep-Alive den Durchsatz und die Latenz deines
Lieblings-Webservers an localhost. Wenn du zu faul bist, empfehle ich
dir http://www.fefe.de/fnord/SPEED, wo ich das mal gemacht habe. Du
wirst sehen, daß keep-alive die Performance nicht nur nicht erhöht,
sondern SOGAR SENKT. Es ist ein widerlicher Kludge aus dem Hause
sendmail, weil es billiger ist, solche Kludges in die Welt zu setzen,
als sendmail mal wegzuschmeißen und neu zu machen. Jetzt, wo es
performante MTAs gibt, ist pipelining obsolet und gehört auf dem
Friedhof der gesammelten Internet-Fehler (von denen die meisten aus
Berkeley kommen) begraben.
Felix
Felix von Leitner
> Bernd hatte zwar schon bessere Argumente, aber das
> Geflame hat er echt nicht verdient.
Daher habe ich mir auch echt Zeit gelassen, bis ich damit anfing. Ich
nehme immer noch an, daß ich eines Tages genügend Reizung an seinem Hirn
anlege, daß er merkt, was er da für eine Scheiße postet und zu seinem
früheren Niveau zurück kehrt. Gut, so viel höher war das noch nie, aber
er könnte wenigstens mal auf die Tippfehler achten. Das ist in letzter
Zeit echt auffällig, daß er da schnoddrige Schluder-Postings absondert.
Peinlich, sowas.
Felix
Felix von Leitner
> Rechner geht sonst schnell die Luft aus...
Der big-todo Patch hat bei allen mir bekannten Benchmarks die
Performance nicht nur nicht erhöht, sondern sogar z.T. deutlich gesenkt.
Kein Wunder also, daß Bernd ihn empfiehlt :-(
Felix von Leitner
> schickt wenn die vorherige angenommen wurde.
Da kein Grund für die Hoffnung besteht, daß du die Argumentation
verstehst, wenn ich sie _noch mal_ bringe, gehe ich darauf nicht noch
mal ein.
> > Diese Behauptung ist zig mal widerlegt worden, hier und anderswo
> Welche Behauptung ist genau von wem wiederlegt wurden?
Blind bist du auch noch? Schmerz laß nach :-O
> Qmail macht bis zu concurrencyremote Verbindungen gleichzeitig zu einem MX
> auf. Dabei interessiert es ihn nicht fuer welche anderen Hosts er noch mails
> hat und wie Sinnvoll das ist. Es ist schleicht zu faul.
Das ist keine Faulheit, das ist elegantes Design. Wenn ich 100 Mails
rausschicken will, dann ist es qmails Aufgabe, das zu tun. Punkt.
Deine "Optimierung" ist keine solche, sondern ein Schuß in den Ofen, den
die sendmail-Leute gemacht haben, weil sie mal wieder nicht nachgedacht
haben vor dem Coden.
> Daraus ergibt sich fuer mich deutlich, dass DJB nie damit gerechnet
> hat auf grossen Mail Servern eingesetzt zu werden.
Die Mailserver sollen ja auch nicht djb einsetzen, sondern qmail. Und
qmail verkraftet mehr Last als sendmail, smail und exim zusammen und
läuft auf einigen der größten Mailserver der Welt. Dein Gefasel ist
ermüdend und falsch.
> Nun ja, was die anzahl der FDs in select() angeht, so finde ich es
> erschrecklich dass du beim zusammenkopieren einer libc nicht aufgepasst hast.
> Das Limit fuer FD_SETSIZE ist unter Linux mit glibc 1024.
Wen interessiert das Limit unter Linux? Bernstein schreibt portable
Software, aber das Konzept wird dir wohl immer verschlossen bleiben.
Du schreibst keine Software, du wartest nur anderer Leute
systemspezifischen, unportablen Legacy-Kram.
> > Und mehr als 256 remote deliveries machen auch keinen Sinn,
> Zum Glueck hast du hier ein Beleg dafuer gebracht wieso mehr als 256 Sessions
> keinen Sinn machen.
Wieviel Mails setzt der größte Mailserver um, den du je gesehen hast?
Wieviel Latenz hat er pro Email? Welche Concurrency?
Wenn du die Concurrency auf 255 limitierst, wie viel Latenz und
Durchsatz hat er dann?
Ich habe einen Mailserver mit deutlich über 100000 Usern mit einem qmail
gesehen, und der hat da mehr über 10 MBit/sec mit Email saturiert
(inklusive POP-3). Mail-Server dieser Größenordnung gibt es nicht so
fürchterlich viele auf der Welt. Und der hat keine größere Concurrency
gebraucht, und kein big toto, und keinen anderen Firlefanz, den
"Experten" deines Kalibers gerne zu Lasten des Kunden empfehlen.
> > da stellt man lieber einen Cluster auf und benutzt smtprouten
> Ja klar, man kann es sich auch schwierig machen. Nur weil qmail unsinnige
> Begrenzungen in der Anzahl der Mails hat die es gleichzeitig ausliefern kann.
> Einen weiteren Rechner kann ich durchaus verstehen, aber nur wenn die Hardware
> am Limit ist, nicht die Software (oder die Vorstellungskraft des
> Programmierers). Ich gehe davon aus dass deine Auftraggeber ueber deinen
> unsinnigen Verbrauch von Rechnern sehr erfreut sind.
Die Hand voll Leute, die über 100 Kilouser haben, haben schon aus
Gründen der Ausfallsicherheit eh einen Cluster. Du faselst also mal
wieder sinnfrei in der Gegend rum.
Felix
Claus Aßmann
> Thus spake Claus Aßmann (ca+se...@mine.informatik.uni-kiel.de):
> > > > > > >Dadurch wird obiger "mongolian sendmail hordes" Effekt gerade
> vermieden.
> > > > Hast Du irgendeinen Beleg fuer diese Aussage?
> > > Ich habe das mehrfach mit eigenen Augen bei Uni-Servern gesehen, die
> > > wegen Netzumbau ein paar Tage off-line waren und wo der secondary MX
> > > smail fuhr und dann alle Mail auf einmal ablieferte, wenn der primary
> > ^^^^^
> > smail != sendmail.
> Ja und? Der Effekt ist nach sendmail benannt, weil sendmail als
> EMPFANGENDER MTA unter der Last zusammenbricht.
Aha, interessant. Jetzt drehst Du das ganze also um.
BTW: RefuseLA und DelayLA koennen zur Lastkontrolle eingesetzt
werden, ebenso wie andere Parameter. Keiner davon ist allerdings
optimal weil Lastmessung extrem OS und hardware-spezifisch ist.
> > Du hast also keinen Beleg fuer Deine Aussage.
> Du hast nicht verstanden.
Hast Du auch irgendwelche Argumente?
> > Z.B. beruecksichtigen seine WWW Seiten bzgl. paralleler Auslieferung
> > kein PIPELINING, STARTTLS, oder AUTH. Da qmail 1.03 die meisten ESMTP
> > Features nicht implementiert, kann DJB den Effekt natuerlich auch
> > nicht messen selbst wenn er seine mehrere Jahre alten Aussagen
> > ueberpruefen wollte.
> Claus, warum laberst du hier mit stumpfem djb-Flaming rum?
Was ist daran "Flaming"? Das sind Tatsachen.
Im Gegensatz zu Dir bleibe ich sachlich.
> Einige dich doch einfach auf eine Teil meiner Aussage, den du
> bestreitest, und ich belege ihn dann gerne.
Ich habe Dich nach dem Beleg gefragt fuer
"mongolian sendmail hordes"
Da hast keinen gebracht. Im Gegenteil, Du verdrehst die Behauptung nun.
> Fakt ist: ob ich jetzt eine oder 20 Verbindungen benutze, um 10
> Meg Emails abzugeben, bei dir müssen 10 Meg Emails über das Netz
> gelutscht und auf die Platte geschrieben werden. DAS ist eine
> invariante Last. Es ist wahr, daß sendmail ein gewaltiges
> Performance-Problem hat, wenn man damit echt viele kleine Mails kriegt,
> aber das auf qmail zu schieben ist wirklich unter aller Sau.
"invariant" bzgl. was?
Ob ich 10MB in 10s oder 1000s schicke, ist ein kleiner Unterschied.
> Dieses ganze Pipelining-Gewäsch bringt in der Praxis nur bei kaputten
> MTAs wie sendmail überhaupt meßbare Performancegewinne. Das liegt
> daran, daß auf modernen Betriebssystemen fork und exec einfach mal keine
> Last erzeugen und der IP Stack echt performant ist. Miß doch einfach
Es gibt leider auch andere OS auf denen sendmail laufen muss.
Z.B. AIX.
> mal mit und ohne HTTP Keep-Alive den Durchsatz und die Latenz deines
> Lieblings-Webservers an localhost. Wenn du zu faul bist, empfehle ich
> dir http://www.fefe.de/fnord/SPEED, wo ich das mal gemacht habe. Du
> wirst sehen, daß keep-alive die Performance nicht nur nicht erhöht,
> sondern SOGAR SENKT. Es ist ein widerlicher Kludge aus dem Hause
Und das hat was mit MTAs zu tun?
Solange Du nicht solche Messungen fuer MTAs hast, sind Deine Daten
hier irrelevant wie jeder andere hinkende Vergleich.
> sendmail, weil es billiger ist, solche Kludges in die Welt zu setzen,
> als sendmail mal wegzuschmeißen und neu zu machen. Jetzt, wo es
> performante MTAs gibt, ist pipelining obsolet und gehört auf dem
> Friedhof der gesammelten Internet-Fehler (von denen die meisten aus
> Berkeley kommen) begraben.
Seit wann unterstuetzt sendmail PIPELINIG und seit wann andere MTAs?
Bitte verdrehe doch nicht die Tatsachen.
PS: ich bin es leid mit Leuten zu "diskutieren", die Behauptungen
aufstellen die sie nicht belegen koennen und dann unsachlich werden.
Bye.
Felix von Leitner
> > EMPFANGENDER MTA unter der Last zusammenbricht.
> Aha, interessant. Jetzt drehst Du das ganze also um.
Nein, wieso?
Der Punkt bei qmail ist, daß es gerade _nicht_ unter extremen
Bedingungen die Arbeit einstellt. Deshalb benutzt man es ja.
qmail ist als Bandbreitensau beschimpft worden, und ich habe dem
entgegen gehalten, daß qmail in allen Nicht-Spam-Szenarien nicht mehr
Bandbreite frißt als andere MTAs und qmail im Gegensatz zu sendmail und
smail nicht unter vielen einkommenden Verbindungen zusammenbricht.
Ich habe hier selbstverständlich keine Positionen zu vertreten, die
andere Leute sich ausgedacht haben.
> BTW: RefuseLA und DelayLA koennen zur Lastkontrolle eingesetzt
> werden, ebenso wie andere Parameter. Keiner davon ist allerdings
> optimal weil Lastmessung extrem OS und hardware-spezifisch ist.
Wozu hast du diese sinnfreien Füllworte in das Posting getan?
> > > Du hast also keinen Beleg fuer Deine Aussage.
> > Du hast nicht verstanden.
> Hast Du auch irgendwelche Argumente?
Wieso sollte ich eine Aussage argumentativ untermauern, die ich nicht
getroffen habe?
> Im Gegensatz zu Dir bleibe ich sachlich.
So? Indem du mir Behauptungen in den Mund legst?
> > Einige dich doch einfach auf eine Teil meiner Aussage, den du
> > bestreitest, und ich belege ihn dann gerne.
> Ich habe Dich nach dem Beleg gefragt fuer
> "mongolian sendmail hordes"
> Da hast keinen gebracht. Im Gegenteil, Du verdrehst die Behauptung nun.
Huh? Wieso sollte ich einen Begriff belegen?
Claus, essentielle Daten aus dem Dialektik-Grundkurs: Belegen kann man
nur _Behauptungen_, keine _Begriffe_.
> > Fakt ist: ob ich jetzt eine oder 20 Verbindungen benutze, um 10
> > Meg Emails abzugeben, bei dir müssen 10 Meg Emails über das Netz
> > gelutscht und auf die Platte geschrieben werden. DAS ist eine
> > invariante Last. Es ist wahr, daß sendmail ein gewaltiges
> > Performance-Problem hat, wenn man damit echt viele kleine Mails kriegt,
> > aber das auf qmail zu schieben ist wirklich unter aller Sau.
> "invariant" bzgl. was?
> Ob ich 10MB in 10s oder 1000s schicke, ist ein kleiner Unterschied.
Vielleicht möchtest du an dieser Stelle belegen, wie du zu der
lächerlichen Behauptung kommst, daß die gleichen Daten über die selte
Ethernet-Leitung um zwei Größenordnungen schneller übertragen werden,
wenn man dafür mehr als eine TCP-Verbindung aufmacht?
"Ich bleibe sachlich", haha.
> > Dieses ganze Pipelining-Gewäsch bringt in der Praxis nur bei kaputten
> > MTAs wie sendmail überhaupt meßbare Performancegewinne. Das liegt
> > daran, daß auf modernen Betriebssystemen fork und exec einfach mal keine
> > Last erzeugen und der IP Stack echt performant ist. Miß doch einfach
> Es gibt leider auch andere OS auf denen sendmail laufen muss.
> Z.B. AIX.
Auch auf AIX performt qmail deutlich besser als sendmail. Auch auf AIX
kann man echt viele Verbindungen in echt kurzer Zeit aufmachen. Du
wirst lachen, aber die Performance des IP Stacks ist heutzutage ein
Verkaufsargument, die Hersteller haben sich da also echt Zeit für
genommen.
> > mal mit und ohne HTTP Keep-Alive den Durchsatz und die Latenz deines
> > Lieblings-Webservers an localhost. Wenn du zu faul bist, empfehle ich
> > dir http://www.fefe.de/fnord/SPEED, wo ich das mal gemacht habe. Du
> > wirst sehen, daß keep-alive die Performance nicht nur nicht erhöht,
> > sondern SOGAR SENKT. Es ist ein widerlicher Kludge aus dem Hause
> Und das hat was mit MTAs zu tun?
> Solange Du nicht solche Messungen fuer MTAs hast, sind Deine Daten
> hier irrelevant wie jeder andere hinkende Vergleich.
Claus, willst du nicht verstehen oder kannst du nicht verstehen?
Es ist nicht nur von der Bandbreite her absolut unerheblich, ob man die
Daten in einer oder in n Verbindungen überträgt, es ist auch von der
Latenz her unerheblich. Das gilt selbstverständlich unabhängig vom
Protokoll.
Komisch, auf deinen sendmail-Webseiten kamst du wie jemand rüber, der so
lächerliche Taktiken nicht nötig hat. So kann man sich irren.
> > sendmail, weil es billiger ist, solche Kludges in die Welt zu setzen,
> > als sendmail mal wegzuschmeißen und neu zu machen. Jetzt, wo es
> > performante MTAs gibt, ist pipelining obsolet und gehört auf dem
> > Friedhof der gesammelten Internet-Fehler (von denen die meisten aus
> > Berkeley kommen) begraben.
> Seit wann unterstuetzt sendmail PIPELINIG und seit wann andere MTAs?
Soll das ein Witz sein? Wen interessiert denn das? Pipelining macht
nur Sinn, wenn man mehr als eine Mail pro Verbindung schickt. Und der
einzige MTA, der kaputt genug ist, davon einen meßbaren
Performancegewinn zu haben, ist sendmail. Pipelining ist für sendmail
erfunden worden.
sendmail hatte 1995 bereits Code für "rcpt streaming" in contrib, es
wurde nur wieder rausgenommen, weil es nicht funktionierte.
> Bitte verdrehe doch nicht die Tatsachen.
Das ist ja wirklich lächerlich.
> PS: ich bin es leid mit Leuten zu "diskutieren", die Behauptungen
> aufstellen die sie nicht belegen koennen und dann unsachlich werden.
> Bye.
Na so ein Zufall. Ich auch nicht.
Felix
Felix von Leitner
> sendmail hatte 1995 bereits Code für "rcpt streaming" in contrib, es
> wurde nur wieder rausgenommen, weil es nicht funktionierte.
BTW: google sagt mir gerade, daß die IETF den pipelining draft explizit
an Eric Allman vorbeigepiped (pardon the pun) hat, damit dieser damit
einverstanden ist (und es umsetzt, natürlich).
Felix
Claus Aßmann
PIPELINING konnte in sendmail nicht ohne wesentliche Aenderungen
an der Architektur funktionieren (Hinweis: no fork() after MAIL).
Diese Aenderungen wurden erst 2001 in Angriff genommen.
Soll ich Eric bitten, Dir das schriftlich zu geben? Er sitzt
naechste Woche wieder im Buero gegenueber von meinem... Frag' mal
Wietse warum er PIPELINING implementiert hat. Oder warst Du derjenige
der auch Wietse nicht als zuverlaessige Quelle betrachtet?
Schade dass ich die Tatsachen aus erster Hand kenne, andere Leute
moegen Deinen Ausfuehrungen glauben.
Es tut mir leid, dass ich Dir geantwortet habe, ich werde versuchen,
Deine Behauptungen nicht mehr durch Tatsachen zu widerlegen.
Bernd Eckenfels
> mal mit und ohne HTTP Keep-Alive den Durchsatz und die Latenz deines
> Lieblings-Webservers an localhost. Wenn du zu faul bist, empfehle ich
> dir http://www.fefe.de/fnord/SPEED, wo ich das mal gemacht habe. Du
> sondern SOGAR SENKT.
Mal eine Frage aus Neugierde... welche Praxis Relevanz hat ein loop Test auf
localhost. Und vor allem wie bekommt man da aussagekraeftige Benchmark Werte
hin, ohne dass sich client und server gegenseitig beeinflussen? Garnicht?
Stimmt.
Gruss
Bernd
Claus Färber
> 2. nimmst du so viele Mails an, wie du annehmen kannst. Auf Systemen
> ohne QoS im System (d.h. Bandbreite zur Platte für MTA reservieren)
> wie Unix führt das zu schlechterem Service für alle anderen
> Dienste. Das ist geschehen.
Wenn der Server so viel Mail (bzw. SMTP-Verbindungen) annimmt,
dass er zu dreschen anfängt, dann ist das "mehr Mail, als man
annehmen kann".
Daran ist dann der Admin schuld (bzw. Programmierer, der einen
Mailer mit riesigen smtpd-Prozessen verbrochen hat).
Wenn dann auch noch essentielle Netzwerkdienste ausfallen, weil
sie auf dem gleichen Server laufen... - dann sollte man zumindest
die DoS-Scheunentore schließen.
Lutz Donnerhacke
>Sinn, wenn man mehr als eine Mail pro Verbindung schickt. Und der einzige
>MTA, der kaputt genug ist, davon einen meßbaren Performancegewinn zu
>haben, ist sendmail. Pipelining ist für sendmail erfunden worden.
Nein. Pipelining ist erfunden worden, um den Ablaufgraphen des SMTP zu
komprimieren.
Claus Färber
> macht nur Sinn, wenn man mehr als eine Mail pro Verbindung
> schickt.
Sag mal, kennst du den Standard, der die Erweiterung spezifiziert
oder rätst du nur?
Pipelining bringt einen Gewinn, wenn man mehrere, jeweils vom
Ergebnis des vorherigen unabhängige SMTP-Befehle nacheinander
verschickt. Das passiert auch bei einer E-Mail.
Arnim Weidner
>
> qmail ist eine Bandbreitensau.
Hallo,
Was mich an der ganzen Sache wundert: Warum hat DJB bei qmail
den Weg der Bandbreitensau gewaehlt, wo er doch sonst kleine,
effiziente, ressourcenschonende und funktionierende Programme
schreibt? Zumal er das multi rcpt-to auf der incoming Seite
eh implementieren muss.
Vielleicht hat DJB ja seine Gruende dafuer: kleinerer Code,
Fehlersicherheit o.ae.? Hat er sich denn mal dazu geaeussert?
Man koennte vermuten dass DJB triftige Gruende hatte, wie auch
die jetzt von Venema veroeffentlichte DOS Moeglichkeit bei
Postfix zeigt. Die ruehrt IMHO, aber ich kenn mich nicht so
gut mit SMTP und Postfix aus, genau aus diesem multi rcpt-to.
Die Meldung kam gestern auf der debian-security-announce,
steht aber leider noch nicht auf der Webseite:
http://www.debian.org/security/
Der diff Patch fuer die Debian findet sich bei:
http://security.debian.org/dists/stable/updates/main/source/
postfix_0.0.19991231pl11-2.diff.gz
postfix_0.0.19991231pl11.orig.tar.gz
Vielleicht kann das mal jemand anschauen, der sich besser als
ich damit auskennt.
Beste Gruesse
Arnim