qmail: MX-Record ?
Rene' Kray
ich habe folgendes Problem:
Auf meinem mailserver läuft qmail. Ich möchte Mails an einen
mailserver verschicken, der hinter einer Firewall sitzt. Die Firewall
blockt meine SMTP-Anfrage offensichtlich ab, aber für die Ziel-Domain
sind weitere mailserver im MX-Record angegeben. Da der eigentliche
Ziel-mailserver nicht erreichbar ist, sollte qmail versuchen die
alternativen mailserver zum ausliefern der Mail zu benutzen.
_Aber_ das tuts nicht. :-(
Muß man das qmail explizit beibringen?
Wie kann ich feststellen, an welche Mailserver sich qmail wendet? Die
Logdateien sind da wenig aussagekräftig.
Btw. die Leute auf dem Ziel-mailserver bekommen mail aus aller Welt,
nur von mir nicht, und ich konnte bisher auch alle server erreichen,
nur diesen einen speziellen nicht. :-( :-(
cu René
Ps.: ich möchte keinen thread "Mein MTA ist besser/schöner/größer als
Deiner" auslösen ;-)
--
.----------------------------------------------------.
| René Kray (mailto:c...@pool.math.tu-berlin.de) |
`----------------------------------------------------'
Sebastian Niehaus
[...]
> ich habe folgendes Problem:
> Auf meinem mailserver läuft qmail. Ich möchte Mails an einen
> mailserver verschicken, der hinter einer Firewall sitzt. Die Firewall
> blockt meine SMTP-Anfrage offensichtlich ab,
Und sowas hat einen MX-Record?
Armes Deutschland....
> aber für die Ziel-Domain
> sind weitere mailserver im MX-Record angegeben. Da der eigentliche
> Ziel-mailserver nicht erreichbar ist, sollte qmail versuchen die
> alternativen mailserver zum ausliefern der Mail zu benutzen.
> _Aber_ das tuts nicht. :-(
> Muß man das qmail explizit beibringen?
"kommt drauf an".
Apropos: "man qmail-remote" und "smtproutes" kennst Du?
> Wie kann ich feststellen, an welche Mailserver sich qmail wendet? Die
> Logdateien sind da wenig aussagekräftig.
qmail meldet zumindest bei /Erfolg/, an welchen Server es die Mail
losgeworden ist.
> Btw. die Leute auf dem Ziel-mailserver bekommen mail aus aller Welt,
> nur von mir nicht, und ich konnte bisher auch alle server erreichen,
> nur diesen einen speziellen nicht. :-( :-(
Dann ist der dort Admin ein Idiot.
Sebastian
Joachim Wehlack
> Hi folks,
> ich habe folgendes Problem:
> Auf meinem mailserver läuft qmail. Ich möchte Mails an einen
> mailserver verschicken, der hinter einer Firewall sitzt. Die Firewall
> blockt meine SMTP-Anfrage offensichtlich ab,
Wie lautet die Fehlermeldung?
> Btw. die Leute auf dem Ziel-mailserver bekommen mail aus aller Welt,
> nur von mir nicht, und ich konnte bisher auch alle server erreichen,
> nur diesen einen speziellen nicht. :-( :-(
Na dann mach doch mal eine Fehlersuche. Versuche mal mit
"telnet mailserver 25" (von deinem mailserver aus) eine Verbindung
aufzubauen. Die smtp Kommandos sind simpel und du kannst so direkt
sehen, was passiert, wenn du eine Mail 'zu Fuss' versendest.
mfg
Joachim
--
Spamschutz: Meine zur Zeit gültige E-Mail Adresse kannst du erfahren,
indem du eine Mail (Inhalt egal - Mail wird gelöscht) an den, in der
Von/FROM-Zeile angegebenen, Absender sendest.
Matthias Andree
> Hi folks,
> ich habe folgendes Problem:
> Auf meinem mailserver läuft qmail.
Erstes Problem, weil... [weiter bei (1)]
> Ich möchte Mails an einen mailserver verschicken, der hinter einer
> Firewall sitzt. Die Firewall blockt meine SMTP-Anfrage offensichtlich
> ab,
Woher weißt Du das? Mit telnet probiert? Oder gibt die Kiste eine blöde
Antwort mit einer Zahl ab 500 vorn?
> aber für die Ziel-Domain sind weitere mailserver im MX-Record
> angegeben. Da der eigentliche Ziel-mailserver nicht erreichbar ist,
Ist er das wirklich nicht? Kann qmail das erkennen?
> sollte qmail versuchen die alternativen mailserver zum ausliefern der
> Mail zu benutzen. _Aber_ das tuts nicht. :-(
Show logs?
> welche Mailserver sich qmail wendet? Die Logdateien sind da wenig
> aussagekräftig.
[(1)] ...qmail scheiße loggt.
> Btw. die Leute auf dem Ziel-mailserver bekommen mail aus aller Welt,
> nur von mir nicht, und ich konnte bisher auch alle server erreichen,
> nur diesen einen speziellen nicht. :-( :-(
Hätteste mal den Namen dazugeschrieben (ruhig ohne Lokalteil der
Adresse), hätte jemand mal nachsehen können, was da im Busch ist.
--
Matthias Andree
Matthias Andree
[Erster MX hinter Firewall]
> Und sowas hat einen MX-Record?
Regelmäßig. Und wenn man kein Split-DNS haben will, aber intern trotzdem
direkt zustellen will statt über Backup-MX, könnte man die Idee durchaus
brauchbar finden, wenn man mit den zusätzlichen RST-/ICMP-Paketen und
der höheren Latenzzeit leben will. Allerdings sollte die Firewall auch
wirklich ICMP oder RST zurückgeben. Die Ciscos diverser Unis taten das
geraume Zeit lang nicht.
> Apropos: "man qmail-remote" und "smtproutes" kennst Du?
Sollte überflüssig sein, es sei denn, es ist keine Firewall.
> qmail meldet zumindest bei /Erfolg/, an welchen Server es die Mail
> losgeworden ist.
Das ist nicht genug.
--
Matthias Andree
Rene' Kray
>> Auf meinem mailserver läuft qmail.
> Erstes Problem, weil... [weiter bei (1)]
;-) mag schon sein, ist aber nicht meine Entscheidung. Ich muß das Ding nur
administrieren.
>> Ich möchte Mails an einen mailserver verschicken, der hinter einer
>> Firewall sitzt. Die Firewall blockt meine SMTP-Anfrage offensichtlich
>> ab,
> Woher weißt Du das? Mit telnet probiert? Oder gibt die Kiste eine blöde
> Antwort mit einer Zahl ab 500 vorn?
Ups, klang meine Frage so unwissend? ;-)
Ich habe probiert:
$ telnet fb3-s7.math.tu-berlin.de smtp
und bekam zur Antwort:
Trying 130.149.11.8...
Connected to fb3-s7.math.TU-Berlin.DE.
Escape character is '^]'.
421 gate.hhi.de Sorry, unable to contact destination SMTP daemon.
Connection closed by foreign host.
Wenn ich das gleiche aus dem Netz math.tu-berlin.de probiere, komme
ich ohne weiteres auf den Server. (ich schicke ihm ein helo und
bekomme Antwort).
Ich habe auch auf den fb3-s7 ssh-Zugriff, also ist dort alles ok.
Die Zieldomain ist übrigens @pool.math.tu-berlin.de.
>> aber für die Ziel-Domain sind weitere mailserver im MX-Record
>> angegeben. Da der eigentliche Ziel-mailserver nicht erreichbar ist,
> Ist er das wirklich nicht?
Naja, was soll ich sagen, s.o.
> Kann qmail das erkennen?
Das ist die Frage, wie stelle ich fest, ob qmail das erkennt, und
wenn es erkannt wird, wie reagiert qmail darauf, wie kann man
beeinflussen, wie qmail reagiert, kann man das überhaupt? (ohne die
sourcen zu patchen)
>> sollte qmail versuchen die alternativen mailserver zum ausliefern der
>> Mail zu benutzen. _Aber_ das tuts nicht. :-(
> Show logs?
May 17 09:49:20 numalfix qmail: 1021621760.302135 delivery 71:
deferral:
Connect ed_to_130.149.11.8_but_greeting_failed./Remote_host_said:
_421_gate.hhi.de_Sorry,
_unable_to_contact_destination_SMTP_daemon./
also das gleiche, wie wenn ich direkt per telnet zuzugreifen.
thanks&bye
René
--
.----------------------------------------------------.
| René Kray (mailto:c...@pool.math.tu-berlin.de) |
`----------------------------------------------------'
Verbringe deine Zeit nicht mit der Suche nach einem Hindernis, vielleicht ist
keins da. (Franz Kafka)
Rene' Kray
>> ich habe folgendes Problem:
>> Auf meinem mailserver läuft qmail. Ich möchte Mails an einen
>> mailserver verschicken, der hinter einer Firewall sitzt. Die Firewall
>> blockt meine SMTP-Anfrage offensichtlich ab,
> Und sowas hat einen MX-Record?
> Armes Deutschland....
... warum auch nicht, ich war eigentlich der Meinung, das der
MX-Backup-Record eigentlich für solche Fälle gedacht ist.
>> aber für die Ziel-Domain
>> sind weitere mailserver im MX-Record angegeben. Da der eigentliche
>> Ziel-mailserver nicht erreichbar ist, sollte qmail versuchen die
>> alternativen mailserver zum ausliefern der Mail zu benutzen.
>> _Aber_ das tuts nicht. :-(
>> Muß man das qmail explizit beibringen?
> "kommt drauf an".
> Apropos: "man qmail-remote" und "smtproutes" kennst Du?
danke, daß hatte ich überlesen. Allerding denke ich, daß das nur eine
vorübergehende Lösung sein kann.
>> Btw. die Leute auf dem Ziel-mailserver bekommen mail aus aller Welt,
>> nur von mir nicht, und ich konnte bisher auch alle server erreichen,
>> nur diesen einen speziellen nicht. :-( :-(
> Dann ist der dort Admin ein Idiot.
Mmmm, naja, das will ich nicht ausschließen. ;-)
Es ist aber schon komisch, daß scheinbar nur ich solche Probleme
habe.
cu René
--
.----------------------------------------------------.
| René Kray (mailto:c...@pool.math.tu-berlin.de) |
| (http://www.cs.tu-berlin.de/~kray/) (ICQ:13437046) |
Matthias Andree
>>> Ich möchte Mails an einen mailserver verschicken, der hinter einer
>>> Firewall sitzt. Die Firewall blockt meine SMTP-Anfrage offensichtlich
>>> ab,
>> Woher weißt Du das? Mit telnet probiert? Oder gibt die Kiste eine blöde
>> Antwort mit einer Zahl ab 500 vorn?
> Ups, klang meine Frage so unwissend? ;-)
Nein, aber die Ausprägung der Abweisung ist essentiell. Wirft die
Firewall SYN-Pakete weg, schickt sie ICMP, schickt sie RST.
> Trying 130.149.11.8...
> Connected to fb3-s7.math.TU-Berlin.DE.
> Escape character is '^]'.
> 421 gate.hhi.de Sorry, unable to contact destination SMTP daemon.
> Connection closed by foreign host.
DAS ist ein Problem. Qmail denkt sich: "später geht's ja wieder" und
legt sich damit auf den Bart.
Abhilfe: Versuch' mal, eine Reject-Route für 130.149.11.8 einzutragen
oder auf dem qmail-Rechner per Paketfilter ausgehend für 130.149.11.8
TCP Port 25 zu verbieten.
Ungeschickt ist das (seitens der TU Berlin) auf jeden Fall, wenn das
Problem nicht nur vorübergehender Natur ist.
>> Kann qmail das erkennen?
> Das ist die Frage, wie stelle ich fest, ob qmail das erkennt, und
> wenn es erkannt wird, wie reagiert qmail darauf, wie kann man
> beeinflussen, wie qmail reagiert, kann man das überhaupt? (ohne die
> sourcen zu patchen)
Ohne Patches geht bei qmail gar nichts. Das meiste Verhalten ist hart
verdrahtet. So auch dieses. Deswegen hab' ich meine qmail-Installationen
inzwischen auch alle in die Tonne getreten. Kann höchstens sein, daß auf
einer IPX mit 120 MB-Platte, die eh nie Mails verschickt, noch eins
läuft.
> May 17 09:49:20 numalfix qmail: 1021621760.302135 delivery 71:
> deferral:
> Connect ed_to_130.149.11.8_but_greeting_failed./Remote_host_said:
> _421_gate.hhi.de_Sorry,
> _unable_to_contact_destination_SMTP_daemon./
>
> also das gleiche, wie wenn ich direkt per telnet zuzugreifen.
Solche Meldungen sind aber essentiell.
Nach Lektüre von qmail-remote.c (aus qmail-1.03):
qmail versucht grundsätzlich nur den ersten MX, zu dem es eine
Verbindung bekommen kann. Wenn der sich mit Meldungen wie 421 oder so
verabschiedet: bei qmail hast Du verloren. Auch aus anderen Gründen.
Insofern gilt meine Empfehlung: bei Ärger mit qmail auf Postfix
umstellen. Weniger Systemlast, mehr Flexibilität, mehr Transparenz,
robuster, und bei chroot auch mehr Sicherheit.
Postfix 1.1.10 kommt damit klar, sofern man nicht smtp_skip_4xx_greeting
vom Default "yes" auf "no" geändert hat, Auszug aus
src/smtp/smtp_connect.c, smtp_connect_addr(), Zln. 244ff.:
/*
* Skip this host if it sends a 4xx greeting.
*/
if (ch == '4' && var_smtp_skip_4xx_greeting) {
vstring_sprintf(why, "connect to %s[%s]: server refused mail service",
addr->name, inet_ntoa(sin.sin_addr));
smtp_errno = SMTP_RETRY;
vstream_fclose(stream);
return (0);
}
Wie es mit anderer Software (Sendmail, Exim, Mercury) aussieht, weiß ich
nicht, augenscheinlich benehmen diese Pakete sich ähnlich wie Postfix
und probieren einfach den nächsten, auch, wenn der erste 4xx gesagt hat
-- sonst hätten andere auch das Problem.
--
Matthias Andree
Rene' Kray
>> Trying 130.149.11.8...
>> Connected to fb3-s7.math.TU-Berlin.DE.
>> Escape character is '^]'.
>> 421 gate.hhi.de Sorry, unable to contact destination SMTP daemon.
>> Connection closed by foreign host.
> DAS ist ein Problem. Qmail denkt sich: "später geht's ja wieder" und
> legt sich damit auf den Bart.
> Abhilfe: Versuch' mal, eine Reject-Route für 130.149.11.8 einzutragen
> oder auf dem qmail-Rechner per Paketfilter ausgehend für 130.149.11.8
> TCP Port 25 zu verbieten.
> Ungeschickt ist das (seitens der TU Berlin) auf jeden Fall, wenn das
> Problem nicht nur vorübergehender Natur ist.
Bedauerlicherweise ist es nicht vorübergehen und ich habe mir
sagenlassen, das die Verantwortlichen bezüglich Veränderungen nicht
besonders zugänglich sind. :-(
Ich habe das Problem erstmal im Griff, in dem ich smtproutes für
die problematischen Domains gestezt habe. Längerfristig wäre mir
latürnicht eine Lösung lieber, die allgemeingültigt ist.
Tja, vieleicht muß es ja doch mal ein anderer MTA als qmail werden,
zumal ich demnächst pop3s und imaps einrichten will/soll.
Danke für die Hilfeleistung
René
--
.----------------------------------------------------.
| René Kray (mailto:c...@pool.math.tu-berlin.de) |
`----------------------------------------------------'
Die bunten Gürtel zeichnen dich nicht vor den Schwächeren aus, sie schützen dich
vor den Stärkeren. (Karatelehrer)
Sebastian Niehaus
[...]
> Tja, vieleicht muß es ja doch mal ein anderer MTA als qmail werden,
> zumal ich demnächst pop3s und imaps einrichten will/soll.
*Das* ist so ziemlich garkein Argument, qmail wegzuwerfen.
Sebastian
Sebastian Niehaus
[...]
> >> Btw. die Leute auf dem Ziel-mailserver bekommen mail aus aller Welt,
> >> nur von mir nicht, und ich konnte bisher auch alle server erreichen,
> >> nur diesen einen speziellen nicht. :-( :-(
[...]
> Es ist aber schon komisch, daß scheinbar nur ich solche Probleme
> habe.
qmail versucht keinen weiten MX, sofern es eine Verbindung zum ersten
Mailserver aufbauen konnte. Auch wenn die nicht zur Abnahme der Mail
führte.
Sebastian
Robin S. Socha
> Insofern gilt meine Empfehlung: bei Ärger mit qmail auf Postfix
> umstellen. Weniger Systemlast, mehr Flexibilität, mehr Transparenz,
> robuster, und bei chroot auch mehr Sicherheit.
Den Teil mit "sicherer als noch nie ein exploit" möchtest Du der
staunenden Welt sicherlich noch erklären. Oder warum Postfix ein
genialer Ersatz für ein qmail setup mit vpopmail oder ezmlm ist.
Deine Liebe zu Postfix sei Dir unbenommen, aber Dein qmail-bashing
nervt, wenn Dir - wie hier - schlicht die Argumente ausgehen.
Robin S. Socha
> Tja, vieleicht muß es ja doch mal ein anderer MTA als qmail werden,
> zumal ich demnächst pop3s und imaps einrichten will/soll.
,----[ run ]
| #!/bin/sh
|
| PATH="/usr/sbin/:/usr/local/sbin:/home/vpopmail/bin:/var/qmail/bin:/usr/local/bin:$PATH"
| export PATH
| exec tcpserver -R -v -c 50 0 995 \
| stunnel -f \
| -p /etc/ssl/stunnel.pem \
| -l qmail-popup -- qmail-popup \
| 209.70.202.39 \
| vchkpw \
| relay-ctrl-allow \
| qmail-pop3d Maildir 2>&1
`----
vpopmail und relay-ctrl sind ggfs. auszublenden. Und Courier IMAP ist
eine perfekte Ergänzung zu qmail. Matthias ist ein netter Junge und
hilft gerne und viel, aber er läßt sich allzu gerne von seiner Abneigung
gegen Dan Bernstein mitreißen. Ich sehe exakt *gar* keinen Grund, eine
laufende qmail Installation gegen Postfix auszutauschen. Gar keinen.
http://mail.socha.net/special/about
Franz Georg Köhler
>
> vpopmail und relay-ctrl sind ggfs. auszublenden. Und Courier IMAP ist
> eine perfekte Ergänzung zu qmail. Matthias ist ein netter Junge und
> hilft gerne und viel, aber er läßt sich allzu gerne von seiner Abneigung
> gegen Dan Bernstein mitreißen. Ich sehe exakt *gar* keinen Grund, eine
> laufende qmail Installation gegen Postfix auszutauschen. Gar keinen.
> http://mail.socha.net/special/about
Und was sagst du zu der Tatsache, daß qmail bei einem 4xx nicht einen
der Backup-MX bemüht (ich weiß, ist vermutlich ein Feature...)?
--
Warning: You are not root
-- nmap V. 2.54BETA31
Matthias Andree
> Ich habe das Problem erstmal im Griff, in dem ich smtproutes für
> die problematischen Domains gestezt habe. Längerfristig wäre mir
> latürnicht eine Lösung lieber, die allgemeingültigt ist.
Naja, fragen, ob sie die Verbindung nicht komplett mit RST abfackeln
können, und warum das problematisch ist, jetzt 459 zu sagen, kann ja
nicht schaden.
Wie gesagt: entweder qmail patchen (ob's was passendes gibt, weiß ich
nicht) oder besser gleich einen anderen MTA nehmen, der dann auch
bandbreiten- und festplattenfreundlicher ist. Ich bevorzuge Postfix.
Was IMAP etc. angeht: Courier-IMAP für POP3/IMAP aus Maildir, Cyrus,
wenn's was mit eigenem Spool sein darf.
--
Matthias Andree
Matthias Andree
Ich wiederhole die Argumente nicht en detail, weil sie jeder mit Google
nachlesen kann. Bezüglich EZMLM: siehe Bugtraq. Dort läuft letztlich nur
noch qmail-local, die Auslieferung in die Welt läuft über Postfix'
qmqpd(8), weil qmail unter Last verreckt ist.
--
Matthias Andree
Matthias Andree
> vpopmail und relay-ctrl sind ggfs. auszublenden. Und Courier IMAP ist
> eine perfekte Ergänzung zu qmail. Matthias ist ein netter Junge und
> hilft gerne und viel, aber er läßt sich allzu gerne von seiner Abneigung
> gegen Dan Bernstein mitreißen. Ich sehe exakt *gar* keinen Grund, eine
> laufende qmail Installation gegen Postfix auszutauschen. Gar keinen.
> http://mail.socha.net/special/about
Robin, gegen qmail sprechen *technische* Gründe, Bugs, Misfeatures,
nicht "qmails Vater ist ein Kotzbrocken".
Du solltest meine Mails und Postings nochmal genau lesen. Google hilft
Dir. MARC.theaimsgroup ebenfalls.
Und alle paar Monate kommt ein neuer (technischer) Grund dazu, der gegen
qmail spricht, hier: bei 4XX- oder 5XX-Begrüßung keinen Backup-MX zu
probieren. Ein anderer ist: Postfix kann auf sinnvolle Weise chroot
einrichten und benutzen, um die Sicherheit zu erhöhen.
Daß der Vater dieser Software DJB heißt, ist vielleicht insofern ein
Grund als man von dem keinen Support kriegt. Für meine Setups spricht
z. B. nichts gegen djbdns, obwohl das Zeug von DJB ist.
--
Matthias Andree
Robin S. Socha
> Und alle paar Monate kommt ein neuer (technischer) Grund dazu, der
> gegen qmail spricht, hier: bei 4XX- oder 5XX-Begrüßung keinen Backup-MX
> zu probieren.
Die Erklärung ist relativ einfach (und DJB-like):
qmail verbindet sich mit MX records in distance order. Wenn ein MX
unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
entry anzusprechen. Warum sollte es auch?
Franz Georg Köhler
Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja ein
temporäres Problem hat?
Robin S. Socha
> * quoting [Robin S. Socha <robin-dated-10...@socha.net>]
>> qmail verbindet sich mit MX records in distance order. Wenn ein MX
>> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
>> entry anzusprechen. Warum sollte es auch?
>
> Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja ein
> temporäres Problem hat?
Wenn der nicht wieder oben ist, bevor die queue-time um ist, hat die
domain ein ganz anderes Problem...
Matthias Andree
> Die Erklärung ist relativ einfach (und DJB-like):
Und sie ist a) falsch.
> qmail verbindet sich mit MX records in distance order. Wenn ein MX
> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
> entry anzusprechen. Warum sollte es auch?
Qmail sollte es, weil die von DJB hochgelobten (zumindest, solang's für
ihn opportun ist) RFCs es vorschreiben, und b) weil es sinnvoll ist.
a) qmail versucht, wenn es keinen connect zu der Kiste kriegt, durchaus
den nächsten MX, auch mit höherer PRI. qmail hängt auf dem MX fest,
wenn er den TCP-Handshake abschließt, aber dann nicht mit 220 grüßt.
Lies und versteh qmail-remote.c, Zeilen 411 bis 424 (1.03) und die
Funktion smtp(), Zeilen 219 ff.
Zwar müßte laut RFC-2821 die andere Kiste 554 schicken, wenn sie
keine Mail will (nur 220 und 554 sind erlaubt), aber qmail würde sich
bei 554 genauso auf die Fresse legen und immer wieder vor die
geschlossene Ladentür hämmern und Einlaß begehren, den es nie
bekommen kann.
Das ist ein Bug, ein logischer und ein Denkfehler, neudeutsch:
thinko.
Und, um das ganz klar zu sagen: qmail verhält sich RFC-2821-widrig:
"5. Address Resolution and Mail Handling
[...] When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. [...]"
Da steht "delivery attempt succeeds", nicht "connection attempt".
Und, um dem Argument "qmail ist älter als RFC-2821" zu begegnen:
RFC-974 hat dieses Verhalten bereits vorgesehen, und qmail versucht
es, macht es aber falsch.
Soviel zur Standardkonformität.
b) Wie oben bereits anhand RFC-2821 dargelegt: Backup MX sind dazu da,
die Aufgabe des Primary MX zu übernehmen, wenn der gerade nicht
kann. Die "distance entry" (eigentlich: Preference) sagen nur, in
welcher Reihenfolge man probieren soll. Sie sagen ausdrücklich nicht,
daß man nur diejenigen mit absoluter Priorität wählen und die anderen
ignorieren soll. qmail probiert nichtmals zwei.
Wenn die "REMOTE"-Domain die Mail nicht auf Backup-MX (solche mit
höherer Preference) haben wollte, würde sie die zugehörigen MX-RR
auch gar nicht eintragen.
--
Matthias Andree
Matthias Andree
> Wenn der nicht wieder oben ist, bevor die queue-time um ist, hat die
> domain ein ganz anderes Problem...
Nein, hat sie nicht, weil augenscheinlich jede andere Software korrekt
und RFC-2821-konform (bzw. für Historiker RFC-974) die Backup-MX benutzt
(wurde so berichtet als qmail-spezifisches Problem; Postfix leistet
definitiv).
Und wenn nun die Mail der qmail-Schwachmaten bounct, sie sich dann beim
postmaster beschweren, und dann zur Antwort kriegen "nur qmail rafft's
nicht", kriegen sie vielleicht einen Clue.
Wie Du anhand meines anderen Postings siehst: technischer Mangel, Norm
verletzt. Alle Schäden gehen zu eigenen Lasten.
--
Matthias Andree
Franz Georg Köhler
Mit dieser Einstellung sind Backup-MX generell sinnlos.
Franz Georg Köhler
Mit dieser Argumentation kann man jeden Backup-MX für sinnlos erklären.
Nils Ketelsen
>>> qmail verbindet sich mit MX records in distance order. Wenn ein MX
>>> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
>>> entry anzusprechen. Warum sollte es auch?
>> Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja ein
>> temporäres Problem hat?
> Wenn der nicht wieder oben ist, bevor die queue-time um ist, hat die
> domain ein ganz anderes Problem...
Es gibt durchaus Setups bei denen auch der secondary-MX in der Lage ist die
mail in das Postfach zuzustellen. Von daher würde mich interessieren:
Welches Problem hat die Domain denn so? Mails von qmail nicht zu bekommen
betrachte ich mehr als Feature.
Nils
--
Well... It all started with a typo in a safe sex pamphlet. By the time
I discovered I didn't really have to use a condor every time, I'd kind
of gotten used to them.
[bsvit...@mln.lib.ma.us in rec.arts.comics.dc.universe]
Gerrit Pape
> Rene' Kray <c...@pool.math.tu-berlin.de> writes:
>> Trying 130.149.11.8...
>> Connected to fb3-s7.math.TU-Berlin.DE.
>> Escape character is '^]'.
>> 421 gate.hhi.de Sorry, unable to contact destination SMTP daemon.
>> Connection closed by foreign host.
> DAS ist ein Problem. Qmail denkt sich: "später geht's ja wieder" und
> legt sich damit auf den Bart.
Die Antwort von 130.149.11.8 ist 421: 'temporarily rejects the connection',
4xx sind temporary errors, das entspricht "spaeter geht's ja wieder".
> Ungeschickt ist das (seitens der TU Berlin) auf jeden Fall, wenn das
> Problem nicht nur vorübergehender Natur ist.
Ja. Und den Sinn der Sache habe ich auch noch nicht verstanden.
>> beeinflussen, wie qmail reagiert, kann man das überhaupt? (ohne die
>> sourcen zu patchen)
> Ohne Patches geht bei qmail gar nichts.
Bei mir 'geht' ungepatchtes qmail seit Jahren als zuverlaessiger MTA.
> Das meiste Verhalten ist hart verdrahtet. So auch dieses.
Mittels smtproutes laesst sich das Verhalten aendern.
> Nach Lektüre von qmail-remote.c (aus qmail-1.03):
> qmail versucht grundsätzlich nur den ersten MX, zu dem es eine
> Verbindung bekommen kann. Wenn der sich mit Meldungen wie 421 oder so
> verabschiedet: bei qmail hast Du verloren. Auch aus anderen Gründen.
qmail probiert bei einem temporary error den gleichen Server spaeter
nochmal. Logisch. Hoer auf mit Deinem FUD.
> Insofern gilt meine Empfehlung: bei Ärger mit qmail auf Postfix
> umstellen. Weniger Systemlast, mehr Flexibilität, mehr Transparenz,
> robuster, und bei chroot auch mehr Sicherheit.
;-) ist der code jetzt schon so schlimm, dass Sicherheit nur noch mit chroot
gegeben ist...
> Postfix 1.1.10 kommt damit klar, sofern man nicht smtp_skip_4xx_greeting
> vom Default "yes" auf "no" geändert hat, Auszug aus
Hmm, stellt sich die Frage, warum es denn die Option smtp_skip_4xx_greeting
und die Moeglichkeit diese auf 'no' zu setzen ueberhaupt gibt.
Gerrit.
Gerrit Pape
> "Robin S. Socha" <robin-dated-10...@socha.net> writes:
>> http://mail.socha.net/special/about
> Robin, gegen qmail sprechen *technische* Gründe, Bugs, Misfeatures,
Bugs? Schon vergessen?:
http://groups.google.com/groups?selm=m3itfih82c.fsf%40emma1.emma.line.org
Misfeatures? Sonst beschwert er sich, qmail haette nicht genug Features.
Gerrit.
Gerrit Pape
> * quoting [Robin S. Socha <robin-dated-10...@socha.net>]
>> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
>> entry anzusprechen. Warum sollte es auch?
> Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja ein
> temporäres Problem hat?
Das loest nicht das temporaere Problem des shortest distance MX.
Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
temporaere Problem beseitigt ist.
Gerrit.
Gerrit Pape
Nein, 'Backup-MX'er werden kontaktiert, wenn keine Netzwerkverbindung zu
dem hoeher priorisierten MX moeglich ist.
Gerrit.
Gerrit Pape
Nein, 'Backup-MX'er werden kontaktiert, wenn keine Netzwerkverbindung zum
Gerrit Pape
> Ich wiederhole die Argumente nicht en detail, weil sie jeder mit Google
> nachlesen kann. Bezüglich EZMLM: siehe Bugtraq. Dort läuft letztlich nur
> noch qmail-local, die Auslieferung in die Welt läuft über Postfix'
> qmqpd(8), weil qmail unter Last verreckt ist.
Oh, auf einmal hast Du die Weisheit gefressen, und kennst die genauen
Gruende, warum bugtraq umgestellt wurde..
Gerrit.
Robin S. Socha
> Robin S. Socha <robin-dated-10...@socha.net> wrote:
>>>> qmail verbindet sich mit MX records in distance order. Wenn ein
>>>> MX unerreichbar ist, versucht qmail nicht, einen MX mit höherem
>>>> distance entry anzusprechen. Warum sollte es auch?
>>> Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja
>>> ein temporäres Problem hat?
>> Wenn der nicht wieder oben ist, bevor die queue-time um ist, hat die
>> domain ein ganz anderes Problem...
>
> Es gibt durchaus Setups bei denen auch der secondary-MX in der Lage
> ist die mail in das Postfach zuzustellen. Von daher würde mich
> interessieren: Welches Problem hat die Domain denn so?
Einen Admin, der ein temporäres Problem nicht innerhalb einer Woche
(default queuelifetime) löst. Für einen MX wohl kaum akzeptabel.
> Mails von qmail nicht zu bekommen betrachte ich mehr als Feature.
Das hatte ich von einem Mitglied Deiner Domain auch nicht anders
erwartet... ;-)
Nils Ketelsen
> Das loest nicht das temporaere Problem des shortest distance MX.
> Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
> temporaere Problem beseitigt ist.
Muss sie garnicht. Muß sie in Deinen Setups vielleicht, aber deswegen noch
lange nicht in allen.
Die Domain ist vielleicht auch beim Backup-MX local und der stellt sie auf
dem gemeinsam Storage zu. Oder aber sie ist bei keinem von beiden local,
aber beide wissen wohin sie die (z.B. innerhalb eines privaten Netzes)
forwarden muessen.
Es gibt durchaus Setups, wo mails auch bei einem Totalausfall des lowest MX
noch ankommen. Das liegt daran, daß E-Mail in einigen Unternehmen als
Geschäftskrtisch betrachtet wird. Da gibt man sich dann etwas mehr Mühe mit
dem Setup.
Nils
--
- Proponenten führen sich (z.T.) auf, wie die Borg nach einer Nacht in
Schlumpfhausen.
[Kai Bojens in de.alt.admin .. Letzter Punkt zur Erklärung seines Protestes]
Matthias Andree
Die wurden veröffentlicht, wo ist das Problem?
--
Matthias Andree
Matthias Andree
> Das loest nicht das temporaere Problem des shortest distance MX.
> Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
> temporaere Problem beseitigt ist.
Nein, qmail muß an denjenigen MX mit niedrigstem Preference-Wert
ausliefern, der die Mail erfolgreich abnimmt. Siehe RFC-2821, Kapitel 6.
qmail unterläuft das Prinzip der Backup-MX und beeinträchtigt damit die
Mailzustellung.
Ausdrücklich muß es auch diejenigen probieren, die nicht den absolut
niedrigsten Preference-Wert im MXRR haben. Wenn die alle die Mailabnahme
verweigern, muß es die nächsthöheren versuchen.
--
Matthias Andree
Matthias Andree
Matthias Andree
> Matthias Andree <matthia...@gmx.de> wrote:
>> Rene' Kray <c...@pool.math.tu-berlin.de> writes:
>>> Trying 130.149.11.8...
>>> Connected to fb3-s7.math.TU-Berlin.DE.
>>> Escape character is '^]'.
>>> 421 gate.hhi.de Sorry, unable to contact destination SMTP daemon.
>>> Connection closed by foreign host.
>
>> DAS ist ein Problem. Qmail denkt sich: "später geht's ja wieder" und
>> legt sich damit auf den Bart.
>
> Die Antwort von 130.149.11.8 ist 421: 'temporarily rejects the connection',
> 4xx sind temporary errors, das entspricht "spaeter geht's ja wieder".
421 heißt "Service shutting down and closing transmission channel"
(RFC-2821). Damit ist die Mailzustellung an diesen MX gescheitert und
muß beim nächsten MX mit derselben "Preference", oder, wenn die alle
versucht wurden, bei einem MX mit der nächsthöheren "Preference" neu
versucht werden.
5XX wäre noch ungeschickter, weil einige Kisten (Exim 3.3X, Exim 4.0X,
ältere Postfix) dann die Mail direkt bouncten.
>> Das meiste Verhalten ist hart verdrahtet. So auch dieses.
>
> Mittels smtproutes laesst sich das Verhalten aendern.
Nein, die RFC-2821-Widrigkeiten kann man nicht wegkonfigurieren. Man
bräuchte ein "Wenn ein MX 421 sagt, probier' den nächsten".
>> Nach Lektüre von qmail-remote.c (aus qmail-1.03):
>> qmail versucht grundsätzlich nur den ersten MX, zu dem es eine
>> Verbindung bekommen kann. Wenn der sich mit Meldungen wie 421 oder so
>> verabschiedet: bei qmail hast Du verloren. Auch aus anderen Gründen.
>
> qmail probiert bei einem temporary error den gleichen Server spaeter
> nochmal. Logisch. Hoer auf mit Deinem FUD.
Warum? Es gibt Backup-MX, die die Mail zur gegebenen Zeit annehmen
können, qmail versucht das nicht und verstößt damit gegen RFC-2821,
Abschnitt 6. Andere Kisten (Um sie mal zu nennen: Postfix, Exim,
Sendmail) gegen mit diesem 421 richtig um.
Und: qmail probiert bei einem permanent error (554) denselben Server
ebenfalls nochmal statt zu bouncen oder die anderen MX zu versuchen, und
das ist sicher ein Bug.
*Ungetesteter* Patch, wie man es RFC-2821 konform hinbiegen könnte. Man
könnte darüber diskutieren, ob man nach dem neuen code = smtpcode()
und vor dem if (code >= 400) noch eine Zeile
if (code >= 500 && code < 600) quit("DConnected to "," but service was refused");
einfügt, um das aus Exim 3.3X/4.0X bekannte Verhalten einzustellen und
einen Bounce zu erzwingen.
--- qmail-remote.c.orig Wed May 22 12:41:20 2002
+++ qmail-remote.c Wed May 22 13:00:36 2002
@@ -222,7 +222,9 @@
int flagbother;
int i;
- if (smtpcode() != 220) quit("ZConnected to "," but greeting failed");
+ code = smtpcode();
+ if (code >= 400 && code < 600) return; /* try next MX, see RFC-2821 */
+ if (code != 220) quit("ZConnected to "," but greeting failed");
substdio_puts(&smtpto,"HELO ");
substdio_put(&smtpto,helohost.s,helohost.len);
@@ -417,7 +419,9 @@
if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) port,timeoutconnect) == 0) {
tcpto_err(&ip.ix[i].ip,0);
partner = ip.ix[i].ip;
- smtp(); /* does not return */
+ smtp(); /* only returns when the next MX is to be tried */
+ close(smtpfd);
+ continue;
}
tcpto_err(&ip.ix[i].ip,errno == error_timeout);
close(smtpfd);
>> Postfix 1.1.10 kommt damit klar, sofern man nicht smtp_skip_4xx_greeting
>> vom Default "yes" auf "no" geändert hat, Auszug aus
>
> Hmm, stellt sich die Frage, warum es denn die Option smtp_skip_4xx_greeting
> und die Moeglichkeit diese auf 'no' zu setzen ueberhaupt gibt.
Wegen RFC-2821, und um der Austauschbarkeit willen. Stellt sich auch
die Frage, warum qmail so eine Option nicht hat.
Postfix' HISTORY beantwortet die Frage:
20000506
[...]
Sendmail compatibility: the Postfix SMTP client now skips
servers that greet the client with a 4xx or 5xx status
code. To disable, set both smtp_skip_4xx_greeting and
smtp_skip_5xx_greeting to "no".
Die Konfiguration dokumentiert:
# The smtp_skip_4xx_greeting parameter controls what happens when
# an SMTP server greets us with a 4XX status code (go away, try
# again later).
#
# By default, Postfix moves on the the next mail exchanger. Specify
# "smtp_skip_4xx_greeting = no" if Postfix should defer delivery
# immediately.
#
smtp_skip_4xx_greeting = yes
In der Mailingliste wurde eben das Problem berichtet, daß einige Server
über längere Zeit mit 4XX grüßten.
--
Matthias Andree
Robin S. Socha
> Nein, qmail muß an denjenigen MX mit niedrigstem Preference-Wert
> ausliefern, der die Mail erfolgreich abnimmt.
Das ist Deine Exegese. Meine sagt, dass "successful delivery attempt"
durchaus heißen kann: "vorbeigeschaut, Tür vor die Nase bekommen -
versuche es später noch einmal."
Matthias Andree
> * Nils Ketelsen <ni...@strg-alt-entf.org> writes:
>> Es gibt durchaus Setups bei denen auch der secondary-MX in der Lage
>> ist die mail in das Postfach zuzustellen. Von daher würde mich
>> interessieren: Welches Problem hat die Domain denn so?
>
> Einen Admin, der ein temporäres Problem nicht innerhalb einer Woche
> (default queuelifetime) löst. Für einen MX wohl kaum akzeptabel.
"4 bis 5 Tage". (RFC 2821)
>> Mails von qmail nicht zu bekommen betrachte ich mehr als Feature.
>
> Das hatte ich von einem Mitglied Deiner Domain auch nicht anders
> erwartet... ;-)
Kann ich aber nachvollziehen, wenn die Kiste zu blöd ist, auf den
Backup-MX auszuweichen... ;-)
--
Matthias Andree
Gerrit Pape
RFC2821, darauf verweist Du doch die ganze Zeit.
Gerrit.
Gerrit Pape
>> * Nils Ketelsen <ni...@strg-alt-entf.org> writes:
>>> Es gibt durchaus Setups bei denen auch der secondary-MX in der Lage
>>> ist die mail in das Postfach zuzustellen. Von daher würde mich
>>> interessieren: Welches Problem hat die Domain denn so?
>>
>> Einen Admin, der ein temporäres Problem nicht innerhalb einer Woche
>> (default queuelifetime) löst. Für einen MX wohl kaum akzeptabel.
> "4 bis 5 Tage". (RFC 2821)
Ach. Demnach ist also der genannte Server der TU Berlin nicht RFC konform.
Er gibt bestimmten Servern permanent einen temporary error code zurueck.
Gerrit.
Gerrit Pape
>> Das loest nicht das temporaere Problem des shortest distance MX.
>> Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
>> temporaere Problem beseitigt ist.
> Nein, qmail muß an denjenigen MX mit niedrigstem Preference-Wert
> ausliefern, der die Mail erfolgreich abnimmt. Siehe RFC-2821, Kapitel 6.
Du meinst Kapitel 5?
---
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.
---
Wenn Du das meinst, bin ich nicht einer Meinung mit Deiner obigen
Interpretation. Das steht hier nicht.
Gerrit.
Gerrit Pape
>> Das loest nicht das temporaere Problem des shortest distance MX.
>> Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
>> temporaere Problem beseitigt ist.
> Muss sie garnicht. Muß sie in Deinen Setups vielleicht, aber deswegen noch
> lange nicht in allen.
> Die Domain ist vielleicht auch beim Backup-MX local und der stellt sie auf
> dem gemeinsam Storage zu. Oder aber sie ist bei keinem von beiden local,
> aber beide wissen wohin sie die (z.B. innerhalb eines privaten Netzes)
> forwarden muessen.
Dafuer sind andere Moeglichkeiten vorgesehen: mehrere MXer mit gleicher
distance oder multihomed hosts.
> Es gibt durchaus Setups, wo mails auch bei einem Totalausfall des lowest MX
> noch ankommen. Das liegt daran, daß E-Mail in einigen Unternehmen als
> Geschäftskrtisch betrachtet wird. Da gibt man sich dann etwas mehr Mühe mit
> dem Setup.
Ich nehme das mal als Witz.
Gerrit.
Gerrit Pape
> Gerrit Pape <pa...@innominate.com> writes:
>> Matthias Andree <matthia...@gmx.de> wrote:
>>> DAS ist ein Problem. Qmail denkt sich: "später geht's ja wieder" und
>>> legt sich damit auf den Bart.
>>
>> Die Antwort von 130.149.11.8 ist 421: 'temporarily rejects the connection',
>> 4xx sind temporary errors, das entspricht "spaeter geht's ja wieder".
> 421 heißt "Service shutting down and closing transmission channel"
> (RFC-2821). Damit ist die Mailzustellung an diesen MX gescheitert und
> muß beim nächsten MX mit derselben "Preference", oder, wenn die alle
> versucht wurden, bei einem MX mit der nächsthöheren "Preference" neu
> versucht werden.
Nein:
RFC2821, 4.2.1:
---
4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not
occur. However, the error condition is temporary and the action
may be requested again. The sender should return to the beginning
of the command sequence (if any). It is difficult to assign a
meaning to "transient" when two different sites (receiver- and
[...]
---
>>> Das meiste Verhalten ist hart verdrahtet. So auch dieses.
>> Mittels smtproutes laesst sich das Verhalten aendern.
> Nein, die RFC-2821-Widrigkeiten kann man nicht wegkonfigurieren. Man
> bräuchte ein "Wenn ein MX 421 sagt, probier' den nächsten".
Das ist eigens Deine Interpretation.
>>> Postfix 1.1.10 kommt damit klar, sofern man nicht smtp_skip_4xx_greeting
>>> vom Default "yes" auf "no" geändert hat, Auszug aus
>>
>> Hmm, stellt sich die Frage, warum es denn die Option smtp_skip_4xx_greeting
>> und die Moeglichkeit diese auf 'no' zu setzen ueberhaupt gibt.
> Wegen RFC-2821, und um der Austauschbarkeit willen. Stellt sich auch
Wegen RFC2821?, davon steht da unten nichts.
> Postfix' HISTORY beantwortet die Frage:
> 20000506
> [...]
> Sendmail compatibility: the Postfix SMTP client now skips
> servers that greet the client with a 4xx or 5xx status
> code. To disable, set both smtp_skip_4xx_greeting and
> smtp_skip_5xx_greeting to "no".
> Die Konfiguration dokumentiert:
> # The smtp_skip_4xx_greeting parameter controls what happens when
> # an SMTP server greets us with a 4XX status code (go away, try
> # again later).
> #
> # By default, Postfix moves on the the next mail exchanger. Specify
> # "smtp_skip_4xx_greeting = no" if Postfix should defer delivery
> # immediately.
> #
> smtp_skip_4xx_greeting = yes
Gerrit.
Nils Ketelsen
>> Die Domain ist vielleicht auch beim Backup-MX local und der stellt sie auf
>> dem gemeinsam Storage zu. Oder aber sie ist bei keinem von beiden local,
>> aber beide wissen wohin sie die (z.B. innerhalb eines privaten Netzes)
>> forwarden muessen.
>
> Dafuer sind andere Moeglichkeiten vorgesehen: mehrere MXer mit gleicher
> distance oder multihomed hosts.
So'n Quark. Nur das er es kann heißt ja nicht, daß er es auch im
"normalbetrieb" soll. Er soll die Mails nur annehmen, wenn der andere
Ausfällt. Aber dann soll er sie auch ordentlich zustellen.
>> Es gibt durchaus Setups, wo mails auch bei einem Totalausfall des lowest MX
>> noch ankommen. Das liegt daran, daß E-Mail in einigen Unternehmen als
>> Geschäftskrtisch betrachtet wird. Da gibt man sich dann etwas mehr Mühe mit
>> dem Setup.
> Ich nehme das mal als Witz.
Dann lach doch.
Nils
--
*SAMMELT OBSTKERNE!*
Ralph Angenendt
>>> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
>>> entry anzusprechen. Warum sollte es auch?
>>
>> Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja ein
>> temporäres Problem hat?
>
> Wenn der nicht wieder oben ist, bevor die queue-time um ist, hat die
So ein Blödfug. Das würde das Konzept Backup-MX völlig aushebeln. Warum
sollte ich versuchen, eine Mail 1000x zuzustellen, wenn es einen Rechner
gibt, der im Falle eines Fehlers des am höchsten priorisierten MX die Mail
entgegennimmt und dann nach eigenen Regeln (z.B 10 Tage versuchen anstelle
von defaultmässig 5) versucht, die Mail zuzustellen?
Das entlastet gerade bei Domains mit vielen Usern z.B. Listserver, die
versuchen in die gerade nicht erreichbare Domain zuzustellen.
Wen qmail bei einem nicht erreichbaren Server nicht versucht, an den nächst
niedrig/hoch priorisierten MX zuzustellen, wenn dieser vorhanden ist, dann
ist diese Software kaputt. Warum sollte ich als Absender x-Mal versuchen
Mails zuzustellen, wenn das auch ein vom Empfänger empfohlener Mailserver
machen kann?
Hrmpf.
Ralph
Matthias Andree
"Tür vor die Nase" ist sicher kein "Successful Delivery Attempt" -- der
liegt nur dann vor, wenn man nach EHLO/MAIL FROM/RCPT TO/DATA
abschließend 250 bekommen hat.
Wohin Deine Interpretation führt, ist ja bereits dokumentiert: qmail
wird die Mail par tout nicht los und wirft sie nach einer Woche aus der
Queue.
Aber daß von DJB-Fans Bugs in seiner Software geleugnet werden, ist ja
nichts neues.
--
Matthias Andree
Matthias Andree
Nein, das steht da genau nicht, das ergibt sich implizit daraus, daß
ohne Verbindung eben kein "delivery attempt" erfolgreich abgeschlossen
werden kann. RFC-2821 verlangt auch, wenn z. B. die Kiste mitten in DATA
verreckt und "den Hörer auflegt", daß man den nächsten von der
geordneten Liste wählt. Mit selber Preference oder, wenn's davon keinen
mehr gibt, mit der nächsthöheren.
Da steht (Abschnitt "5. Address Resolution and Mail Handling"):
"To provide reliable mail transmission, the SMTP client MUST be able
to try (and retry) each of the relevant addresses in this list [die
Liste aller Mailexchanger nach MX-Lookup, einschließlich ihrer
evtl. mehrfachen IP je Adresse] in order, until a delivery attempt
succeeds."
Da steht ausdrücklich "delivery attempt" (letztlich eine komplette
SMTP-Session mit Mailtransaktion), NICHT connection.
Wie gesagt, RFC-821/974/1123 verlangen ähnliches -- 1123 wegen der
Abschaffung der "WKS" (well known service)-Lookups.
--
Matthias Andree
Matthias Andree
Innerhalb dieser 4 bis 5 Tage sollte wenigstens die Zustellung seitens
des Clients neu versucht werden.
Da aber -- wie berichtet -- die anderen MX für die fragliche Domain die
Mail abnehmen, hat qmail den schwarzen Peter.
--
Matthias Andree
Matthias Andree
Qmail hat kein konfigurierbares Limit für die Adreßliste. Ich sehe auch
nicht, daß es die beschneidet, den DNS-Client hab' ich mir dabei nicht
angesehen. Ich vermute, daß außer der DNS-immanenten "512 Byte für UDP"
keine weitere Beschränkung vorliegt. Damit fällt der Teil ab "However"
schonmal weg.
Bleiben die Verpflichtungen:
1. die MX mit der geringsten Preference zu probieren
2. wenn die nicht wollen, die Liste (nach Preference sortiert) weiter
"abzugrasen", bis die Mail zugestellt ist.
Daraus ergibt sich automatisch, daß die Mail bei demjenigen (oder einem
von denjenigen) MX landet, der die niedrigste "Preference" hat und die
Mail abnimmt. Einer mit niedrigerer Preference hat die Mail bereits
abgelehnt, einen mit höherer Preference darfst Du nicht versuchen, wenn
einer mit niedrigerer die Mail abnimmt.
--
Matthias Andree
Matthias Andree
>> Die Domain ist vielleicht auch beim Backup-MX local und der stellt sie auf
>> dem gemeinsam Storage zu. Oder aber sie ist bei keinem von beiden local,
>> aber beide wissen wohin sie die (z.B. innerhalb eines privaten Netzes)
>> forwarden muessen.
>
> Dafuer sind andere Moeglichkeiten vorgesehen: mehrere MXer mit gleicher
> distance oder multihomed hosts.
Sprich doch bitte von "preference value" (RFC-1034), nicht von
"distance".
Auch Deine "Vorsehung" ändert nichts am kaputten qmail-Verhalten.
>> Es gibt durchaus Setups, wo mails auch bei einem Totalausfall des lowest MX
>> noch ankommen. Das liegt daran, daß E-Mail in einigen Unternehmen als
>> Geschäftskrtisch betrachtet wird. Da gibt man sich dann etwas mehr Mühe mit
>> dem Setup.
>
> Ich nehme das mal als Witz.
Durchaus nicht.
--
Matthias Andree
Matthias Andree
>> Nein, die RFC-2821-Widrigkeiten kann man nicht wegkonfigurieren. Man
>> bräuchte ein "Wenn ein MX 421 sagt, probier' den nächsten".
>
> Das ist eigens Deine Interpretation.
Durchaus nicht, aber mir ist auch klar, daß für Leute, die qmail
einsetzen, qmail allein schon deswegen keine Bugs hat, weil sie ohnehin
nicht behoben würden, wenn es welche hätte: und dann stünde die
Entscheidung für qmail auf wackligeren Füßen.
--
Matthias Andree
Stefan Paletta
> Wen qmail bei einem nicht erreichbaren Server nicht versucht, an den nächst
> niedrig/hoch priorisierten MX zuzustellen, wenn dieser vorhanden ist, dann
> ist diese Software kaputt. Warum sollte ich als Absender x-Mal versuchen
> Mails zuzustellen, wenn das auch ein vom Empfänger empfohlener Mailserver
> machen kann?
qmail versucht bei einem nicht erreichbaren MX den naechsten besten.
Diese Tatsache ist unbestritten.
Stefan
Florian Weimer
> qmail versucht bei einem nicht erreichbaren MX den naechsten besten.
> Diese Tatsache ist unbestritten.
Der RFC legt nahe, sich nicht nach der Erreichbarkeit zu richten.
Sebastian Niehaus
> qmail versucht bei einem nicht erreichbaren MX den naechsten besten.
> Diese Tatsache ist unbestritten.
So pauschal, wie Du sie in den Raum stellst, ist sie schlichtweg
falsch.
Und morgen darfst Du "nicht erreichbar" definieren.
Stefan Paletta
>> qmail versucht bei einem nicht erreichbaren MX den naechsten besten.
>> Diese Tatsache ist unbestritten.
>
> So pauschal, wie Du sie in den Raum stellst, ist sie schlichtweg
> falsch.
>
> Und morgen darfst Du "nicht erreichbar" definieren.
Definiere fuer mich mal 'nicht erreichbar' so, dass meine Aussage
falsch ist. Sinnvoll bitte.
Stefan
Matthias Andree
> Stefan Paletta <ste...@world.wronline.de> writes:
>
>> qmail versucht bei einem nicht erreichbaren MX den naechsten besten.
>> Diese Tatsache ist unbestritten.
>
> So pauschal, wie Du sie in den Raum stellst, ist sie schlichtweg
> falsch.
So für sich gesehen, ist die Aussage schon richtig, modulo DNS-Oversized
Records und "unvollständige DNS-Antworten nicht berücksichtigen" und so
fort.
Nur, daß "bei einem nicht erreichbaren" eben nicht genügt.
--
Matthias Andree
Florian Weimer
Die Aussage ist richtet, dieses Verhalten ist aber nicht hinreichend
für korrekte Operation.
Gerrit Pape
> Gerrit Pape <pa...@innominate.com> writes:
>> Matthias Andree <matthia...@gmx.de> wrote:
>>> Gerrit Pape <pa...@innominate.com> writes:
>>>> Nein, 'Backup-MX'er werden kontaktiert, wenn keine Netzwerkverbindung zum
>>>> hoeher priorisierten MX moeglich ist.
>>> Wo steht, daß man das so machen soll?
>> RFC2821, darauf verweist Du doch die ganze Zeit.
> Nein, das steht da genau nicht, das ergibt sich implizit daraus, daß
> ohne Verbindung eben kein "delivery attempt" erfolgreich abgeschlossen
> werden kann.
Huh, also steht es da doch.
> RFC-2821 verlangt auch, wenn z. B. die Kiste mitten in DATA
> verreckt und "den Hörer auflegt", daß man den nächsten von der
Wohl mit 421.
> geordneten Liste wählt. Mit selber Preference oder, wenn's davon keinen
> mehr gibt, mit der nächsthöheren.
Das widerspricht Abschnitt 4.2.1:
---
4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not
occur. However, the error condition is temporary and the action
may be requested again. The sender should return to the beginning
of the command sequence (if any). It is difficult to assign a
meaning to "transient" when two different sites (receiver- and
sender-SMTP agents) must agree on the interpretation. Each reply
in this category might have a different time value, but the SMTP
client is encouraged to try again. A rule of thumb to determine
whether a reply fits into the 4yz or the 5yz category (see below)
is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)
---
Gerrit.
Gerrit Pape
FUD.
'Mir ist klar, dass fuer bestimmte Leute, die eine Aversion gegen qmail
entwickelt haben, qmail allein schon deswegen Bugs hat, weil es einfach
qmail ist.'
Mir ist nicht klar, warum Leute, die kein qmail einsetzen, bei dem Thema
ueberhaupt mitreden.
http://groups.google.com/groups?selm=9phpu1%24mf7%241%40bolzen.all.de
Gerrit.
Juergen Ilse
Robin S. Socha <robin-dated-10...@socha.net> wrote:
> Die Erklärung ist relativ einfach (und DJB-like):
... was nicht immer eine Empfehlung fuer die Software bedeutet ...
> qmail verbindet sich mit MX records in distance order. Wenn ein MX
> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
> entry anzusprechen. Warum sollte es auch?
Weil es sonst das Konzept der "Backup-MX-Records" zumindest teilweise
ad absurdum fuehrt. Ein Backup-Mailserver dient dazu, die Mail entge-
genzunehmen und temporaer zwischenzuspeichern, bis der primaere Server
wieder erreichbar ist. Weigert sich ein einliefernder Server den
Backup-Server zu verwenden, wenn der primary einen temporaeren Fehler
meldet, wird dieses Konzept schlicht torpediert ...
Anders saehe es aus, wenn der primary Server eine 5xx Fehlernummer
liefert (also ein permanenter Fehler vorliegt): In diesem Fall ist
es (bei richtiger Konfiguration des Zielservers) tatsaechlich sinnlos
einen weiteren Auslieferungsversuch zu starten (AFAIK startet aber
qmail weitere Auslieferungsversuche, vermeidet aber die Verbindung
zum Backup-Server wenn der primaere TCP-maessig erreichbar ist, oder
sollte ich mich in diesem Punkt irren?).
Irgendwie sieht das Ergebnis bei qmail fast so aus wie "das schlech-
teste Verhalten aus allen Welten" ...
Tschuess,
Juergen Ilse (il...@usenet-verwaltung.org)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Juergen Ilse
Wenn man unter nicht erreichbar auch "momentan nicht in der Lage die Mail
anzunehmen, obwohl tcp-maessig noch erriechbar" faellt, ist diese Aussage
nicht ganz so unbestritten ... Ein Mailserver, der bei einem temporaeren
Fehler im SMTP-Protokoll (4xx Fehlernummer) nicht als naechstes versucht,
an einen Backup-MX zuzustellen, ist mindestens fragwuerdig, ich kann aber
auch verstehen, wenn dieser Mailserver als kaputt bezeichnet wird ...
Genau dieses Verhalten von qmail wurde doch in diesem Thread kritisiert
oder habe ich da etwas uebersehen?
Juergen Ilse
Gerrit Pape <pa...@innominate.com> wrote:
> Nils Ketelsen <ni...@strg-alt-entf.org> wrote:
>> Gerrit Pape <pa...@innominate.com> wrote:
>>> Das loest nicht das temporaere Problem des shortest distance MX.
>>> Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
>>> temporaere Problem beseitigt ist.
>> Muss sie garnicht. Muß sie in Deinen Setups vielleicht, aber deswegen noch
>> lange nicht in allen.
>> Die Domain ist vielleicht auch beim Backup-MX local und der stellt sie auf
>> dem gemeinsam Storage zu. Oder aber sie ist bei keinem von beiden local,
>> aber beide wissen wohin sie die (z.B. innerhalb eines privaten Netzes)
>> forwarden muessen.
> Dafuer sind andere Moeglichkeiten vorgesehen: mehrere MXer mit gleicher
> distance oder multihomed hosts.
Vorgesehen ist, was im RFC steht. Das Verhalten von qmail widerspricht
dem in mindestens einer Hinsicht. Ausserdem steht dir in keiner Weise zu,
ein laut RFC zulaessiges Setup als "ist aber anders vorgesehen" fuer
nicht sinnvoll zu erklaeren, solange du nicht alle Begleitumstaende
beim Empfaenger kennst (und normalerweise kennst du die nicht).
Juergen Ilse
Gerrit Pape <pa...@innominate.com> wrote:
> Franz Georg Köhler <fgko...@gigabell.de> wrote:
>> * quoting [Robin S. Socha <robin-dated-10...@socha.net>]
>>> qmail verbindet sich mit MX records in distance order. Wenn ein MX
>>> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
>>> entry anzusprechen. Warum sollte es auch?
>> Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja ein
>> temporäres Problem hat?
> Das loest nicht das temporaere Problem des shortest distance MX.
> Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
> temporaere Problem beseitigt ist.
Die Auslieferung an den Host hat (laut RFC2881, wie schon mehrfach
zitiert wurde) ggfs. ein Backup zu uebernehmen, falls der primary
MX die Mail-Transaktion nicht vollstaendig abschliessen kann (warum
auch immer). Dazu iost der Backup da. Wenn der Backup von qmail nur
in einem Bruchteil der Faelle so verwendet wird, ist qmail in dieser
Hinsicht nicht RFC-konform (um die noch weniger schmeichelhafte
Bezeichnung "kaputt" zu vermeiden). Dabei ist es voellig zweitrangig,
ob du, Robin socha oder DJB das fuer sinnvoll haelt oder nicht, es
ist so im RFC festgeschrieben und damit der einzuhaltende Standard.
Aber anscheinend hat DJB ja sowieso einige teils etwas eigentuemliche
Ansichten ueber die Einhaltung von Standards und Vorschriften. Da
vermutlich sogar bei der Reservierung von .to Domains normalerweise
2 DNS-Server angegeben werden muessen, er aber nur einen fuer noetig
haelt, hat er zwei NS-Records mit unterschiedlichen Namen und der
selben zugehoerigen IP-Adresse angegeben ... Auch eine Meoglichkeit,
Vorschriften zu unterlaufen (wer das nicht glaubt, moege sich bitte
die zustaendigen NS-Records fuer DJBs Domain "yp.to" heraussuchen).
Juergen Ilse
Gerrit Pape <pa...@innominate.com> wrote:
> Franz Georg Köhler <fgko...@gigabell.de> wrote:
>> Mit dieser Argumentation kann man jeden Backup-MX für sinnlos erklären.
> Nein, 'Backup-MX'er werden kontaktiert, wenn keine Netzwerkverbindung zum
> hoeher priorisierten MX moeglich ist.
Wenn du nun statt "Netzwerkverbindung" "Mailannahme" schreibst, wuerde
ich sogar zustimmen. Der Backup soll fuer den Primary einspringen, wenn
dieser die Mail (aus welchen Gruenden auch immer) nicht annehmen kann.
Fehlende Netzwerkverbindung ist nur ein moegliches Problem von vielen.
Juergen Ilse
Gerrit Pape <pa...@innominate.com> wrote:
> Matthias Andree <matthia...@gmx.de> wrote:
>> Rene' Kray <c...@pool.math.tu-berlin.de> writes:
>>> Trying 130.149.11.8...
>>> Connected to fb3-s7.math.TU-Berlin.DE.
>>> Escape character is '^]'.
>>> 421 gate.hhi.de Sorry, unable to contact destination SMTP daemon.
>>> Connection closed by foreign host.
>> DAS ist ein Problem. Qmail denkt sich: "später geht's ja wieder" und
>> legt sich damit auf den Bart.
> Die Antwort von 130.149.11.8 ist 421: 'temporarily rejects the connection',
> 4xx sind temporary errors, das entspricht "spaeter geht's ja wieder".
Nein, das heisst "spaeter geht es moeglicherweise wieder". Vielleicht
geht die Zustellung an den primary MX (auch welchen Gruenden auch immer)
durch densecondary auch jetzt schon (es koennten z.B. DNS-Probleme eine
Rolle spielen, die beim secondary nicht auftreten, weil der auch ohne
DNS-Serverzugriff aufgeloest werden kann, ueber /etc/hosts oder evt.
auch ueber NIS oder NIS+ oder ...). Bei dem Verhalten von qmail wuerde,
selbst wenn das "temporaere Problem" innerhalb weniger Tage beseitigt
wird, die Mails in diesem Fall deutlich verzoegert, unnoetigerweise
(und RFC-widrig)!
>> Ungeschickt ist das (seitens der TU Berlin) auf jeden Fall, wenn das
>> Problem nicht nur vorübergehender Natur ist.
> Ja. Und den Sinn der Sache habe ich auch noch nicht verstanden.
Die Argumentation bezieht sich nicht nur auf dieses (IMHO eher etwas
eigenartige) Setup, sondern auch auf Faelle, wo es sich wirklich um
ein temporaeres Problem handelt.
>> Nach Lektüre von qmail-remote.c (aus qmail-1.03):
>> qmail versucht grundsätzlich nur den ersten MX, zu dem es eine
>> Verbindung bekommen kann. Wenn der sich mit Meldungen wie 421 oder so
>> verabschiedet: bei qmail hast Du verloren. Auch aus anderen Gründen.
> qmail probiert bei einem temporary error den gleichen Server spaeter
> nochmal. Logisch. Hoer auf mit Deinem FUD.
Auch ein temporaerer Fehler ist ein Fehler bei der Mailtransaktion.
Kann eine Mailtransaktion nicht erfolgreich abgeschlossen werden,
sollen laut RFC auch die Backup-MXe in die Zustellversuche einbezogen
werden (mindestens zwei, so es denn so viele gibt). qmail tut das
nicht. Tatsache oder FUD?
>> Postfix 1.1.10 kommt damit klar, sofern man nicht smtp_skip_4xx_greeting
>> vom Default "yes" auf "no" geändert hat, Auszug aus
> Hmm, stellt sich die Frage, warum es denn die Option smtp_skip_4xx_greeting
> und die Moeglichkeit diese auf 'no' zu setzen ueberhaupt gibt.
Nicht jede Konfigurationsmoeglichkeit in jeder Software muss unbedingt
sinnvoll sein (und es gibt auch keine Pflicht, Software so zu gestalten,
dass RFC-widrige Setups unmoeglich werden). Trotzdem sollte man eine
RFC-konforme Konfiguration einer RFC-widrigen vorziehen.
Matthias Andree
> FUD.
> 'Mir ist klar, dass fuer bestimmte Leute, die eine Aversion gegen qmail
> entwickelt haben, qmail allein schon deswegen Bugs hat, weil es einfach
> qmail ist.'
Komisch nur, daß die Bugs belegt werden, in der weiten Welt zu real
existierenden Problemen geführt haben (siehe Ursprung dieser Diskussion)
und trotzdem geleugnet werden. Irgendwas muß DJB oder qmail an sich
haben, daß immer behauptet wird, qmail würde alles richtig machen und
wäre ach so RFC-konform, obwohl es zwei essentielle RFCs (2821, 1652)
verletzt und einen dritten (1894) nicht implementiert.
> Mir ist nicht klar, warum Leute, die kein qmail einsetzen, bei dem Thema
> ueberhaupt mitreden.
> http://groups.google.com/groups?selm=9phpu1%24mf7%241%40bolzen.all.de
Weil sie qmail eingesetzt haben, weil sie qmail kennen, und weil sie
wissen, was da falsch läuft.
Mir wird auch klar, daß einige Leute, Socha, Du, augenscheinlich mehr
Wert auf die nicht wirklich RFC-nahe Implementierung von qmail legen als
auf Verträglichkeit und robuste Zustellung. Daß das den Problemen, die
diese Leute hier berichten, zuwider läuft, solltet Ihr beide
baldmöglichst bemerken.
--
Matthias Andree
Matthias Andree
>> geordneten Liste wählt. Mit selber Preference oder, wenn's davon keinen
>> mehr gibt, mit der nächsthöheren.
>
> Das widerspricht Abschnitt 4.2.1:
> 4yz Transient Negative Completion reply
> The command was not accepted, and the requested action did not
> occur. However, the error condition is temporary and the action
> may be requested again. The sender should return to the beginning
=====
> of the command sequence (if any).
[...]
Wo bitte widerspricht "Die Aktion darf nochmals verlangt werden" einem
"der SMTP Client, jede der relevanten Adressen dieser [MX-]Liste in der
Reihenfolge versuchen können (und erneut versuchen), solange, bis ein
Zustellversuch erfolgreich ist"?
Nirgends. Qmail darf natürlich nochmal denselben MX versuchen, es muß
aber die Backup-MX ebenfalls probieren und darf sich im Umkehrschluß
nicht darauf beschränken, nur den ersten zu benutzen.
Tatsache ist doch, daß mit der 421-Antwort die Transaktion gescheitert
ist und der Zustellversuch nicht erfolgreich war, und qmail nichtmals
den ersten Backup MX versucht.
qmail bleibt alleinschuldig an der Unzustellbarkeit an diejenige Domain,
deren erster MX "421" liefert. Und das zu leugnen statt zu beheben,
hilft absolut niemandem. qmail verstößt zum Nachteil seines Benutzers
gegen RFC-2821. Über Abhilfe kannst Du jetzt selbst nachdenken. Material
ist genug da.
--
Matthias Andree
Matthias Andree
>> geordneten Liste wählt. Mit selber Preference oder, wenn's davon keinen
>> mehr gibt, mit der nächsthöheren.
>
> Das widerspricht Abschnitt 4.2.1:
> 4yz Transient Negative Completion reply
> The command was not accepted, and the requested action did not
> occur. However, the error condition is temporary and the action
> may be requested again. The sender should return to the beginning
=====
> of the command sequence (if any).
[...]
Wo bitte widerspricht "Die Aktion darf nochmals verlangt werden" einem
"der SMTP Client, jede der relevanten Adressen dieser [MX-]Liste in der
Reihenfolge versuchen können (und erneut versuchen), solange, bis ein
Zustellversuch erfolgreich ist"?
Nirgends. Qmail darf natürlich nochmal denselben MX versuchen, es muß
aber die Backup-MX ebenfalls probieren und darf sich im Umkehrschluß
nicht darauf beschränken, nur den ersten erreichbaren MX zu versuchen.
Florian Weimer
Die Aussage ist richtig, dieses Verhalten ist aber nicht hinreichend
für korrekte Operation.
Gerrit Pape
> Hallo,
> Gerrit Pape <pa...@innominate.com> wrote:
>> Franz Georg Köhler <fgko...@gigabell.de> wrote:
>>> * quoting [Robin S. Socha <robin-dated-10...@socha.net>]
>>>> qmail verbindet sich mit MX records in distance order. Wenn ein MX
>>>> unerreichbar ist, versucht qmail nicht, einen MX mit höherem distance
>>>> entry anzusprechen. Warum sollte es auch?
>>> Um die Mail an diesen loszuwerden, da der höher-Priorisierte MX ja ein
>>> temporäres Problem hat?
>> Das loest nicht das temporaere Problem des shortest distance MX.
>> Letztendlich muss die Mail dahin, qmail wird einliefern, sobald das
>> temporaere Problem beseitigt ist.
> Die Auslieferung an den Host hat (laut RFC2881, wie schon mehrfach
> zitiert wurde) ggfs. ein Backup zu uebernehmen, falls der primary
> MX die Mail-Transaktion nicht vollstaendig abschliessen kann (warum
> auch immer). Dazu iost der Backup da. Wenn der Backup von qmail nur
Nein, und das jetzt mal ganz abgesehen von qmail.
RFC2821, 5.:
---
To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.
---
Das RFC erlaubt also, das u.U. bei einer bestimmten Konfiguration nur genau
ein MX kontaktiert wird, ganz unabhaengig von irgendeinem bestimmten MTA.
> in einem Bruchteil der Faelle so verwendet wird, ist qmail in dieser
> Hinsicht nicht RFC-konform (um die noch weniger schmeichelhafte
> Bezeichnung "kaputt" zu vermeiden). Dabei ist es voellig zweitrangig,
> ob du, Robin socha oder DJB das fuer sinnvoll haelt oder nicht, es
> ist so im RFC festgeschrieben und damit der einzuhaltende Standard.
Wie scheinbar auch Matthias Andree erkannt hat, hat dieser MX von der
TUB ein Problem und befolgt nicht das RFC:
http://groups.google.com/groups?selm=m3r8k3xjo3.fsf%40merlin.emma.line.org
Die Admins da scheinen es fuer sinnvoll zu halten, obwohl es nicht dem
Standard entspricht. Was daran ueberhaupt sinnvoll sein soll, habe ich
bisher nicht verstanden und konnte mir auch noch keiner hier erklaeren.
Mit postfix funktioniert es, weil Wietse damals diese 'Sendmail
compatibility', wie er sie nennt, implementiert hat, wie ich von Andree
gelernt habe.
http://groups.google.com/groups?selm=m31yc4zamm.fsf%40merlin.emma.line.org
Nun gibt es da vielleicht eine MTA, der die o.g. spezielle Konfiguration
hat, RFC konform operiert, diese 'Sendmail compatibility' nicht implemetiert
hat, aber die Mail kann nicht zugestellt werden.
Auf welcher Seite seht ihr jetzt das Problem, wenn ihr das Wort 'qmail' mal
kurz aus euren Koepfen streicht?
Gerrit.
Gerrit Pape
> Nirgends. Qmail darf natürlich nochmal denselben MX versuchen, es muß
> aber die Backup-MX ebenfalls probieren und darf sich im Umkehrschluß
Eben das nicht, oder warum steht im RFC sonst 'In any case, the SMTP client
SHOULD try at least two addresses.', wenn es keinen Fall gibt, wo nur genau
eine Adresse probiert wird.
> qmail bleibt alleinschuldig an der Unzustellbarkeit an diejenige Domain,
> deren erster MX "421" liefert. Und das zu leugnen statt zu beheben,
Niemand hat das 'geleugnet' soweit ich weiss. Ich habe ein Problem mit einem
MX, der _permanent_ temporary errors zurueckgibt, nicht mit qmail.
> hilft absolut niemandem. qmail verstößt zum Nachteil seines Benutzers
> gegen RFC-2821. Über Abhilfe kannst Du jetzt selbst nachdenken. Material
> ist genug da.
Ich habe qmail Installationen seit Jahren, habe diese Probleme nicht,
brauche keine Abhilfe. Wie der OP dieses Threads sein Problem in den Griff
bekommt, stand im ersten FollowUp.
Gerrit.
Gerrit Pape
> Gerrit Pape <pa...@innominate.com> writes:
>> FUD.
>> 'Mir ist klar, dass fuer bestimmte Leute, die eine Aversion gegen qmail
>> entwickelt haben, qmail allein schon deswegen Bugs hat, weil es einfach
>> qmail ist.'
> Komisch nur, daß die Bugs belegt werden, in der weiten Welt zu real
^^^^
Wie, schon wieder?
http://groups.google.com/groups?selm=m3itfih82c.fsf%40emma1.emma.line.org
> existierenden Problemen geführt haben (siehe Ursprung dieser Diskussion)
Ich sehe das Problem auf der anderen Seite und kann mir gut vorstellen, dass
es da noch andere MTAs gibt, mit denen es vielleicht auch nicht
funktioniert.
Gerrit.
Matthias Andree
>> in einem Bruchteil der Faelle so verwendet wird, ist qmail in dieser
>> Hinsicht nicht RFC-konform (um die noch weniger schmeichelhafte
>> Bezeichnung "kaputt" zu vermeiden). Dabei ist es voellig zweitrangig,
>> ob du, Robin socha oder DJB das fuer sinnvoll haelt oder nicht, es
>> ist so im RFC festgeschrieben und damit der einzuhaltende Standard.
>
> Wie scheinbar auch Matthias Andree erkannt hat, hat dieser MX von der
> TUB ein Problem und befolgt nicht das RFC:
Du legst mir Worte in den Mund oder in die Hand, die ich dort nicht
hingetan habe, und...
> http://groups.google.com/groups?selm=m3r8k3xjo3.fsf%40merlin.emma.line.org
...daß der RFC-2821 vorschreibe, innerhalb welcher Zeit ein temporäres
Problem behoben sein sollte, ist falsch und in dem Artikel nicht
behauptet. Die Zeitangabe ist ebendort in Abschnitt "4.5.4.1 Sending
Strategy" zu finden. Danke übrigens für den Hinweis darauf, daß qmail
auch an dieser Stelle RFC-widrig ist, weil der "retry algorithm"
(ibidem) eben nicht konfigurierbar ist.
[TU B]
> Die Admins da scheinen es fuer sinnvoll zu halten, obwohl es nicht dem
> Standard entspricht. Was daran ueberhaupt sinnvoll sein soll, habe ich
> bisher nicht verstanden und konnte mir auch noch keiner hier
> erklaeren.
Es ist erlaubt, und mit dem Wissen, daß eine gewisse von Dir
favorisierte Software da Bugs hat, die ihr Autor auch nicht beheben
wird, weil seine Software per definitionem keine hat, ist es vielleicht
ungeschickt.
> Nun gibt es da vielleicht eine MTA, der die o.g. spezielle Konfiguration
> hat, RFC konform operiert, diese 'Sendmail compatibility' nicht implemetiert
> hat, aber die Mail kann nicht zugestellt werden.
Im konkreten Fall, daß nur der /eine/ MX mit der absolut niedrigesten
"preference value" die Mail mit 421 abnimmt, kann das mit einem Client,
der die SHOULD-Bestimmung verletzt, auch nur dann passieren, wenn das
konfigurierbare Limit auf "1 MX" gesetzt ist. MTAs, die die Zahl der
besuchten MX-Records nicht durch den Admin begrenzen lassen, müssen
sowieso alle MX-Server abgrasen.
> Auf welcher Seite seht ihr jetzt das Problem, wenn ihr das Wort '*****' mal
> kurz aus euren Koepfen streicht?
Immer noch auf Seite des Clients, der die Backups nicht versucht. Es ist
ja nicht der MTA explizit konfiguriert worden, schon nach dem ersten MX
aufzugeben.
--
Matthias Andree
Matthias Andree
> Wie, schon wieder?
> http://groups.google.com/groups?selm=m3itfih82c.fsf%40emma1.emma.line.org
Ich weiß jetzt, daß Du qmail-Bugs ebenso wegdefinierst wie Dan, Du
brauchst das nicht immer neu zu belegen. Trotzdem sind sie da, bis
jemand sich ihrer annimmt.
>> existierenden Problemen geführt haben (siehe Ursprung dieser Diskussion)
>
> Ich sehe das Problem auf der anderen Seite und kann mir gut vorstellen, dass
> es da noch andere MTAs gibt, mit denen es vielleicht auch nicht
> funktioniert.
Das Problem liegt im RFC-2821-Verstoß von Kuhmail. Daß ferner eine
andere Gurkensoftware das falsch macht, ist noch lange keine
Rechtfertigung, es selbst falsch zu machen.
Wieviel zahlt Dir Dan für die erste Verteidigungslinie?
--
Matthias Andree
Matthias Andree
> Matthias Andree <matthia...@gmx.de> wrote:
>> Nirgends. Qmail darf natürlich nochmal denselben MX versuchen, es muß
>> aber die Backup-MX ebenfalls probieren und darf sich im Umkehrschluß
>
> Eben das nicht, oder warum steht im RFC sonst 'In any case, the SMTP client
> SHOULD try at least two addresses.', wenn es keinen Fall gibt, wo nur genau
> eine Adresse probiert wird.
Zusammen mit dem Satz davor "However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried." ergibt
das den Sinn, daß der Client auch dann zwei MX versuchen soll, wenn der
Admin konfiguriert hat "nur einen".
>> qmail bleibt alleinschuldig an der Unzustellbarkeit an diejenige Domain,
>> deren erster MX "421" liefert. Und das zu leugnen statt zu beheben,
>
> Niemand hat das 'geleugnet' soweit ich weiss. Ich habe ein Problem mit einem
> MX, der _permanent_ temporary errors zurueckgibt, nicht mit qmail.
Ich weiß, daß Du mit qmail kein Problem hat, weil ja qmail auch keine
Bugs hat, weil nicht sein kann, was nicht sein darf.
Wie die Firewall vor dem ersten MX sinnvoller konfiguriert wäre (nämlich
RST oder ICMP statt SYN|ACK schicken), ist ja unbestritten hier genannt
worden.
> Ich habe qmail Installationen seit Jahren, habe diese Probleme nicht,
> brauche keine Abhilfe. Wie der OP dieses Threads sein Problem in den Griff
> bekommt, stand im ersten FollowUp.
Mit dem "in den Griff kriegen" schafft sich der OP. aber das neue
Problem, daß er fortan laufend die MX-Liste kontrollieren muß, will er
fehlgeleitete Mail vermeiden -- und einen Menschen vor einen Mailserver
zu setzen, der als zuverlässig angepriesen ist, aber genau in solchen
Konstellationen keine Mail loswird, halte ich für absolut inakzeptabel.
--
Matthias Andree
Andreas Barth
> Ich sehe das Problem auf der anderen Seite und kann mir gut vorstellen, dass
> es da noch andere MTAs gibt, mit denen es vielleicht auch nicht
> funktioniert.
Es gibt da einen netten Spruch:
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:
"Be liberal in what you accept, and
conservative in what you send"
RFC 1122/STD0003 Requirements for Internet Hosts - Communication
Layers
Qmail sollte mal anfangen, diesen seit Oktober _1989_ gültigen RFC zu
implementieren. Nur weil die andere Seite einen Fehler macht, macht es
qmail noch lange nicht richtig.
Grüße,
Andi
--
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
die Weltherrschaft erringen Ziel des Spiels "Risiko" 1976
die Welt zu befreien ... und 1990.
Matthias Andree
421-in-RFC-2821-Behauptung. RFC-2821 erlaubt 421.]
Gerrit Pape <pa...@innominate.com> writes:
> Matthias Andree <matthia...@gmx.de> wrote:
>> Rene' Kray <c...@pool.math.tu-berlin.de> writes:
>>> Trying 130.149.11.8...
>>> Connected to fb3-s7.math.TU-Berlin.DE.
>>> Escape character is '^]'.
>>> 421 gate.hhi.de Sorry, unable to contact destination SMTP daemon.
>>> Connection closed by foreign host.
>
>> DAS ist ein Problem. Qmail denkt sich: "später geht's ja wieder" und
>> legt sich damit auf den Bart.
>
> Die Antwort von 130.149.11.8 ist 421: 'temporarily rejects the connection',
> 4xx sind temporary errors, das entspricht "spaeter geht's ja wieder".
Korrekt. Wenn man denen das geeignet mitteilt und von Kostenersparnis
(Berlin ist ja pleite...) redet, sollten sie sich vielleicht dazu
bequemen, lieber RST zu schicken.
>> Ohne Patches geht bei qmail gar nichts.
>
> Bei mir 'geht' ungepatchtes qmail seit Jahren als zuverlaessiger MTA.
Lief das ohne den big-DNS-record-Patch, als AOL noch über 512 Byte in
der Antwort war?
>> Das meiste Verhalten ist hart verdrahtet. So auch dieses.
>
> Mittels smtproutes laesst sich das Verhalten aendern.
Nein, man bräuchte ein "Wenn ein MX 421 oder 554 sagt, probier' den
nächsten". Das kannst Du leider nicht konfigurieren ohne Patch: wenn
qmail einen Connect hat und etwas anderes als 220 sieht, hinterläßt es
eine Abschiedszeile und springt aus dem Fenster.
>> Nach Lektüre von qmail-remote.c (aus qmail-1.03):
>> qmail versucht grundsätzlich nur den ersten MX, zu dem es eine
>> Verbindung bekommen kann. Wenn der sich mit Meldungen wie 421 oder so
>> verabschiedet: bei qmail hast Du verloren. Auch aus anderen Gründen.
>
> qmail probiert bei einem temporary error den gleichen Server spaeter
> nochmal. Logisch. Hoer auf mit Deinem FUD.
Warum? Es gibt Backup-MX, die die Mail zur gegebenen Zeit annehmen
können, qmail versucht das nicht und verstößt damit gegen RFC-2821. Dort
geht es, wie geschrieben, um Delivery, nicht Delivery Attempts.
Und: qmail probiert bei einem permanent error (554) denselben Server
ebenfalls nochmal statt zu bouncen oder die anderen MX zu versuchen, und
das ist sicher ein Bug.
*Ungetesteter* Patch:
--- qmail-remote.c.orig Wed May 22 12:41:20 2002
+++ qmail-remote.c Wed May 22 12:52:13 2002
@@ -222,7 +222,9 @@
int flagbother;
int i;
- if (smtpcode() != 220) quit("ZConnected to "," but greeting failed");
+ code = smtpcode();
+ if (code >= 400 && code < 600) return; /* try next MX, see RFC-2821 */
+ if (code != 220) quit("ZConnected to "," but greeting failed");
substdio_puts(&smtpto,"HELO ");
substdio_put(&smtpto,helohost.s,helohost.len);
@@ -417,7 +419,7 @@
if (timeoutconn(smtpfd,&ip.ix[i].ip,(unsigned int) port,timeoutconnect) == 0) {
tcpto_err(&ip.ix[i].ip,0);
partner = ip.ix[i].ip;
- smtp(); /* does not return */
+ smtp(); /* only returns when the next MX is to be tried */
}
tcpto_err(&ip.ix[i].ip,errno == error_timeout);
close(smtpfd);
>> Insofern gilt meine Empfehlung: bei Ärger mit qmail auf Postfix
>> umstellen. Weniger Systemlast, mehr Flexibilität, mehr Transparenz,
>> robuster, und bei chroot auch mehr Sicherheit.
>
> ;-) ist der code jetzt schon so schlimm, dass Sicherheit nur noch mit chroot
> gegeben ist...
Wer mit "Sicherheit" wirbt...
(...muß trotzdem damit rechnen, daß die Konkurrenz noch eine Hürde mehr
aufstellt)
>> Postfix 1.1.10 kommt damit klar, sofern man nicht smtp_skip_4xx_greeting
>> vom Default "yes" auf "no" geändert hat, Auszug aus
>
> Hmm, stellt sich die Frage, warum es denn die Option smtp_skip_4xx_greeting
> und die Moeglichkeit diese auf 'no' zu setzen ueberhaupt gibt.
Oder die Frage, warum qmail so eine Option nicht hat.
Postfix' HISTORY beantwortet die Frage:
19990212
Feature: skip SMTP servers that greet us with a 4XX status
code. Example: "smtp_skip_4xx_greeting = yes". By default,
the Postfix SMTP client defers delivery when a server
declines talking to us. File: smtp/smtp_connect.c.
[...]
20000506
[...]
Sendmail compatibility: the Postfix SMTP client now skips
servers that greet the client with a 4xx or 5xx status
code. To disable, set both smtp_skip_4xx_greeting and
smtp_skip_5xx_greeting to "no".
Die Konfiguration dokumentiert:
# The smtp_skip_4xx_greeting parameter controls what happens when
# an SMTP server greets us with a 4XX status code (go away, try
# again later).
#
# By default, Postfix moves on the the next mail exchanger. Specify
# "smtp_skip_4xx_greeting = no" if Postfix should defer delivery
# immediately.
#
smtp_skip_4xx_greeting = yes
In der Mailingliste wurde eben das Problem berichtet, daß einige Server
mit 4XX grüßten, obwohl sie 5XX meinten.
--
Matthias Andree
Gerrit Pape
>> TUB ein Problem und befolgt nicht das RFC:
> Du legst mir Worte in den Mund oder in die Hand, die ich dort nicht
> hingetan habe, und...
Wenn das so ist, sorry. Das ist ja sonst Deine Spezialitaet:
http://archives.neohapsis.com/archives/postfix/2001-08/1477.html
> ...daß der RFC-2821 vorschreibe, innerhalb welcher Zeit ein temporäres
> Problem behoben sein sollte, ist falsch und in dem Artikel nicht
> behauptet. Die Zeitangabe ist ebendort in Abschnitt "4.5.4.1 Sending
> Strategy" zu finden. Danke übrigens für den Hinweis darauf, daß qmail
> auch an dieser Stelle RFC-widrig ist, weil der "retry algorithm"
> (ibidem) eben nicht konfigurierbar ist.
Ich denke, Du kennst qmail.
man qmail-send -> /var/qmail/control/queuelifetime
FAQ 7.3
> [TU B]
>> Die Admins da scheinen es fuer sinnvoll zu halten, obwohl es nicht dem
>> Standard entspricht. Was daran ueberhaupt sinnvoll sein soll, habe ich
>> bisher nicht verstanden und konnte mir auch noch keiner hier
>> erklaeren.
> Es ist erlaubt, und mit dem Wissen, daß eine gewisse von Dir
> favorisierte Software da Bugs hat, die ihr Autor auch nicht beheben
> wird, weil seine Software per definitionem keine hat, ist es vielleicht
> ungeschickt.
Es scheint nicht verboten, einen MX so zu konfigurieren, das er permanent
bestimmten clients temporary errors zurueckgibt. Wer das macht, darf sich
aber nicht wundern, wenn er u.U. nicht jede Mail, fuer die er zustaendig ist,
auch wirklich bekommt.
>> Nun gibt es da vielleicht eine MTA, der die o.g. spezielle Konfiguration
>> hat, RFC konform operiert, diese 'Sendmail compatibility' nicht implemetiert
>> hat, aber die Mail kann nicht zugestellt werden.
> Im konkreten Fall, daß nur der /eine/ MX mit der absolut niedrigesten
> "preference value" die Mail mit 421 abnimmt, kann das mit einem Client,
^^^^^^^^^^^^^^^ haeh?
> der die SHOULD-Bestimmung verletzt, auch nur dann passieren, wenn das
> konfigurierbare Limit auf "1 MX" gesetzt ist. MTAs, die die Zahl der
Ja. Genau das habe ich geschrieben, Du hast es nochmal wiederholt.
>> Auf welcher Seite seht ihr jetzt das Problem, wenn ihr das Wort '*****' mal
>> kurz aus euren Koepfen streicht?
> Immer noch auf Seite des Clients, der die Backups nicht versucht. Es ist
Ich nicht.
> ja nicht der MTA explizit konfiguriert worden, schon nach dem ersten MX
> aufzugeben.
Das war aber die Annahme, s.o. Du bist scheinbar nicht faehig, das Wort
'qmail' aus Deinem Kopf zu streichen.
Gerrit.
Matthias Andree
>> ...daß der RFC-2821 vorschreibe, innerhalb welcher Zeit ein temporäres
>> Problem behoben sein sollte, ist falsch und in dem Artikel nicht
>> behauptet. Die Zeitangabe ist ebendort in Abschnitt "4.5.4.1 Sending
>> Strategy" zu finden. Danke übrigens für den Hinweis darauf, daß qmail
>> auch an dieser Stelle RFC-widrig ist, weil der "retry algorithm"
>> (ibidem) eben nicht konfigurierbar ist.
>
> Ich denke, Du kennst qmail.
> man qmail-send -> /var/qmail/control/queuelifetime
Ich denke nicht, daß das hinreichend ist, weil insbesondere das
Intervall für neue Versuche festliegt.
> FAQ 7.3
Nicht anwendbar, weil es manuellen Eingriff erfordert. RFC-2821 spricht
aber von Konfigurierbarkeit der Parameter des "retry algorithm".
> Es scheint nicht verboten, einen MX so zu konfigurieren, das er permanent
> bestimmten clients temporary errors zurueckgibt. Wer das macht, darf sich
> aber nicht wundern, wenn er u.U. nicht jede Mail, fuer die er zustaendig ist,
> auch wirklich bekommt.
Man kann erwarten, daß Clients RFC-2821 korrekt implementieren. Ich
würde an Stelle der TU Berlin auch keine Rücksicht darauf nehmen, daß
vielleicht irgendwo in der Welt eine Spielzeugsoftware es nicht gebacken
kriegt, andere MX auszuprobieren. Der Grund, dennoch auf 421 zu
verzichten und RST zu verschicken, ist: weniger packets (Handshake
weglassen) == weniger Kosten.
>>> Auf welcher Seite seht ihr jetzt das Problem, wenn ihr das Wort '*****' mal
>>> kurz aus euren Koepfen streicht?
>
>> Immer noch auf Seite des Clients, der die Backups nicht versucht. Es ist
>
> Ich nicht.
Welchen Sinn neben der Verunsachlichung der Debatte hatte Deine Frage
dann?
>> ja nicht der MTA explizit konfiguriert worden, schon nach dem ersten MX
>> aufzugeben.
>
> Das war aber die Annahme, s.o. Du bist scheinbar nicht faehig, das Wort
> 'qmail' aus Deinem Kopf zu streichen.
Das hat damit nichts zu tun. Der Client MUSS die komplette MX-Liste
abgrasen, sofern nicht der Admin etwas anderes konfiguriert -- und das
hat er nicht. Selbst, wenn auch Sendmail bei 421 nicht die Backups
versuchen würde, würde das an meiner Einschätzung nichts ändern.
--
Matthias Andree
Gerrit Pape
> "Robin S. Socha" <robin-dated-10...@socha.net> writes:
>> Deine Liebe zu Postfix sei Dir unbenommen, aber Dein qmail-bashing
>> nervt, wenn Dir - wie hier - schlicht die Argumente ausgehen.
> Ich wiederhole die Argumente nicht en detail, weil sie jeder mit Google
> nachlesen kann.
Ich habe das mal probiert, leider kann ich die 'Argumente' unter einer
Unmenge von FUD von Matthias Andree in dieser Gruppe nicht finden, das ist
wie Nadeln im Heuhaufen.
Gerrit.
Gerrit Pape
>> bestimmten clients temporary errors zurueckgibt. Wer das macht, darf sich
>> aber nicht wundern, wenn er u.U. nicht jede Mail, fuer die er zustaendig ist,
>> auch wirklich bekommt.
> Man kann erwarten, daß Clients RFC-2821 korrekt implementieren. Ich
> würde an Stelle der TU Berlin auch keine Rücksicht darauf nehmen, daß
> vielleicht irgendwo in der Welt eine Spielzeugsoftware es nicht gebacken
> kriegt, andere MX auszuprobieren.
['qmail' aus dem Kopf streichen]
Wie wir erkannt haben, erlaubt das RFC, dass nur genau ein MX kontaktiert
wird, wenn auch nur in einer speziellen Konfiguration, das ist also ein
korrekt implementierter Client. Kann mir denn endlich mal jemand erklaeren,
_warum_ die TUB diese Configuration hat, die eindeutig ein Problem hat:
'_permanent_ eine _temporary_ error melden'?
>>>> Auf welcher Seite seht ihr jetzt das Problem, wenn ihr das Wort '*****' mal
>>>> kurz aus euren Koepfen streicht?
>>
>>> Immer noch auf Seite des Clients, der die Backups nicht versucht. Es ist
>>
>> Ich nicht.
> Welchen Sinn neben der Verunsachlichung der Debatte hatte Deine Frage
> dann?
Bist Du verwirrt? Wenn Du etwas nicht verstanden hast, lies meine Postings
nochmal durch. Den von Dir genannten Sinn auf jeden Fall nicht.
>>> ja nicht der MTA explizit konfiguriert worden, schon nach dem ersten MX
>>> aufzugeben.
>>
>> Das war aber die Annahme, s.o. Du bist scheinbar nicht faehig, das Wort
>> 'qmail' aus Deinem Kopf zu streichen.
> Das hat damit nichts zu tun. Der Client MUSS die komplette MX-Liste
> abgrasen, sofern nicht der Admin etwas anderes konfiguriert -- und das
> hat er nicht. Selbst, wenn auch Sendmail bei 421 nicht die Backups
> versuchen würde, würde das an meiner Einschätzung nichts ändern.
Bist Du verwirrt oder bloed?, mittlerweile tendiere ich zu Zweiterem.
Annahme: Client ist so konfiguriert.
Folgerung: klappt nicht.
Matthias Andree: Client ist nicht so konfiguriert, klappt also.
Haeh?
Gerrit.
Gerrit Pape
> Gerrit Pape <pa...@innominate.com> writes:
>> Matthias Andree <matthia...@gmx.de> wrote:
>>> Nirgends. Qmail darf natürlich nochmal denselben MX versuchen, es muß
>>> aber die Backup-MX ebenfalls probieren und darf sich im Umkehrschluß
>> Eben das nicht, oder warum steht im RFC sonst 'In any case, the SMTP client
>> SHOULD try at least two addresses.', wenn es keinen Fall gibt, wo nur genau
>> eine Adresse probiert wird.
> Zusammen mit dem Satz davor "However, there MAY also be a configurable
> limit on the number of alternate addresses that can be tried." ergibt
> das den Sinn, daß der Client auch dann zwei MX versuchen soll, wenn der
> Admin konfiguriert hat "nur einen".
Das kann ich absolut nicht nachvollziehen. Entpricht das irgendeiner mir
nicht bekannten Logik?
Gerrit.
Matthias Andree
> ['qmail' aus dem Kopf streichen]
> Wie wir erkannt haben, erlaubt das RFC, dass nur genau ein MX kontaktiert
> wird, wenn auch nur in einer speziellen Konfiguration, das ist also ein
> korrekt implementierter Client.
Falsch. Dem Client ist die Zahl der Neuversuche eben NICHT durch
Konfiguration beschränkt worden, sondern er hat eigenmächtig und
RFC-widrig den Versuch beim Backup-MX unterschlagen. Damit hat er gegen
eine "MUST"-Bestimmung verstoßen: die Nichtzustellung ist alleine sein
Problem.
> Kann mir denn endlich mal jemand erklaeren, _warum_ die TUB diese
> Configuration hat, die eindeutig ein Problem hat: '_permanent_ eine
> _temporary_ error melden'?
Für Dich gilt: Die TU B braucht sich dafür nicht zu rechtfertigen, sie
darf ihren Primary MX mit 421 grüßen, wann, wen und solange sie
will. Benutz' die Backup-MX-Server.
Für die TU B gilt: es gibt defekte Clients, die raffen das nicht. Nehmt
RST statt SMTP 421, ist eh billiger für Euch.
> Bist Du verwirrt oder bloed?, mittlerweile tendiere ich zu Zweiterem.
> Annahme: Client ist so konfiguriert.
> Folgerung: klappt nicht.
> Matthias Andree: Client ist nicht so konfiguriert, klappt also.
???
Nochmal deutlich, auch und besonders für Leute, die andere gerne blöd
nennen:
RFC-2821 sagt:
1. Client MUSS die komplette MX-Liste abgrasen und jeden MX
ausprobieren, und zwar in der Reihenfolge aufsteigender "preference
value".
2. Client DARF zusätzlich einen Schalter anbieten, mit dem der
Administrator die Zahl der Neuversuche begrenzen kann.
3. Client SOLL in jedem Fall mindestens zwei MX versuchen.
Übrigens ergibt sich die von Dir aus der Postfix-History aufgegriffene
"Sendmail-Kompatibilität" auch daraus, daß RFC-2821 augenscheinlich von
Sendmail in dieser Hinsicht korrekt implementiert wird -- nur, daß
diese Verhaltensänderung in Postfix vor Veröffentlichung von RFC-2821
geschehen ist und daher RFC-2821-Konformität zur Begründung nicht
herhalten konnte. Ist aber auch egal, wie man's nennt.
Somit ist ein Client, der nicht alle MX versucht, verdächtig des
RFC-Verstoßes nach 1. Daß der SMTP-Client konfiguriert war, die
MX-Versuche frühzeitig abzubrechen, ist nicht bekannt geworden[*]. In
jedem Fall verstößt der fragliche Client gegen die
Soll-Bestimmung. Damit ist er für sein Zustellproblem allein
verantwortlich.
Da gibt's nichts dran zu drehen, und Interpretationsspielraum der Art,
daß Clients nach dem 421-Gruß nicht wenigstens den ersten Backup-MX
versuchen, ist nicht gegeben.
Mit anderen Worten: ein Client, der grundsätzlich nur den Primary-MX
versucht, ist nicht RFC-konform (ob's klappt oder nicht, ist dabei nicht
bedeutsam).
-----
[*] Wenn wir jetzt den Namen des ursprünglichen Clients wieder
einblenden und dem in die Eingeweide schauen, sehen wir, daß er
einen Schalter nach 2. nicht anbietet. 3. wird damit redundant.
--
Matthias Andree
Matthias Andree
> Ich habe das mal probiert, leider kann ich die 'Argumente' unter einer
> Unmenge von FUD von Matthias Andree in dieser Gruppe nicht finden, das ist
> wie Nadeln im Heuhaufen.
FUD, klar. Wenn Dich qmail-Bugs ängstigen, unsicher machen, ob qmail die
richtige Software ist oder Dich an Deiner Wahl zweifeln lassen.
Nochmal zusammengefaßt:
http://mandree.home.pages.de/qmail-bugs.html
--
Matthias Andree
Matthias Andree
Wenn Dir die in diesem Land gängige Logik fremd sein sollte, könnte das
der Fall sein.
--
Matthias Andree
Jakob Hirsch
> Nochmal zusammengefaßt:
> http://mandree.home.pages.de/qmail-bugs.html
Ich will jetzt nicht in diese unsägliche Diskussion einsteigen, aber
zumindest 3.1 macht Exim (leider) auch. Allerdings nicht standardmäßig,
dort muß man 8BITMIME explizit aktivieren und in der Doku wird explizit
davor gewarnt.
Florian Weimer
Es kann durchaus Situationen geben, in denen 8BITMIME auch ohne
MIME-Konverter sinnvoll ist (z.B. bei Leafsites, die zusätzliche keine
Bounces nach dem Annehmen einer Nachricht erzeugen).
Andreas Metzler
Wie handhabt das Postfix? Bietet es kein 8BITMIME an oder konvertiert
es bei Bedarf zu QP? Konvertiert es wie sendmail auch in andere
Richtung?
cu andreas
--
Hey, da ist ein Ballonautomat auf der Toilette!
vim:ls=2:stl=***\ Sing\ a\ song.\ ***
Matthias Andree
Sendmail's just-send-eight-Option ist da nicht besser, ist aber, als ich
zuletzt nachgesehen habe, ebenfalls nicht die Standardeinstellung.
Auch die stable-Postfix-Versionen haben das Problem, daß sie 8BITMIME
versprechen, aber die Konvertierung nicht vornehmen, nur ist hier
absehbar, daß das Problem verschwinden wird, die experimental-Version
(seit 1.1.11-20020527, aktuell -20020529) ist bereits gebugfixt, nur
gibt's bei Postfix keinen "MFC" (merge from current) wie bei FreeBSD,
der dann die Kiste zerreißt: der Bugfix bedingt ein neues Feature, einen
MIME-Zustandsautomaten, und der kann eben erst mit Postfix 1.2 kommen.
Besonders Postfix-Maschinen, die Mailinglisten fahren, tun sehr gut
daran, Postfix 1.1.11-20020529 (aus dem experimental-Verzeichnis) zu
benutzen und strict_8bitmime=yes zu setzen, um zu vermeiden, daß einige
Listenteilnehmer Mail mit defektem 8Bit-Zeug bekommen und andere nicht,
weil deren MX etwas pingeliger ist.
Für 1.1.x-Postfixen hab' ich einen pro-forma-Patch, der zwar Dummheiten
nicht verhindert, aber wenigstens die Versprechung, die Postfix nicht
hält, abschaltet:
http://mandree.home.pages.de/postfix/patch-postfix-1.1.10-rfc1652.diff
Für qmail ist der äquivalente Patch:
http://mandree.home.pages.de/postfix/patch-qmail-1.03-rfc1652.diff
--
Matthias Andree
Matthias Andree
> Es kann durchaus Situationen geben, in denen 8BITMIME auch ohne
> MIME-Konverter sinnvoll ist (z.B. bei Leafsites, die zusätzliche keine
> Bounces nach dem Annehmen einer Nachricht erzeugen).
Den letzten Halbsatz kannst Du bei qmail leider vergessen. Übrigens
danke für die unbeabsichtigte Erinnerung, einen Absatz über delayed
bounces in mein qmail-bugs.html zu schreiben. ;-)
--
Matthias Andree
Matthias Andree
> Jakob Hirsch <forg...@plonk.de> wrote:
>> Matthias Andree wrote:
>>> Nochmal zusammengefaßt:
>>> http://mandree.home.pages.de/qmail-bugs.html
>
>> Ich will jetzt nicht in diese unsägliche Diskussion einsteigen, aber
>> zumindest 3.1 macht Exim (leider) auch. Allerdings nicht standardmäßig,
>> dort muß man 8BITMIME explizit aktivieren und in der Doku wird explizit
>> davor gewarnt.
>
> Wie handhabt das Postfix? Bietet es kein 8BITMIME an oder konvertiert
> es bei Bedarf zu QP? Konvertiert es wie sendmail auch in andere
> Richtung?
Postfix 1.1.x und Snapshots vor (ausschließlich) 20020527: Es bietet
8BITMIME ohne Konvertierung an. Das ist RFC-1652-widrig.
Postfix 1.1.11-20020527 und neuere Snapshots: Konvertieren für Ziele,
die nicht 8BITMIME reden, alles, was nicht 7bit ist, nach
quoted-printable.
Die Rückkonvertierung ist nicht implementiert, und in einem MTA auch
nicht sinnvoll: es könnte ja sein, daß der Absender schon
quoted-printable codiert hat, und sowas sollte man nicht eigenmächtig
auf 8bit umstricken. Für den anderen Weg gibt's hingegen die zwingende
Notwendigkeit aus RFC-1652.
Wer die Konvertierung quoted-printable/base64 -> 8bit benötigt, kann sie
z. B. mit "reformime" und dessen -r8-Option haben, und dieses z. B. per
/etc/procmailrc (:0f und |) oder /etc/maildroprc (xfilter)
zwangseinbinden.
reformime gehört zu Sam Varshavchiks maildrop.
<URL:http://www.flounder.net/~mrsam/maildrop/README.html>.
--
Matthias Andree
Florian Weimer
> Florian Weimer <f...@deneb.enyo.de> writes:
>
>> Es kann durchaus Situationen geben, in denen 8BITMIME auch ohne
>> MIME-Konverter sinnvoll ist (z.B. bei Leafsites, die zusätzliche keine
>> Bounces nach dem Annehmen einer Nachricht erzeugen).
>
> Den letzten Halbsatz kannst Du bei qmail leider vergessen.
Ja, ich weiß. :-(
In unserer internen Dokumentation gibt es nach einem halben Jahr qmail
einen Abschnitt über die zahlreichen Probleme. :-/
> Übrigens danke für die unbeabsichtigte Erinnerung, einen Absatz über
> delayed bounces in mein qmail-bugs.html zu schreiben. ;-)
Im Praxisbetrieb ist mir jüngst folgendes Verhalten von qmail
aufgefallen: Wenn qmail sehr viel Mail an einen MX zuzustellen hat
und dieser die Parallelität stärker einschränkt als das sendende
qmail, dann bekommt ein Teil der qmail-remote-Prozesse ein "Connection
Refused" oder einen anderen temporären Fehler, und Mail bleibt erst
einmal liegen, obwohl die Ressourcen für die Zustellung vorhanden
sind.
Mit anderen Worten: Die angeblich so flinke Parallelzustellung sorgt
dafür, daß Mail unnötig lange liegenbleibt. Ich habe nicht
ausprobiert, was passiert, wenn man einen etwas gemütlicheren Host mit
vernünftigem Verbindungslimit als Smarthost einträgt, oder wenn man
sehr viel Mail verschickt. Ob das dann Sekundärkollisionen beim
nächsten Zustellversuch gibt?
Jakob Hirsch
> Es kann durchaus Situationen geben, in denen 8BITMIME auch ohne
> MIME-Konverter sinnvoll ist (z.B. bei Leafsites, die zusätzliche keine
> Bounces nach dem Annehmen einer Nachricht erzeugen).
Wenn man nur mail annimmt, ist es kein Problem, aber die meisten
leafsites verschicken auch mal was. Da darf der MUA schon keine
8bit-mails erzeugen, weil der MTA das unverändert durchhaut.
Auf exim-users gab's übrigens vor kurzem einen längeren Thread dazu,
u.a. weil demon.(nl|uk) noch irgendein altes Mailsystem einsetzt, das
nicht 8bit-fest ist.
Florian Weimer
>> Es kann durchaus Situationen geben, in denen 8BITMIME auch ohne
>> MIME-Konverter sinnvoll ist (z.B. bei Leafsites, die zusätzliche keine
>> Bounces nach dem Annehmen einer Nachricht erzeugen).
>
> Wenn man nur mail annimmt, ist es kein Problem, aber die meisten
> leafsites verschicken auch mal was.
Das sollte kein Problem sein (bis auf Bounces eben).
> Da darf der MUA schon keine 8bit-mails erzeugen, weil der MTA das
> unverändert durchhaut.
Wenn der MUA nicht über ESMTP einliefert und per Voreinstellung
8-Bit-Nachrichten generiert, ist er defekt.
M.E. ist es durchaus sinnvoll, falsches 8BITMIME als Option
anzubieten, nur eben nicht per Voreinstellung.
Joerg Backschues
> Warum? Es gibt Backup-MX, die die Mail zur gegebenen Zeit annehmen
> können, qmail versucht das nicht und verstößt damit gegen RFC-2821. Dort
> geht es, wie geschrieben, um Delivery, nicht Delivery Attempts.
Das qmail Problem, um das Du hier einen riesen Aufstand machst, ist
mittlerweile schon kalter Kaffee: Schon 1999 war das Problem bekannt und
es gab entsprechende Patches dafür.
vgl. http://msgs.securepoint.com/cgi-bin/get/qmail9906/389.html
Mit freundlichen Grüßen
Jörg Backschues
Florian Weimer
> Das qmail Problem, um das Du hier einen riesen Aufstand machst, ist
> mittlerweile schon kalter Kaffee: Schon 1999 war das Problem bekannt
> und es gab entsprechende Patches dafür.
Zumindest Dezember 2001 waren diese noch nicht in die Quellen
eingeflossen.
Ich bevorzuge jedenfalls Software, bei der ich nicht alle
Ungereimtheiten nach und nach selbst wegpatchen muß. Sonst könnte ich
ja auch alles selbst schreiben.
Matthias Andree
> "Jakob Hirsch" <forg...@plonk.de> writes:
>
>>> Es kann durchaus Situationen geben, in denen 8BITMIME auch ohne
>>> MIME-Konverter sinnvoll ist (z.B. bei Leafsites, die zusätzliche keine
>>> Bounces nach dem Annehmen einer Nachricht erzeugen).
>>
>> Wenn man nur mail annimmt, ist es kein Problem, aber die meisten
>> leafsites verschicken auch mal was.
>
> Das sollte kein Problem sein (bis auf Bounces eben).
Wenn die Kisten nur wenigstens so schlau wären, dann
MIME-Version: 1.0
Content-Type: multipart/report; boundary="=_huesebrue"
Content-Transfer-Encoding: binary
--=_huesebrue
[Bounce hier]
--=_huesebrue--
da drumherum zu schreiben. Tun sie aber nicht, und legen sich verdient
auf die Fr_ss_.
> Wenn der MUA nicht über ESMTP einliefert und per Voreinstellung
> 8-Bit-Nachrichten generiert, ist er defekt.
Könnte ja sein, daß er per /usr/sbin/sendmail -B8BITMIME
einliefert... (Postfix 1.1.11-20020527 braucht übrigens die Deklaration
im Envelope nichtmals, sondern rafft bei korrekt formatierten Postings
selbst anhand der Transfer-Encodings, daß 8bit drin ist).
> M.E. ist es durchaus sinnvoll, falsches 8BITMIME als Option
> anzubieten, nur eben nicht per Voreinstellung.
Sag' das den Leuten, die "Anale Schalter sind per Default aus" (oder so
ähnlich) sagen. :*)
--
Matthias Andree
Matthias Andree
> Matthias Andree schrieb:
>
>> Warum? Es gibt Backup-MX, die die Mail zur gegebenen Zeit annehmen
>> können, qmail versucht das nicht und verstößt damit gegen RFC-2821. Dort
>> geht es, wie geschrieben, um Delivery, nicht Delivery Attempts.
>
> Das qmail Problem, um das Du hier einen riesen Aufstand machst, ist
> mittlerweile schon kalter Kaffee: Schon 1999 war das Problem bekannt und
> es gab entsprechende Patches dafür.
Den Aufstand betreiben diejenigen, die das Problem bestreiten oder
leugnen. Und warum sind die Patches in qmail nie eingegangen? Ein Grund
mehr, die Finger von dem Zeug zu lassen.
> vgl. http://msgs.securepoint.com/cgi-bin/get/qmail9906/389.html
Wo ist bitte der Patch? Und wohin wollen die mit ihrem close() in der
Diskussion?
--
Matthias Andree
Matthias Andree
> In unserer internen Dokumentation gibt es nach einem halben Jahr qmail
> einen Abschnitt über die zahlreichen Probleme. :-/
Oh, steht da außer dem unten noch etwas drin, was meinem
http://mandree.home.pages.de/qmail-bugs.html fehlt?
>> Übrigens danke für die unbeabsichtigte Erinnerung, einen Absatz über
>> delayed bounces in mein qmail-bugs.html zu schreiben. ;-)
>
> Im Praxisbetrieb ist mir jüngst folgendes Verhalten von qmail
> aufgefallen: Wenn qmail sehr viel Mail an einen MX zuzustellen hat
> und dieser die Parallelität stärker einschränkt als das sendende
> qmail, dann bekommt ein Teil der qmail-remote-Prozesse ein "Connection
> Refused" oder einen anderen temporären Fehler, und Mail bleibt erst
> einmal liegen, obwohl die Ressourcen für die Zustellung vorhanden
> sind.
Da war was mit überrennen und dabei tottrampeln.
http://www.informatik.uni-bonn.de/pub/software/postfix/queuing.html
"No thundering herd"
> Mit anderen Worten: Die angeblich so flinke Parallelzustellung sorgt
> dafür, daß Mail unnötig lange liegenbleibt.
Die "flinke" Parallelzustellung ist erforderlich, um die durch die
Nichtimplementierung von ESMTP PIPELINING auf der Clientseite
entstehende Latenzzeit zu verdecken. Ich zweifele nicht an, daß
qmail-send mit -rspawn und -remote Deinen externen Link sättigen kann,
ist halt nur blöd, 20 mal dieselbe Mail an denselben MX zu
pusten. Designfehler in qmail-send halt.
> Ich habe nicht ausprobiert, was passiert, wenn man einen etwas
> gemütlicheren Host mit vernünftigem Verbindungslimit als Smarthost
> einträgt, oder wenn man sehr viel Mail verschickt. Ob das dann
> Sekundärkollisionen beim nächsten Zustellversuch gibt?
Definiere "gemütlich" und "vernünftig".
Gesetzt den Fall, Du würdest einen Postfix-Smarthost hinstellen. Der
redet auf 50 Verbindungen gleichzeitig Server-SMTP und auf 1 bis 10
(Defaultkonfiguration) gleichzeitig Client-SMTP, siehe auch URL
oben. qmail würde 20 Verbindungen öffnen, Postfix bei der Annahme
Däumchen drehen und aus Langeweile schonmal die komplett angenommene
Mail ausliefern.
Wenn Dein qmail nur routet und keine lokale Zustellung vornimmt, ist es
auch effizienter, dann Postfix' qmqp-Server (prinzipiell jeden anderen,
ich kenne aber nur die von Postfix und Kuhmehl) zu nehmen und qmail per
QMQP an den Smarthost zustellen zu lassen, dann ist -- unter Vorbehalt,
aber AFAIR wird qmail-queue durch den qmail-qmqpc ersetzt -- qmail-send
nicht im Weg und kann folglich nicht aus Mail für a...@eine.domain und
b...@eine.domain zwei Sessions machen.
--
Matthias Andree