Dreckstool qmail
Lutz Donnerhacke
1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder "A".
Problem: Es gibt Domains, die mehr als drei Einträge unter dem FQDN
haben. Die Antwort ist dann größer als 512 Byte.
Akut tritt es hier durch DNSSEC Signaturen nach RfC 4033
(März 2005, inital RfC 2535 vom März 1999) auf.
2. Qmail implementiert EDNS nach RfC 2671 (August 1999) für größere UDP
Pakete nicht.
Problem: Antworten größer 512 Byte werden abgeschnitten und TC markiert.
3. Qmail implementiert den TCP Fallback nach RfC 1035 (November 1987) nicht.
Qmail kann mit der abgeschnittenen Antwort nichts anfangen und loggt
"CNAME_lookup_failed_temporarily._(#4.4.3)".
Dreckstool.
Arnim Sommer
> Klassischer Dreifachfehler in Sachen Dummheit.
>
>
> Dreckstool.
>
Nein, ist nicht gelistet.
A!S
--
Die Vier (Mail-)Server der Apokalypse:
Ken, David, Exchange und Notes.
(aus de.alt.sysadmin.recovery)
Lutz Donnerhacke
> Nein, ist nicht gelistet.
Das Posting ist der Versuch, den fehlenden Submit Button zu drücken.
Christian Winter
[...qmail-bugs gesnipped...]
>
> Dreckstool.
Ich weiß nicht, warum mich diese Schlußfolgerung nicht wirklich[TM]
überrascht. Auf der anderen Seite - ein Grund mehr für DNSSEC.
-Christian
Helmut Springer
[...qmail...]
> Dreckstool.
Jemand aus der Gemeinschaft der Glaeubigen hat bestimmt einen,
natuerlich von djb niemals unterstuetzten, patch dafuer geschrieben.
Da aber derartige Beitraege zum Werk des Herrn als Beleg des rechten
Glaubens angesehen werden, gleichzeitig der geringste Eindruck von
Maengeln in eben diesem Werk aber nicht statthaft ist, wirst Du ihn
nur nie finden. Wahrscheinlich solltest Du sogar froh darueber
sein...
--
MfG/Best regards
helmut springer
Juergen P. Meier
Florian Weimer
> 1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder "A".
Bittewas? Das *kann* doch nicht wahr sein.
Ah, das wird nur bei der RCPT-TO:-Kanonisierung nach RFC 1123 gemacht.
Aber bricht die Zustellung wirklich ab, wenn kein CNAME-Eintrag
gefunden werden konnte? Der Code sieht nicht danach aus (was bedeutet
eigentlich der Rückgabewert "2"?)
> 2. Qmail implementiert EDNS nach RfC 2671 (August 1999) für größere UDP
> Pakete nicht.
qmail verwendet den libc-Resolver, gibt ihm aber nur einen Puffer von
512 Bytes auf den Weg. Der libc-Resolver hat so keine Chance, mehr
Daten an qmail zu liefern.
> 3. Qmail implementiert den TCP Fallback nach RfC 1035 (November 1987) nicht.
BIND 9 als Resolver schickt eine abgeschnittene Antwort. Das sollte
qmail zufriedenstellen. Höchstens mit Bernsteins
Resolver-Approximation gibt es Probleme, weil diese eine leere Antwort
schickt (was ein genauso akzeptables Verhalten ist, aber eben nicht
kompatibel mit qmail ist).
Euer SPF-Eintrag ist übrigens fehlerhaft. Ist das Absicht?
Juergen P. Meier
> * Lutz Donnerhacke:
>
>> 1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder "A".
>
> Bittewas? Das *kann* doch nicht wahr sein.
Mach nen tcpdump wenn du es nicht glaubst (oder querylog im dns-server).
Der Unsinn hatte mich mal dazu animiert, unsinnig viel TXT RR zu
schicken bei IN ANY queries an jors.net. So rein aus Boshaftigkeit.
> Ah, das wird nur bei der RCPT-TO:-Kanonisierung nach RFC 1123 gemacht.
Was fuer einen outgoing-MTA bei aller externer Mail der Fall sein
muesste.
> Aber bricht die Zustellung wirklich ab, wenn kein CNAME-Eintrag
Dunno. Man kann ferne qmails mit komischen Antworten aber ganz schoen
verwirren, so dass sie einen nicht mehr laenger mit E-Mails belaestigen.
> gefunden werden konnte? Der Code sieht nicht danach aus (was bedeutet
> eigentlich der Rückgabewert "2"?)
>
>> 2. Qmail implementiert EDNS nach RfC 2671 (August 1999) für größere UDP
>> Pakete nicht.
>
> qmail verwendet den libc-Resolver, gibt ihm aber nur einen Puffer von
> 512 Bytes auf den Weg. Der libc-Resolver hat so keine Chance, mehr
> Daten an qmail zu liefern.
Es ist die Aufgabe des Clients, dass den libc Resolver verwendet, den
Fehlercode der Resolver-librarycalls zu evaluieren, diesen Umstand
festzustellen und es ggf. mit einen groesseren Buffer nochmal zu
versuchen (wenn die abgeschnittene Antwort nicht zufriedenstellend
war). Schliesslich will Kuhmail ja hier nicht nur den ersten IN A RR
haben, sondern muss die vollstaendige Antwort auswerten.
>> 3. Qmail implementiert den TCP Fallback nach RfC 1035 (November 1987) nicht.
>
> BIND 9 als Resolver schickt eine abgeschnittene Antwort. Das sollte
> qmail zufriedenstellen. Höchstens mit Bernsteins
> Resolver-Approximation gibt es Probleme, weil diese eine leere Antwort
> schickt (was ein genauso akzeptables Verhalten ist, aber eben nicht
> kompatibel mit qmail ist).
Das ist nicht wahr, oder? Wie konnte ich dieses Kleinod an Inkompetenz
bisher nur uebersehen? Das ist zu schoen um wahr zu sein.
> Euer SPF-Eintrag ist übrigens fehlerhaft. Ist das Absicht?
Ist der v6 Eintrag nicht richtig? Der rest ist zumindest korrekt so.
(SPFv1 syntax fuer IPv6 kenne ich schlicht nicht, daher kann ich das
nicht einschaetzen).
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Lutz Donnerhacke
> * Lutz Donnerhacke:
>> 1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder "A".
>
> Bittewas? Das *kann* doch nicht wahr sein.
Grund soll ein Bug in BIND 4.x sein.
Grund wird sein, daß djb den zweiten Lookup nach einem A Record vermied.
> Aber bricht die Zustellung wirklich ab, wenn kein CNAME-Eintrag
> gefunden werden konnte?
Ich nichts qmail, ich nur Beschwerdeannahmestelle von qmail-Admins, die
Beschwerdeannahmestelle von deren Nutzern.
> qmail verwendet den libc-Resolver, gibt ihm aber nur einen Puffer von
> 512 Bytes auf den Weg. Der libc-Resolver hat so keine Chance, mehr
> Daten an qmail zu liefern.
Noch besser. :-(
> BIND 9 als Resolver schickt eine abgeschnittene Antwort. Das sollte
> qmail zufriedenstellen. Höchstens mit Bernsteins
> Resolver-Approximation gibt es Probleme, weil diese eine leere Antwort
> schickt (was ein genauso akzeptables Verhalten ist, aber eben nicht
> kompatibel mit qmail ist).
Da wird letzteres der Fall sein.
> Euer SPF-Eintrag ist übrigens fehlerhaft. Ist das Absicht?
Nein. Fixed.
Florian Weimer
> * Florian Weimer wrote:
>> * Lutz Donnerhacke:
>>> 1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder "A".
>>
>> Bittewas? Das *kann* doch nicht wahr sein.
>
> Grund soll ein Bug in BIND 4.x sein.
Gute Ausrede, muß ich mir merken.
> Grund wird sein, daß djb den zweiten Lookup nach einem A Record vermied.
Den braucht er an dieser Stelle doch gar nicht. Letztlich ist sogar
egal, ob der CNAME-Eintrag irgendwo in die Pampa zeigt.
Gert Doering
> 2. Qmail implementiert EDNS nach RfC 2671 (August 1999) für größere UDP
> Pakete nicht.
Du willst mir jetzt nicht sagen, dass qmail auch noch einen eigenen
resolver mitbringt, und dieser natuerlich dann die Entwicklung der letzten
10 Jahre nicht mitgemacht hat, weil "ist nicht so, wie DJB sich das
vorgestellt hat, also wird's boykottiert"?
Andererseits waer's keine wirkliche Ueberraschung.
gert
--
Wege entstehen, wenn wir sie gehen. | gert doering
Vielleicht sollte ich meinen Beobachterposten | ge...@greenie.muc.de
an der Strassenkreuzung aufgeben. | 2:2480/55.4
Arnim Sommer
> * Arnim Sommer wrote:
>
>>Nein, ist nicht gelistet.
>
>
> Das Posting ist der Versuch, den fehlenden Submit Button zu drücken.
Ah, so desu.
4. $dreckstool hat keine _einfache_ Möglichkeit, Erweiterungen einzuhängen.
Lutz Donnerhacke
> Lutz Donnerhacke <lu...@iks-jena.de> writes:
>> 2. Qmail implementiert EDNS nach RfC 2671 (August 1999) für größere UDP
>> Pakete nicht.
>
> Du willst mir jetzt nicht sagen, dass qmail auch noch einen eigenen
> resolver mitbringt, und dieser natuerlich dann die Entwicklung der letzten
> 10 Jahre nicht mitgemacht hat, weil "ist nicht so, wie DJB sich das
> vorgestellt hat, also wird's boykottiert"?
Schlimmer: qmail mit bind zusammen bekommt die Anworten zwar gekürzt,
ignoriert die Fehlermeldung und nimmt den ersten brauchbaren Eintrag
in der Kurzfassung. Qmail mit djbdns bekommt von djbs höchsteigenem
Resolver gar keine Antwort, weil die ja nicht in den Puffer reinpaßt,
geht dann davon aus, daß ein CNAME nicht aufgelöst werden kann, also
loggt es ein temporäres CNAME Problem und empfiehlt in "Li[fv]e with
qmail" doch auf unterschiedliche Expires unterschiedlicher Recordset
zu warten, damit die spätere Anfrage an einen nichtauthoritiven Name-
server dann in den Puffer von qmail paßt.
Richtig verstanden, Florian?
BTW:
Sendmail hat im Spezialresolver für DNS-mapping-rules auch keinen
TCP Fallback. Das nutzen Spammer aus, um an bestimmten Testregeln
vorbei zu kommen. Beispielsweise mit einem MX auf einen FQDN, der
selbst 254 A Records hat.
Florian Weimer
> Du willst mir jetzt nicht sagen, dass qmail auch noch einen eigenen
> resolver mitbringt, und dieser natuerlich dann die Entwicklung der letzten
> 10 Jahre nicht mitgemacht hat, weil "ist nicht so, wie DJB sich das
> vorgestellt hat, also wird's boykottiert"?
Es gibt wohl so einen Patch, mit dem man den Stub-Resolver, der bei
tinydns dabei ist, in qmail hineinbekommt. Ich weiß nicht, ob das in
diesem Fall hilft.
Daniel Roesen
> Das ist nicht wahr, oder? Wie konnte ich dieses Kleinod an Inkompetenz
> bisher nur uebersehen? Das ist zu schoen um wahr zu sein.
Frevel! Dich wird die Heilige Inquisition treffen!
Ich finde qmail ist fuer eine gewisse Sorte Admins[1] genau das richtige
Tool.
Gruss,
Daniel
PS: die Sektenanhaenger die zuhause nen Maso-Shop betreiben
--
Ich finde, scharfe Waffen und "Feuern nach eigenem Ermessen" sollte zum
Adminjob dazugehören. [Lars Marowsky-Bree in d.a.s.r]
Daniel Roesen
> Es gibt wohl so einen Patch, [...]
Das DJB-User Mantra.
Gruss,
Daniel
Juergen P. Meier
> * Florian Weimer <f...@deneb.enyo.de>:
>> Es gibt wohl so einen Patch, [...]
>
> Das DJB-User Mantra.
Was passiert eigentlich, wenn man alle qmail-patches zusammen nimmt,
und alle Original DJB-Codezeilen entfernt? Hat man dann einen
funktionierenden, standardkonformen MTA?
Juergen
Timm Korte
> Was passiert eigentlich, wenn man alle qmail-patches zusammen nimmt,
> und alle Original DJB-Codezeilen entfernt? Hat man dann einen
> funktionierenden, standardkonformen MTA?
qmail-ldap?
*duck&run*
Timm
Felix von Leitner
> 1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder "A".
-> Latenzminimierung. Ist in meinen Augen ein Feature.
> Problem: Es gibt Domains, die mehr als drei Einträge unter dem FQDN
> haben. Die Antwort ist dann größer als 512 Byte.
> Akut tritt es hier durch DNSSEC Signaturen nach RfC 4033
> (März 2005, inital RfC 2535 vom März 1999) auf.
..
> 2. Qmail implementiert EDNS nach RfC 2671 (August 1999) für größere UDP
> Pakete nicht.
Ist ja auch nicht Aufgabe eines MX, DNS zu implementieren.
qmail benutzt den DNS aus der libc. Hat sich später als Fehler
herausgestellt, daher hat djb dann djbdns gehackt. Ist nur noch nicht
offiziell mit qmail integriert worden, aber jemand soll da wohl einen
Patch gemacht haben. Interessiert mich persönlich nicht sonderlich,
ehrlich gesagt.
> Problem: Antworten größer 512 Byte werden abgeschnitten und TC markiert.
Wo denn, bei iks-jena.de? Da kriege ich gerade folgenden Effekt:
$ host -t any iks-jena.de
[leeres Paket, truncated-Flag gesetzt]
und bei einem djbdns-Resolver kriege ich:
$ host -t any iks-jena.de
iks-jena.de name server euro-ns3.cw.net
iks-jena.de name server avalon.iks-jena.de
iks-jena.de name server jengate.thur.de
iks-jena.de name server euro-ns1.cw.net
iks-jena.de name server euro-ns2.cw.net
[ab da ist truncated]
$
Wer hat hier noch gleich behauptet, djbdns würde dann ein leeres Paket
verschicken?
> 3. Qmail implementiert den TCP Fallback nach RfC 1035 (November 1987) nicht.
> Qmail kann mit der abgeschnittenen Antwort nichts anfangen und loggt
> "CNAME_lookup_failed_temporarily._(#4.4.3)".
Nicht qmail, sondern die libc kann das dann offensichtlich nicht.
Heul den libc-Implementierer an, wenn du das brauchst. Wenn du die diet
libc verwendest, bist du herzlich eingeladen, einen funktionierenden
Patch zu submitten.
Felix
Lutz Donnerhacke
> Thus spake Lutz Donnerhacke (lu...@iks-jena.de):
>> 1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder "A".
>
> -> Latenzminimierung. Ist in meinen Augen ein Feature.
Dann sollte man es wenigstens richtig machen.
>> 2. Qmail implementiert EDNS nach RfC 2671 (August 1999) für größere UDP
>> Pakete nicht.
>
> Ist ja auch nicht Aufgabe eines MX, DNS zu implementieren.
> qmail benutzt den DNS aus der libc. Hat sich später als Fehler
> herausgestellt, daher hat djb dann djbdns gehackt. Ist nur noch nicht
> offiziell mit qmail integriert worden, aber jemand soll da wohl einen
> Patch gemacht haben. Interessiert mich persönlich nicht sonderlich,
> ehrlich gesagt.
Nochmal für einen geistig blockierten Fanatiker, wie Dich:
- qmail fragt die libc mit einem 512 byte buffer
- ignoriertert die API return codes, die mehr Platz fordern
- parst den Response
- wenn das Parsen fehlschlägt, nimmt es CNAME Fehler an.
qmail mit einem bind resolver bekommt eine abgeschnittene Response in den
Puffer gefüllt und ist meistens glücklich.
qmail mit eine djbdns resolver bekommt eine leere Response und plappert
CNAME Scheiße.
qmail mit eingebauten djbdns (patch) resolver, bekommt eine leere Response ...
>> Problem: Antworten größer 512 Byte werden abgeschnitten und TC markiert.
>
> Wo denn, bei iks-jena.de? Da kriege ich gerade folgenden Effekt:
>
> $ host -t any iks-jena.de
> [leeres Paket, truncated-Flag gesetzt]
Dein Resolver ist von djb.
> und bei einem djbdns-Resolver kriege ich:
>
> $ host -t any iks-jena.de
> iks-jena.de name server euro-ns3.cw.net
> iks-jena.de name server avalon.iks-jena.de
> iks-jena.de name server jengate.thur.de
> iks-jena.de name server euro-ns1.cw.net
> iks-jena.de name server euro-ns2.cw.net
> [ab da ist truncated]
> $
Dein Resolver ist kaputt. Das TC Flag ist gesetzt.
> Wer hat hier noch gleich behauptet, djbdns würde dann ein leeres Paket
> verschicken?
Florian.
>> 3. Qmail implementiert den TCP Fallback nach RfC 1035 (November 1987) nicht.
>> Qmail kann mit der abgeschnittenen Antwort nichts anfangen und loggt
>> "CNAME_lookup_failed_temporarily._(#4.4.3)".
>
> Nicht qmail, sondern die libc kann das dann offensichtlich nicht.
Wie füllst Du in einen 512 byte Puffer eine Datenmenge größer 512 Byte ein?
Warum sollte man TCP machen, wenn der Puffer eh zu klein ist?
> Heul den libc-Implementierer an, wenn du das brauchst. Wenn du die diet
> libc verwendest, bist du herzlich eingeladen, einen funktionierenden
> Patch zu submitten.
"rm -rf qmail*" ist leider nicht akzeptiert worden.
Florian Weimer
> Wer hat hier noch gleich behauptet, djbdns würde dann ein leeres Paket
> verschicken?
Bernstein, auf seinen Webseiten.
> Nicht qmail, sondern die libc kann das dann offensichtlich nicht.
Wenn qmail nur PACKETSZ Bytes bereitstellt, kann die libc so viel
TCP-Fallback machen, wie sie will. Sie kann ihre zusätzlichen
Erkenntnisse nicht an die Anwendung weitergeben.
Rolf Eike Beer
> * Lutz Donnerhacke:
>
>> 1. Beim Mailzustellen fragt qmail nach "ANY", statt nach "MX" oder
>> "A".
>
> Bittewas? Das *kann* doch nicht wahr sein.
>
> Ah, das wird nur bei der RCPT-TO:-Kanonisierung nach RFC 1123 gemacht.
> Aber bricht die Zustellung wirklich ab, wenn kein CNAME-Eintrag
> gefunden werden konnte? Der Code sieht nicht danach aus (was bedeutet
> eigentlich der Rückgabewert "2"?)
So wie es aussieht etwas in der Art "ich habe keine neuen Antworten, ob
das ein Fehler ist musst du selbst wissen".
Eike
Rolf Eike Beer
> Lutz Donnerhacke schrieb:
>> * Arnim Sommer wrote:
>>
>>>Nein, ist nicht gelistet.
>>
>>
>> Das Posting ist der Versuch, den fehlenden Submit Button zu drücken.
>
> Ah, so desu.
> 4. $dreckstool hat keine _einfache_ Möglichkeit, Erweiterungen
> einzuhängen.
Nimm Qsmtp :)
Eike
Arnim Sommer
Felix von Leitner
> >> Pakete nicht.
> > Ist ja auch nicht Aufgabe eines MX, DNS zu implementieren.
> > qmail benutzt den DNS aus der libc. Hat sich später als Fehler
> > herausgestellt, daher hat djb dann djbdns gehackt. Ist nur noch nicht
> > offiziell mit qmail integriert worden, aber jemand soll da wohl einen
> > Patch gemacht haben. Interessiert mich persönlich nicht sonderlich,
> > ehrlich gesagt.
> Nochmal für einen geistig blockierten Fanatiker, wie Dich:
> - qmail fragt die libc mit einem 512 byte buffer
Nicht bei mir. Das ist das erste, was man patch. Das war auch einer
der ersten qmail-Patches, weil AOL 199irgendwann oversize Records
verschickt hat und dann nicht mit qmail reden konnte.
Ist in net-qmail vergrößert. Das ist die Version, die dir auf der
qmail-Mailingliste empfohlen worden wäre, wenn du vor dem Rumheulen dort
aufgeschlagen wärest.
> - ignoriertert die API return codes, die mehr Platz fordern
Ich weiß ja nicht, von welcher API du da redest. Hier ist die
Dokumentation des DNS-API, das qmail benutzt:
RETURN VALUE
The res_query(), res_search(), res_querydomain(), res_mkquery() and
res_send() functions return the length of the response, or -1 if an
error occurs.
Der Return-Code sagt dir offensichtlich nicht, daß da was abgeschnitten
wurde. Also mir sagt er das nicht. Vielleicht hast du da ja erweiterte
Einblicksmöglichkeiten als ich.
> - parst den Response
ACK.
> - wenn das Parsen fehlschlägt, nimmt es CNAME Fehler an.
Na ob da jetzt "DNS kaputt" oder "CNAME Fehler" steht, das ist Kosmetik.
Da kann man drüber argumentieren, aber das ist nicht das eigentliche
Problem, sondern das Symptom. Ich habe gerade keine Zeit, mich mit dir
über Symptome zu streiten. Ich möchte lieber auf das eigentliche
Problem hinweisen: Du schickst zu lange DNS-Antworten :-)
> qmail mit einem bind resolver bekommt eine abgeschnittene Response in den
> Puffer gefüllt und ist meistens glücklich.
> qmail mit eine djbdns resolver bekommt eine leere Response und plappert
> CNAME Scheiße.
Das halte ich für ein Gerücht. Mein djbdns zumindest schickt keine
leere Response, wenn ich ihn -t any nach iks-jena.de befrage.
> qmail mit eingebauten djbdns (patch) resolver, bekommt eine leere Response ...
Hast du den Patch tatsächlich mal reingepatcht? War mir zu nervig.
> >> Problem: Antworten größer 512 Byte werden abgeschnitten und TC markiert.
> > Wo denn, bei iks-jena.de? Da kriege ich gerade folgenden Effekt:
> >
> > $ host -t any iks-jena.de
> > [leeres Paket, truncated-Flag gesetzt]
> Dein Resolver ist von djb.
Nein. Das ist der Trivial-Stub-Resolver von der diet libc.
> > und bei einem djbdns-Resolver kriege ich:
> > $ host -t any iks-jena.de
> > iks-jena.de name server euro-ns3.cw.net
> > iks-jena.de name server avalon.iks-jena.de
> > iks-jena.de name server jengate.thur.de
> > iks-jena.de name server euro-ns1.cw.net
> > iks-jena.de name server euro-ns2.cw.net
> > [ab da ist truncated]
> > $
> Dein Resolver ist kaputt. Das TC Flag ist gesetzt.
Die Frage war nicht, ob TC gesetzt ist, sondern ob djbdns eine leere
Antwort schickt. Das ist offensichtlich nicht der Fall.
Das host hier ist ein selbstgehacktes, das ebenfalls den dietlibc Stub
Resolver benutzt, und TC nicht checkt.
> > Wer hat hier noch gleich behauptet, djbdns würde dann ein leeres Paket
> > verschicken?
> Florian.
Ich würde sagen: Er irrt. Oder es gab da ein Mißverständnis.
> >> 3. Qmail implementiert den TCP Fallback nach RfC 1035 (November 1987) nicht.
> >> Qmail kann mit der abgeschnittenen Antwort nichts anfangen und loggt
> >> "CNAME_lookup_failed_temporarily._(#4.4.3)".
> > Nicht qmail, sondern die libc kann das dann offensichtlich nicht.
> Wie füllst Du in einen 512 byte Puffer eine Datenmenge größer 512 Byte ein?
> Warum sollte man TCP machen, wenn der Puffer eh zu klein ist?
Ich sehe das mit dem truncate nicht so tragisch. Normalerweise paßt der
interessante Teil in das Paket und nur der Aux-Blah am Ende paßt nicht.
Und den braucht qmail ja eh nicht, um Mail zuzustellen.
Ich persönlich sehe da im Moment keinen Handlungsbedarf. Du spielst da
mit DNSSEC, von dem ja völlig klar ist, daß es wertlos ist, und dabei
gehen Sachen kaputt. Jetzt projizierst du deinen Ärger auf die kaputt
gehenden Sachen, dabei ist doch dein DNSSEC-Experimentieren die
eigentlich ärgerliche Sache, die Zeitverschwendung.
Fel"Freud"ix
Lutz Donnerhacke
>
> Nicht bei mir. Das ist das erste, was man patch. Das war auch einer
> der ersten qmail-Patches, weil AOL 199irgendwann oversize Records
> verschickt hat und dann nicht mit qmail reden konnte.
Die Leute, die unseren Kunden Mails schicken wollen, tun das nicht.
So what? Ich setze kein qmail ein. Soviel Anstand habe ich.
> Ist in net-qmail vergrößert. Das ist die Version, die dir auf der
> qmail-Mailingliste empfohlen worden wäre, wenn du vor dem Rumheulen dort
> aufgeschlagen wärest.
Die Kunden unserer Kunden heulen sich bei mir aus. Was soll man da tun?
Deren ISP zum Teufel jagen? Gern.
>> - ignoriertert die API return codes, die mehr Platz fordern
>
> Ich weiß ja nicht, von welcher API du da redest. Hier ist die
> Dokumentation des DNS-API, das qmail benutzt:
>
> RETURN VALUE
> The res_query(), res_search(), res_querydomain(), res_mkquery() and
> res_send() functions return the length of the response, or -1 if an
> error occurs.
>
> Der Return-Code sagt dir offensichtlich nicht, daß da was abgeschnitten
> wurde. Also mir sagt er das nicht. Vielleicht hast du da ja erweiterte
> Einblicksmöglichkeiten als ich.
Was denkst Du, ist die Bedeutung von einem Returncode, der gleich der
Puffergröße ist? Du hast das gleiche Problem bei einem simplen read(2) oder
bei einem ältern snprintf(3). Wenn man schon bei solche elementarer
Verarbeitung externer Daten konzeptionell überfordert ist, sollte man keinen
MTA schreiben. YMMV.
>> - wenn das Parsen fehlschlägt, nimmt es CNAME Fehler an.
>
> Na ob da jetzt "DNS kaputt" oder "CNAME Fehler" steht, das ist Kosmetik.
Nicht für den Endanwender. Der hat die Fehlermeldung auf dem Bildschirm.
> Da kann man drüber argumentieren, aber das ist nicht das eigentliche
> Problem, sondern das Symptom. Ich habe gerade keine Zeit, mich mit dir
> über Symptome zu streiten. Ich möchte lieber auf das eigentliche
> Problem hinweisen: Du schickst zu lange DNS-Antworten :-)
Das Problem besteht darin, daß qmail kaputt ist. Man fragt nicht nach "ANY"
und stellt unzureichend Platz bereit.
>> qmail mit einem bind resolver bekommt eine abgeschnittene Response in den
>> Puffer gefüllt und ist meistens glücklich.
>
>> qmail mit eine djbdns resolver bekommt eine leere Response und plappert
>> CNAME Scheiße.
>
> Das halte ich für ein Gerücht. Mein djbdns zumindest schickt keine
> leere Response, wenn ich ihn -t any nach iks-jena.de befrage.
Frage ihn mit zu kleinem Puffer via res_query.
Falls Du mit dem C Code überfordert sein solltest, hier etwas Startcode.
$ cat > test.c <<END
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
#include <stdio.h>
void main(int argc, char *argv[]) {
size_t len = atoi(argv[1]);
char *buff = malloc(len);
printf("init: %d\n", res_init());
printf("search(%s,%d): %d\n", argv[2], len,
res_query(argv[2], ns_t_any, ns_c_in, buff, len));
}
END
$ cc -o test test.c -lresolv
$ ./test 100 iks-jena.de
init: 0
search(iks-jena.de,100): 100
$ ./test 1000 iks-jena.de
init: 0
search(iks-jena.de,1000): 276
$./test 276 iks-jena.de
init: 0
search(iks-jena.de,276): 276
$ ./test 277 iks-jena.de
init: 0
search(iks-jena.de,277): 276
>> qmail mit eingebauten djbdns (patch) resolver, bekommt eine leere
>> Response ...
>
> Hast du den Patch tatsächlich mal reingepatcht? War mir zu nervig.
Nein. Ich ekle mich schon vor qmail selbst.
>> > $ host -t any iks-jena.de
>> > [leeres Paket, truncated-Flag gesetzt]
>> Dein Resolver ist von djb.
>
> Nein. Das ist der Trivial-Stub-Resolver von der diet libc.
Das Verhalten ist zulässig, führt aber zu dem genannten Problem mit qmail.
>> Dein Resolver ist kaputt. Das TC Flag ist gesetzt.
>
> Die Frage war nicht, ob TC gesetzt ist, sondern ob djbdns eine leere
> Antwort schickt. Das ist offensichtlich nicht der Fall.
Interessant. Offenbar sind nur Kunden betroffen, die qmail mit dietlibc
einsetzen ;-)
>> > Nicht qmail, sondern die libc kann das dann offensichtlich nicht.
>> Wie füllst Du in einen 512 byte Puffer eine Datenmenge größer 512 Byte ein?
>> Warum sollte man TCP machen, wenn der Puffer eh zu klein ist?
>
> Ich sehe das mit dem truncate nicht so tragisch. Normalerweise paßt der
> interessante Teil in das Paket und nur der Aux-Blah am Ende paßt nicht.
> Und den braucht qmail ja eh nicht, um Mail zuzustellen.
qmail scheitert offenbar trotzdem mit dieser Haltung.
> Ich persönlich sehe da im Moment keinen Handlungsbedarf. Du spielst da
> mit DNSSEC, von dem ja völlig klar ist, daß es wertlos ist, und dabei
> gehen Sachen kaputt. Jetzt projizierst du deinen Ärger auf die kaputt
> gehenden Sachen, dabei ist doch dein DNSSEC-Experimentieren die
> eigentlich ärgerliche Sache, die Zeitverschwendung.
Du spielst mit einem Plonk.
Felix von Leitner
> > leere Response, wenn ich ihn -t any nach iks-jena.de befrage.
> Frage ihn mit zu kleinem Puffer via res_query.
Äh, solche Fragen klärt man mit tcpdump, nicht mit res_query.
> Falls Du mit dem C Code überfordert sein solltest,
"No... fuck YOU!" :-)
> hier etwas Startcode.
> $ ./test 100 iks-jena.de
> init: 0
> search(iks-jena.de,100): 100
init: 0
search(iks-jena.de,100): 45
..?
Und überhaupt: das kann ja trotzdem abgeschnitten sein. Vielleicht gibt
mir der libc-resolver lieber nur ganze Records. Der Return Code sagt
dir das nicht.
Und mehrfach aufrufen ist auch keine Lösung, falls du darauf jetzt
argumentativ heraus wolltest, weil der Gegenüber natürlich dynamische
Antworten mit Lebenszeit 0 rausgeben kann.
> Nein. Ich ekle mich schon vor qmail selbst.
Ach weißt du, ...
$ host -t mx iks-jena.de
iks-jena.de mail is handled (pri=10) by excalibur.iks-jena.de
iks-jena.de mail is handled (pri=20) by avalon.iks-jena.de
additional:
avalon.iks-jena.de has address 217.17.192.66
excalibur.iks-jena.de has address 217.17.192.67
excalibur.iks-jena.de IPv6 address 2001:4bd8::17
$ telnet excalibur.iks-jena.de 25
220 excalibur.iks-jena.de ESMTP Sendmail 8.13.5/8.13.1; Thu, 23 Feb 2006 06:55:04 +0100
quit
Wer _Sendmail_ fährt, sollte man GANZ leise sein, wenn es um Ästhetik,
Schönheit oder Geschmack geht.
> Interessant. Offenbar sind nur Kunden betroffen, die qmail mit dietlibc
> einsetzen ;-)
Hihi, ich fühle mich geehrt :-)
> > Ich sehe das mit dem truncate nicht so tragisch. Normalerweise paßt der
> > interessante Teil in das Paket und nur der Aux-Blah am Ende paßt nicht.
> > Und den braucht qmail ja eh nicht, um Mail zuzustellen.
> qmail scheitert offenbar trotzdem mit dieser Haltung.
Also mein qmail kann mit djbdns Mail an dich zustellen, auch mit Buffer
512 Bytes. Ich sehe nicht, wo das Problem ist. Ich vermute
irgendwelche kaputten DNS-Proxy-Kaskaden zwischen dir und dem heulenden
Peer.
> > Ich persönlich sehe da im Moment keinen Handlungsbedarf. Du spielst da
> > mit DNSSEC, von dem ja völlig klar ist, daß es wertlos ist, und dabei
> > gehen Sachen kaputt. Jetzt projizierst du deinen Ärger auf die kaputt
> > gehenden Sachen, dabei ist doch dein DNSSEC-Experimentieren die
> > eigentlich ärgerliche Sache, die Zeitverschwendung.
> Du spielst mit einem Plonk.
:-)
Felix
--
A blow with a word strikes deeper than a blow with a sword.
--Robert Burton, English author and clergyman (1577-1640)
Daniel Albuschat
>>Ah, so desu.
-h
Arnim Sommer
> Rolf Eike Beer wrote:
>
>>> Ah, so desu.
>
>
> -h
Japanisch.
"Ach, so ist das!"
Rolf Eike Beer
> Rolf Eike Beer wrote:
>
>>>Ah, so desu.
>
> -h
Könntest du bitte weniger Sinn entstellend quoten?
Eike
Volker Birk
> Wer _Sendmail_ fährt, sollte man GANZ leise sein, wenn es um Ästhetik,
> Schönheit oder Geschmack geht.
Wieso? Mann muss ja kein M4 verwenden.
Viele Grüße,
VB.
--
Wenn Du "Ich sehe die Mathematik als einzigen Bereich an, wo es klare
Beweise gibt." und "Ich fuehle mich in einem Anzug unwohl." als Aussagen
mit aequivalentem Meinungsinhalt betrachtest, hast Du mit Deinem Gleichnis
recht. (Michail Bachmann zu Thomas Wallutis in d.a.s.r)
Tobias Wolter
> Daniel Albuschat schrieb:
>> Rolf Eike Beer wrote:
>>>> Ah, so desu.
>> -h
> Japanisch.
> "Ach, so ist das!"
Wobei es, rein technisch, "aa, sou desu" heissen muesste.
-to 'Dehnungsvokale sind der Horror' wo
--
Mister Teatime had a truly brilliant mind, but it was brilliant like a frac-
tured mirror, all marvellous facets and rainbows but, ultimately, also some-
thing that was broken. (Terry Pratchett in `Hogfather')
Arnim Sommer
> On 2006-02-24, Arnim Sommer wrote:
>
>>Daniel Albuschat schrieb:
>>
>>>Rolf Eike Beer wrote:
>>>
>>>>>Ah, so desu.
>>>
>>>-h
>>
>>Japanisch.
>>"Ach, so ist das!"
>
>
> Wobei es, rein technisch, "aa, sou desu" heissen muesste.
>
übereinander herfällt, man hier durchaus etwas lernen kann.
A!S
Volker Birk
> Wobei es, rein technisch, "aa, sou desu" heissen muesste.
Hört sich irgendwie an wie gelalltes ErZwoDeZwo.
Dietz Proepper
> Felix von Leitner <usenet-...@fefe.de> wrote:
>> Wer _Sendmail_ fährt, sollte man GANZ leise sein, wenn es um Ästhetik,
>> Schönheit oder Geschmack geht.
>
> Wieso? Mann muss ja kein M4 verwenden.
Ähem, Volker, Du mußt jetzt stark sein. OK? Halt' Dich fest:
ES GIBT MÄNNER DIE NICHT AUF SCHMERZEN STEHEN!
Volker Birk
Echte Männer?
Tobias Wolter
> Tobias Wolter <to...@nurfuerspam.de> wrote:
>> Wobei es, rein technisch, "aa, sou desu" heissen muesste.
> Hört sich irgendwie an wie gelalltes ErZwoDeZwo.
Chinesisch eher, Japanisch hat oft laengerere Woerter.
-towo
Ansgar -59cobalt- Wiechers
> Tobias Wolter <to...@nurfuerspam.de> wrote:
>> Wobei es, rein technisch, "aa, sou desu" heissen muesste.
>
> Hört sich irgendwie an wie gelalltes ErZwoDeZwo.
iie.
cu
59cobalt
--
"Der Computer ist da, um zu rechnen, nicht um Ausreden wie 'Kann nicht
durch Null teilen' auf den Bildschirm zu schreiben."
--Marco Haschka in de.org.ccc
Ansgar -59cobalt- Wiechers
> Dietz Proepper <dietz...@rotfl.franken.de> wrote:
>> Volker Birk wrote:
>>> Felix von Leitner <usenet-...@fefe.de> wrote:
>>>> Wer _Sendmail_ fährt, sollte man GANZ leise sein, wenn es um
>>>> Ästhetik, Schönheit oder Geschmack geht.
>>>
>>> Wieso? Mann muss ja kein M4 verwenden.
>>
>> Ähem, Volker, Du mußt jetzt stark sein. OK? Halt' Dich fest:
>> ES GIBT MÄNNER DIE NICHT AUF SCHMERZEN STEHEN!
>
> Echte Männer?
Ganz besonders echte Männer. Und große blonde Frauen.
Dietz Proepper
> Dietz Proepper <dietz...@rotfl.franken.de> wrote:
>> Volker Birk wrote:
>> > Felix von Leitner <usenet-...@fefe.de> wrote:
>> >> Wer _Sendmail_ fährt, sollte man GANZ leise sein, wenn es um Ästhetik,
>> >> Schönheit oder Geschmack geht.
>> > Wieso? Mann muss ja kein M4 verwenden.
>> Ähem, Volker, Du mußt jetzt stark sein. OK? Halt' Dich fest:
>> ES GIBT MÄNNER DIE NICHT AUF SCHMERZEN STEHEN!
>
> Echte Männer?
Echte Männer fügen Schmerzen zu. Ggf.
Felix von Leitner
> > Wer _Sendmail_ fährt, sollte man GANZ leise sein, wenn es um Ästhetik,
> > Schönheit oder Geschmack geht.
> Wieso? Mann muss ja kein M4 verwenden.
Versteh mich nicht falsch, als Programmiersprache hat sendmail durchaus
Hack Value. Ich habe damit mal 99 beers implementiert, ich weiß, wovon
ich rede.
Aber für Mail? Um Gottes Willen
Felix
Volker Birk
Genau das wollte ich sagen. Oder vielmehr natürlich: OMN!
;-)
Viele Grüße,
V - für Mail vor Jahren tatsächlich sendmail eingesetzt habend - B.
Tobias Wolter
Nein, das waren die Leute, vor denen Schafe Angst haben.
Andreas Scherbaum
> V - für Mail vor Jahren tatsächlich sendmail eingesetzt habend - B.
So vor Urzeiten, als es nichts anderes gab, war das tatsächlich in.
Aber dann kam so hübsche Software wie Postschlumpf oder Exim, dann
wollte man eigentlich kein sendmail mehr nutzen.
Ach so, wir lästern über qmail?
Ob ich nun M4 hacke oder Hunderte mehr oder weniger schlecht dokumentierte
einzeilige Configfiles ändern muss ... Ok, in qmail kann Fefe kein
'99 beers' hacken. Das ist schlecht ...
Schönne Sonntag ansonsten noch
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Arnim Sommer
>
> Versteh mich nicht falsch, als Programmiersprache hat sendmail durchaus
> Hack Value. Ich habe damit mal 99 beers implementiert, ich weiß, wovon
> ich rede.
>
Ulrich Schwarz
> Felix von Leitner schrieb:
>>
>> Versteh mich nicht falsch, als Programmiersprache hat sendmail durchaus
>> Hack Value. Ich habe damit mal 99 beers implementiert, ich weiß, wovon
>> ich rede.
>>
> Macht man das nicht besser in TeX?
Nö, zu trivial. Es sei denn, es soll vollständig expandieren;
Schleifen ohne Seiteneffekte sind etwas schwieriger.
Ulrich
--
Reiß Bäume aus. Du bist der Baum. DU BIST DEUTSCHLAND!
Kurt Bernhard Pruenner
> Volker Birk wrote:
> > Tobias Wolter <to...@nurfuerspam.de> wrote:
> > > Wobei es, rein technisch, "aa, sou desu" heissen muesste.
> >
> > Hört sich irgendwie an wie gelalltes ErZwoDeZwo.
>
> iie.
Ist es schlimm, wenn man eher an einen Redmonder "Browser" als an "nein"
denkt wenn man das liest? o_O;
--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
np: Jah Wobble - Fly 11 (Fly)
Kurt Bernhard Pruenner
> Oder vielmehr natürlich: OMN!
Open Mic Night?
--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
np: Sten - Are You A Doctor (Leaving The Frantic)
Florian Weimer
> Schlimmer: qmail mit bind zusammen bekommt die Anworten zwar gekürzt,
> ignoriert die Fehlermeldung und nimmt den ersten brauchbaren Eintrag
> in der Kurzfassung. Qmail mit djbdns bekommt von djbs höchsteigenem
> Resolver gar keine Antwort, weil die ja nicht in den Puffer reinpaßt,
> geht dann davon aus, daß ein CNAME nicht aufgelöst werden kann, also
> loggt es ein temporäres CNAME Problem und empfiehlt in "Li[fv]e with
> qmail" doch auf unterschiedliche Expires unterschiedlicher Recordset
> zu warten, damit die spätere Anfrage an einen nichtauthoritiven Name-
> server dann in den Puffer von qmail paßt.
>
> Richtig verstanden, Florian?
Das ist jedenfalls die von mir vermutete Erklärung.
Auf namedroppers melden sich schon Stimmen, die von Resolvern
verlangen wollen, daß DNSSEC-Datensetze ausgefiltert werden (es sei
denn, DNSSEC ist aktiv). Natürlich hilft das im vorliegenden Fall
genau gar nichts, weil qmail und djbdns seit Jahren vollständig
ungepflegt sind.
Felix von Leitner
> > Versteh mich nicht falsch, als Programmiersprache hat sendmail durchaus
> > Hack Value. Ich habe damit mal 99 beers implementiert, ich weiß, wovon
> > ich rede.
> Macht man das nicht besser in TeX?
Das macht man in allen Sprachen, in denen es möglich ist.
Felix
Oliver Schad
> Volker Birk wrote:
>> Oder vielmehr natürlich: OMN!
>
> Open Mic Night?
Nein: "Oma! Mach dich nackig!"
mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.
Volker Birk
> Volker Birk wrote:
> > Oder vielmehr natürlich: OMN!
> Open Mic Night?
Oh My Noodles!
VB.
Andreas Krey
>> Open Mic Night?
>
> Oh My Noodles!
Bei 'Nuts' hätte ich den Plural ja verstanden.
Andreas
--
np: 4'33
Ansgar -59cobalt- Wiechers
> Ansgar -59cobalt- Wiechers wrote:
>> Volker Birk wrote:
>>> Tobias Wolter <to...@nurfuerspam.de> wrote:
>>>> Wobei es, rein technisch, "aa, sou desu" heissen muesste.
>>>
>>> Hört sich irgendwie an wie gelalltes ErZwoDeZwo.
>>
>> iie.
>
> Ist es schlimm, wenn man eher an einen Redmonder "Browser" als an
> "nein" denkt wenn man das liest? o_O;
Zumindest lässt es auf eine traumatische Erfahrung schließen. :3