ezmlm warning
Harald Muehlboeck
Ich bekomme von einigen Maillinglisten z.B gestern von
Bugtraq immer wieder mal (alle 2 bis 3 Wochen) ezmlm Warnings, in
denen steht einige Mails an meine Adresse <ne...@clef.at> wüden
boucen.
,----
| Hi! This is the ezmlm program. I'm managing the
| bug...@securityfocus.com mailing list.
|
| [...]
|
| Messages to you from the bugtraq mailing list seem to
| have been bouncing. I've attached a copy of the first bounce
| message I received.
|
| [... Erklärung, wie ich die nicht zugestellten Mails aus dem Archiv
| nachladen kann ...]
|
|
| --- Enclosed is a copy of the bounce message I received.
|
| Return-Path: <>
| Received: (qmail 5344 invoked from network); 19 Oct 2002 05:28:21 -0000
| Received: from unknown (HELO securityfocus.com) (205.206.231.9)
| by lists.securityfocus.com with SMTP; 19 Oct 2002 05:28:21 -0000
| Received: (qmail 15554 invoked by alias); 19 Oct 2002 05:28:07 -0000
| Received: (qmail 8817 invoked from network); 19 Oct 2002 05:08:56 -0000
| Received: from outgoing3.securityfocus.com (HELO outgoing.securityfocus.com) (205.206.231.27)
| by mail.securityfocus.com with SMTP; 19 Oct 2002 05:08:56 -0000
| Received: by outgoing.securityfocus.com (Postfix)
| id F17D1A9CDF; Fri, 18 Oct 2002 22:36:43 -0600 (MDT)
| Date: Fri, 18 Oct 2002 22:36:43 -0600 (MDT)
| From: MAILER...@outgoing.securityfocus.com (Mail Delivery System)
| Subject: Undelivered Mail Returned to Sender
| To: bugtraq-return-6922-news=cle...@securityfocus.com
| MIME-Version: 1.0
| Content-Type: multipart/report; report-type=delivery-status;
| boundary="B2CCAA36C6.1035002074/outgoing.securityfocus.com"
| Message-Id: <200210190436...@outgoing.securityfocus.com>
|
| This is a MIME-encapsulated message.
|
| --B2CCAA36C6.1035002074/outgoing.securityfocus.com
| Content-Description: Notification
| Content-Type: text/plain
|
| This is the Postfix program at host outgoing.securityfocus.com.
|
| I'm sorry to have to inform you that the message returned
| below could not be delivered to one or more destinations.
|
| For further assistance, please send mail to <postmaster>
|
| If you do so, please include this problem report. You can
| delete your own text from the message returned below.
|
| The Postfix program
|
| <ne...@clef.at>: Name service error for clef.at: Host found but no data record
| of requested type
|
| --B2CCAA36C6.1035002074/outgoing.securityfocus.com
| Content-Description: Delivery error report
| Content-Type: message/delivery-status
|
| Reporting-MTA: dns; outgoing.securityfocus.com
| Arrival-Date: Fri, 18 Oct 2002 16:23:48 -0600 (MDT)
|
| Final-Recipient: rfc822; ne...@clef.at
| Action: failed
| Status: 5.0.0
| Diagnostic-Code: X-Postfix; Name service error for clef.at: Host found but no
| data record of requested type
|
| --B2CCAA36C6.1035002074/outgoing.securityfocus.com
| Content-Description: Undelivered Message
| Content-Type: message/rfc822
|
| Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19])
| by outgoing.securityfocus.com (Postfix) with QMQP
| id B2CCAA36C6; Fri, 18 Oct 2002 16:23:48 -0600 (MDT)
| Mailing-List: contact bugtra...@securityfocus.com; run by ezmlm
| Precedence: bulk
| List-Id: <bugtraq.list-id.securityfocus.com>
| List-Post: <mailto:bug...@securityfocus.com>
| List-Help: <mailto:bugtra...@securityfocus.com>
| List-Unsubscribe: <mailto:bugtraq-u...@securityfocus.com>
| List-Subscribe: <mailto:bugtraq-...@securityfocus.com>
| Delivered-To: mailing list bug...@securityfocus.com
| Delivered-To: moderator for bug...@securityfocus.com
| Received: (qmail 5113 invoked from network); 18 Oct 2002 20:30:23 -0000
| Message-ID: <04d801c276e8$c1b881e0$0700...@apl.qfis.net>
| From: "Alex Lambert" <alam...@webmaster.com>
| To: "David Krum" <frob...@msn.com>, <bug...@securityfocus.com>
| References: <F14e8tlMazUSx...@hotmail.com>
| Subject: Re: KaZaA
| Date: Fri, 18 Oct 2002 15:55:57 -0500
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="iso-8859-1"
| Content-Transfer-Encoding: 7bit
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Mailer: Microsoft Outlook Express 5.50.4522.1200
| X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
|
|
| Kazaa's IE [....]
| [Text enthält keine Umalute, Sonderziechen, usw, Anm]
|
| --B2CCAA36C6.1035002074/outgoing.securityfocus.com--
`----
Ist es normal, dass die Mailadresse halt nicht immer geht? Gibt es
vielleicht Sytaxfehler im Mail, die die Zustellung verhindern?
Was bedeutet diese Fehlermeldung?
| Diagnostic-Code: X-Postfix; Name service error for clef.at: Host found but no
| data record of requested type
Ich habe schon vor ein paar Monaten eine solche Meldung an den
Support meines Providers[1] weitergeleitet.
Die konnten damit aber nichts anfangen. Quota dürften aber nicht voll
sein o.ä.
Wäre nett, wenn mir jemand sagen könnte, was ich tun muss um
sicherzustellen, dass meine E-Mailadresse zuverlässig funktioniert.
TIA,
Harald
Fußnoten:
=========
[1] Sind die Überhaupt zuständig? Wenn nicht, bin ich hier wohl OT. f'up
wohin?
Guenther Fuchs
> Ist es normal, dass die Mailadresse halt nicht immer geht?
Nein.
> Was bedeutet diese Fehlermeldung?
>| Diagnostic-Code: X-Postfix; Name service error for clef.at: Host found
>| but no data record of requested type
Daß der DNS Deines Providers - zumindest temporär - keinen gültigen Eintrag
für den abgefragten typ (vermutlich: MX, also Mail Exchanger) hatte. Dies
würde ich als groben Fehler bezeichnen.
> Ich habe schon vor ein paar Monaten eine solche Meldung an den
> Support meines Providers[1] weitergeleitet.
> Die konnten damit aber nichts anfangen.
In diesem Fall würde ich empfehlen, einen Providerwechsel anzudenken.
Zumindest Fehlermeldungen _lesen_ können sollte ein seriöser, kompetenter
Provider schon können ...
> Quota dürften aber nicht voll sein o.ä.
Ist ja auch nicht die Ursache - laut Fehlermeldung ist hier eine DNS-Anfrage
"in die Hose gegangen", also ohne Ergebnis geblieben. Kann damit nur in
direktem Zusammenhang mit dem DNS System liegen.
> Wäre nett, wenn mir jemand sagen könnte, was ich tun muss um
> sicherzustellen, dass meine E-Mailadresse zuverlässig funktioniert.
Einen kompetent(er)en Partner wählen .... Wer ist denn diese Support-"Größe"
gewesen?
--
meint Guenther Fuchs
Service hat einen Namen: www.Service-Fuchs.com
| Your success is our pleasure!
Wulff D. Heiss
>Einen kompetent(er)en Partner wählen .... Wer ist denn diese
>Support-"Größe"
>gewesen?
# host -t ns clef.at
clef.at NS ns2.inode.at
clef.at NS ns1.inode.at
*g*
--
-s- <the dark one>
>22-Sep-82 21:31 James Muller at CMU-750Y ?
>I propose that the above character be placed in the subject field of all
>posts which ask questions.
Thomas Themel
> Daß der DNS Deines Providers - zumindest temporär - keinen gültigen Eintrag
> für den abgefragten typ (vermutlich: MX, also Mail Exchanger) hatte. Dies
> würde ich als groben Fehler bezeichnen.
So sicher würde ich mir da nicht sein - ich habe auch schon solche Mails von
securityfocus gekriegt, ohne dass auf meiner Seite ein Domain-Ausfall passiert
wäre.
IMO kann's sich da durchaus auch mal um ein verlorenes Paket oÄ handeln.
ciao,
--
Thomas Themel | Just because very few people can fly a Space Shuttle
Hauptplatz 8/4 | doesn't mean we shouldn't have spacecraft. Some of us
A-9500 Villach | are big boys, and we can handle C++ just fine, thank
+43 676 846623-13 | you. - Scott Robert Ladd, on Java and C++
Guenther Fuchs
> # host -t ns clef.at
> clef.at NS ns2.inode.at
> clef.at NS ns1.inode.at
>
> *g*
Uuups - nicht nachgesehen. Wundert mich jetzt aber, denn dieser Bereich war
doch eher einer der funktionierenden bei inode. DNS-Probleme als solche
kannte ich da bisher noch nicht, auch wenn's andere Ungereimtheiten (auch
massivere) gab ...
Sehe ich aber nun schon als etwas "peinlich" für inode an - danke für den
Hinweis.
Guenther Fuchs
> So sicher würde ich mir da nicht sein
Bin auch nicht 100% sicher, aber die Wahrscheinlichkeit ist prinzipiell
schon sehr hoch, wenn Du die Meldung genauer liest.
> ich habe auch schon solche Mails von securityfocus gekriegt, ohne dass
> auf meiner Seite ein Domain-Ausfall passiert wäre.
Idente Meldungen, d.h. sinngemäß "DNS erreicht, aber keinen Eintrag zur
Abfrage erhalten"? Das klingt IMHO doch sehr nach "der DNS liefert
unvollständige oder falsche Daten" ...
> IMO kann's sich da durchaus auch mal um ein verlorenes Paket oÄ
> handeln.
Bei zwei unabhängigen, korrekten DNS?
--
wundert sich Guenther Fuchs (der noch nie solche Mails erhalten hat)
Thomas Themel
Guenther Fuchs <no...@nowhere.invalid> wrote on 2002-11-02:
>> auf meiner Seite ein Domain-Ausfall passiert wäre.
>
> Idente Meldungen, d.h. sinngemäß "DNS erreicht, aber keinen Eintrag zur
> Abfrage erhalten"? Das klingt IMHO doch sehr nach "der DNS liefert
> unvollständige oder falsche Daten" ...
Nein, nicht genau diese Meldung. Ich habe eine Bounce-Warnung bekommen,
weil die Nachricht nicht an den MX von themel.com, sondern an den Host,
auf den der A-Record von themel.com zeigt, geliefert wurde.
>> IMO kann's sich da durchaus auch mal um ein verlorenes Paket oÄ
>> handeln.
>
> Bei zwei unabhängigen, korrekten DNS?
Zugegebenermaßen entzieht sich das meinem Aufsichtsbereich, aber ich
konnte bei meinen darauffolgenden Tests keinen Fehler entdecken und hatte
auch mit dem Anbieter vorher/nachher nie Schwierigkeiten.
Dass der A-Record vorhanden war, der MX aber nicht, scheint mir irgendwie
eigenartig und eher nur durch einen Fehlschlag des Abfragenden zu erklären.
Heinz Ekker
> Guenther Fuchs <no...@nowhere.invalid> wrote on 2002-11-02:
>> Daß der DNS Deines Providers - zumindest temporär - keinen gültigen
>> Eintrag für den abgefragten typ (vermutlich: MX, also Mail Exchanger)
>> hatte. Dies würde ich als groben Fehler bezeichnen.
> So sicher würde ich mir da nicht sein - ich habe auch schon solche
> Mails von securityfocus gekriegt, ohne dass auf meiner Seite ein
> Domain-Ausfall passiert wäre.
Ich auch nicht - habe erst vor kurzem dieselbe Warnung erhalten,
allerdings liegt die "betroffene" Domain bei einem anderen Provider, bei
dem ich mir *ziemlich* sicher bin, dass die Nameserver tadellos
funktionieren.
Ich wuerde eher auf den Securityfocus-Problem tippen.
lg,he
Robert Rotman
> Harald Muehlboeck <ho...@clef.at> wrote:
>
>
>>Ist es normal, dass die Mailadresse halt nicht immer geht?
>
>
> Nein.
>
>
>>Was bedeutet diese Fehlermeldung?
>>| Diagnostic-Code: X-Postfix; Name service error for clef.at: Host found
>>| but no data record of requested type
>
das bedeutet das irgendein programm (in dem fall postfix) auf dem
rechner "outgoing.securityfocus.com" irgendwelche daten von der domain
"clef.at" nicht gefunden hat um die mail zuzustellen.
woran das genau liegt und welche daten das sind steht nicht da!
eine genauere analyse zeigt das "securityfocus.com" von zeit zu zeit
testmails schickt um zu verifizieren ob die mailadresse noch "gueltig" ist.
allerdings macht "securityfocus.com" das nicht ganz richtig:
sie schicken nach dem "rcpt-to" sofort ein "quit" und vergessen dabei
auf die "header-lines".
der gegenueberliegende mailserver atwortet somit mit "5xx" was diese
mail ausloest.
ich hab "securityfocus.com" mal gebeten das auszubessern,
da es aber keinen "normalen" mailverkehr handelt sagten sie es sei
nicht oberste prioritaet:(
>
> Daß der DNS Deines Providers - zumindest temporär - keinen gültigen Eintrag
> für den abgefragten typ (vermutlich: MX, also Mail Exchanger) hatte. Dies
> würde ich als groben Fehler bezeichnen.
blablabla....
warum schreiben in dieser ng die leute die am wenigsten ahnung haben die
meisten postings ;-) ?
>
>
>>Ich habe schon vor ein paar Monaten eine solche Meldung an den
>>Support meines Providers[1] weitergeleitet.
>>Die konnten damit aber nichts anfangen.
>
>
> In diesem Fall würde ich empfehlen, einen Providerwechsel anzudenken.
> Zumindest Fehlermeldungen _lesen_ können sollte ein seriöser, kompetenter
> Provider schon können ...
>
heheheh ;-))))))))))))))))))))))))
no comment,
robert
Thomas Themel
> sie schicken nach dem "rcpt-to" sofort ein "quit" und vergessen dabei
> auf die "header-lines".
"header-lines"? Bitte?
IMO ist MAIL FROM, RCPT TO und dann QUIT eigentlich kein Grund, 550 zu
schicken.
Ich habe den Begriff in RFC2821 nicht gefunden, und allgemein bekannt
scheint er ja auch nicht zu sein.
Robert Rotman
> Robert Rotman <rot...@inode.at> wrote on 2002-11-03:
>
>>sie schicken nach dem "rcpt-to" sofort ein "quit" und vergessen dabei
>>auf die "header-lines".
>
>
> "header-lines"? Bitte?
>
> IMO ist MAIL FROM, RCPT TO und dann QUIT eigentlich kein Grund, 550 zu
> schicken.
>
> Ich habe den Begriff in RFC2821 nicht gefunden, und allgemein bekannt
> scheint er ja auch nicht zu sein.
>
> ciao,
im rfc steht 'SHOULD NOT' und definitiev nicht 'MUST NOT' fuer den from
header.
bei automatisch generierten mails sollte auch "<>" als envelop-sender
aufscheinen.
bei dieser kombination halte ich es durchaus fuer legitim solche mails
zu bouncen denn beides wird von "securityfocus.com" ignoriert.
robert
Guenther Fuchs
> Harald Muehlboeck <ho...@clef.at> wrote:
>>Was bedeutet diese Fehlermeldung?
>>| Diagnostic-Code: X-Postfix; Name service error for clef.at: Host found
>>| but no data record of requested type
> das bedeutet das irgendein programm (in dem fall postfix) auf dem
> rechner "outgoing.securityfocus.com" irgendwelche daten von der domain
> "clef.at" nicht gefunden hat um die mail zuzustellen.
Du hast "z.B." vergessen dazuzuschreiben, auch wenn die anderen Punkte
durchaus als Ursache gelten können.
> woran das genau liegt und welche daten das sind steht nicht da!
Jein - "Name service error" steht dabei, daher ist die Vermutung auch sehr
hoch, daß es damit was zu tun haben wird.
> eine genauere analyse zeigt das "securityfocus.com" von zeit zu zeit
> testmails schickt um zu verifizieren ob die mailadresse noch "gueltig"
> ist. allerdings macht "securityfocus.com" das nicht ganz richtig:
> sie schicken nach dem "rcpt-to" sofort ein "quit" und vergessen dabei
> auf die "header-lines".
> der gegenueberliegende mailserver atwortet somit mit "5xx" was diese
> mail ausloest.
Was nicht unbedingt aus der Fehlermeldung auszulesen ist und auch zu dieser
im Widerspruch steht. Wir hatten diesebezüglich noch keine analogen Fälle,
sind durchaus jedoch gerne bereit, fundierten Argumenten und schlüssigen
Punkten bzw. nachvollziehbaren Argumenten zu folgen.
Parallel zu Deiner durchaus fachlich fundierten Antwort schreibst Du dann
jedoch weiter:
> blablabla....
>
> warum schreiben in dieser ng die leute die am wenigsten ahnung haben
> die meisten postings ;-) ?
Da Du dies offenbar auf (u.a.) mich beziehst und scheinbar auch bei inode
arbeitest (wenn nicht sogar Dipl. Ing. Robert Rotman, einer der für Kunden
normal unerreichbaren Chefs bist): Findest Du dies korrekte Diskussions-
kultur? Warum antwortet Ihr Eurem Kunden nicht einfach direkt und korrekt,
dann käme derartiges hier nicht "zur Sprache" - ich zitiere gerne nochmals
die Nachricht Deines Kunden:
> Harald Muehlboeck <ho...@clef.at> wrote:
>>Ich habe schon vor ein paar Monaten eine solche Meldung an den
>>Support meines Providers[1] weitergeleitet.
>>Die konnten damit aber nichts anfangen.
Bitte entschuldige, daß ich ohne Zugriff auf Deine Logs versucht habe, aus
der Fehlermeldung schlüsssige Antworten zu lesen und natürlich von den
Einträgen in Deinen Logs keine Ahnung habe, dies auch nich haben kann.
Sorry, daß ich Deinem Ratsuchenden Kunden trotzdem versucht habe, eine
Antwort zu finden. Tut mir wirklich sehr leid, wenn ich gewusst hätte, daß
er inode Kunde ist, hätte ich Eure fehlerfreie Kompetenz ja nie auch nur
ansatzweise versucht in Frage zu stellen. Dies wirst Du ja sicher
veranlassen, so daß Dein Kunde nicht mehr hier nachfragen muß.
F'up2p, weil's stark OT wird. Persönliche Differenzen und haltlose
Unterstellungen haben IMHO hier nichts verloren.
(PS für die inode Geschäftsführung: Bucht mal einen Kurs in Vertragsrecht -
insbesondere in den Punkten Nichterfüllung und Haftung)
--
Guenther "ich such' grad nach Asche für mein Haupt" Fuchs
Guenther Fuchs
> blablabla....
...
> heheheh ;-))))))))))))))))))))))))
...
> no comment,
Da nun wieder einer der inode Chefs zum Posten "hier ist": Magst nicht auch
was zu den anderen offenen Fragen Deiner Kunden hier schreiben? Nur, damit
ich mit meinen inkompetenten Antworten nicht wieder auf Deine Füsse steigen
muß - zur Erinnerung ein Beispiel:
Klaus Trabitsch weiß immer noch nicht, wieso seine Domain im Wechsel zu
Euch laufend abgelehnt wird (obwohl er ja laufend bei Euch bezahlt dafür)
=> news:aq0ies$2kt$1...@newsreader1.netway.at (nette ID übrigens)
Martin Szongott
> blablabla....
>
> warum schreiben in dieser ng die leute die am wenigsten ahnung haben die
> meisten postings ;-) ?
Gegenfrage: Warum stehst du mit deiner Weisheit, deiner Kompetenz und
deinem umfangreichen Erfahrungsschatz nicht deinen Kollegen im Support
zur Verfügung?
siehe:
> >>Ich habe schon vor ein paar Monaten eine solche Meldung an den
> >>Support meines Providers[1] weitergeleitet.
> >>Die konnten damit aber nichts anfangen.
Oder ist es gar Inode's Firmenpolitik - bevor man wenigstens Vermutungen
äußerst - lieber erst gar nichts zu antworten?
So nach dem Motto: Wer nichts von sich gibt, kann auch nichts Falsches
sagen? ;-)
--
Liebe Grüße,
Martin, der sich eine Stellungnahme von Inode's GL erwarten würde
Martin Szongott
> Klaus Trabitsch weiß immer noch nicht, wieso seine Domain im Wechsel
> zu Euch laufend abgelehnt wird (obwohl er ja laufend bei Euch bezahlt
> dafür) => news:aq0ies$2kt$1...@newsreader1.netway.at (nette ID übrigens)
Der arme Klaus wird inzwischen hoffentlich so einsichtig geworden sein,
sich nach einem kompetenteren Partner in Sachen Domains umzuschauen.
--
Liebe Grüße,
Martin, der für einen KK einer .at-Domain noch nie länger als 5 Tage
brauchte (cno-Domain max. 2 Wochen)
Alexander Talos
Robert Rotman <rot...@inode.at> wrote:
>Thomas Themel wrote:
>> Robert Rotman <rot...@inode.at> wrote on 2002-11-03:
>>>sie schicken nach dem "rcpt-to" sofort ein "quit" und vergessen dabei
>>>auf die "header-lines".
>> "header-lines"? Bitte?
Me too: In SMTP gibts keine Header-Lines. Also kann deren Fehlen auch
kein 550 ausloesen.
>> IMO ist MAIL FROM, RCPT TO und dann QUIT eigentlich kein Grund, 550 zu
>> schicken.
>> Ich habe den Begriff in RFC2821 nicht gefunden, und allgemein bekannt
>> scheint er ja auch nicht zu sein.
>im rfc
Welchem jetzt? In Bezug worauf?
>steht 'SHOULD NOT' und definitiev nicht 'MUST NOT' fuer den from
>header.
Verwirr, verwirr. Reden wir von der Envelop*e* oder vom Header?
>bei automatisch generierten mails sollte auch "<>" als envelop-sender
>aufscheinen.
Nein. Keineswegs. Ganz im Gegentum. Der leere Reverse-Path ist fuer
DSNs reserviert. Nicht einmal Return Receipts sollen mit <>
verschickt werden.
>bei dieser kombination halte ich es durchaus fuer legitim solche mails
>zu bouncen denn beides wird von "securityfocus.com" ignoriert.
Wenn auf RCPT gleich QUIT folgt, gibt es keine Mail. Folglich kann
sie auch nicht bouncen.
>>>blablabla....
>>>
>>>warum schreiben in dieser ng die leute die am wenigsten ahnung haben die
>>>meisten postings ;-) ?
Seufz, ja.
Ciao
Alexander
Peter J. Holzer
> eine genauere analyse zeigt das "securityfocus.com" von zeit zu zeit
> testmails schickt um zu verifizieren ob die mailadresse noch "gueltig" ist.
> allerdings macht "securityfocus.com" das nicht ganz richtig:
> sie schicken nach dem "rcpt-to" sofort ein "quit" und vergessen dabei
> auf die "header-lines".
Dann ist es keine Testmail.
> der gegenueberliegende mailserver atwortet somit mit "5xx" was diese
> mail ausloest.
Worauf soll der mit "5xx" antworten? Auf das "quit"? Das meinst Du
hoffentlich nicht ernst, und ich kann es bei Euren Meil-Servern auch
nicht nachvollziehen.
Außerdem würde mich wundern, wenn securityfocus auf diese Art
festzustellen versuchen würde, ob eine Adresse noch gültig ist: Ich
traue den Leuten genug Clue zu, dass sie wissen, dass ein 250-Reply auf
"RCPT TO" nicht besonders aussagekräftig ist.
hp
--
_ | Peter J. Holzer | Schlagfertigkeit ist das, was einem
|_|_) | Sysadmin WSR | auf dem Nachhauseweg einfällt.
| | | h...@hjp.at | -- Lars 'Cebewee' Noschinski in dasr.
__/ | http://www.hjp.at/ |
Guenther Fuchs
> ahja, und ich kenne auch einen Exkunden von Inode, der noch
> buchhalterische Fragen offen hat. Leistungsnichterfüllung, etc.
Dero kenne ich mindestens zwei, denke jedoch nicht, daß sich auch nur einer
hier in diesem Zusammenhang "outen" wird - geht ja hier eigentlich "nur" um
Support und nicht um Leistungserfüllung. Und a.g.r ist für Rechtsfragen
wohl besser geeignet.
Peter J. Holzer
Gerade habe ich auch so eine Warnung bekommen:
| Here are the message numbers:
|
| 6919
| 6910
| 6963
| 6967
[...]
| Date: Fri, 18 Oct 2002 22:37:37 -0600 (MDT)
| From: MAILER...@outgoing.securityfocus.com (Mail Delivery System)
| Subject: Undelivered Mail Returned to Sender
| To: bugtraq-return-6919-hjp=wsr....@securityfocus.com
[...]
| Diagnostic-Code: X-Postfix; Name service error for wsr.ac.at: Host found
| but no
| data record of requested type
Vier gebouncte Messages in ca. 2 Wochen, gleicher Fehler wie beim OP.
Dass in der Zeit einmal tatsächlich der MX-Record für wsr.ac.at gehlt
haben sollte, kann ich ausschließen.
Allerdings fällt mir gerade ein etwas seltsames Verhalten des bind als
caching name server auf:
teal:~ 21:07 121% dig any wsr.ac.at
;; ANSWER SECTION:
wsr.ac.at. 80291 IN NS ns1.wsr.ac.at.
wsr.ac.at. 80291 IN NS mario.gams.at.
Nanu? Nur NS-Records? Wo ist denn der MX?
teal:~ 21:39 122% dig mx wsr.ac.at
;; ANSWER SECTION:
wsr.ac.at. 86400 IN MX 10 wsrcom.wsr.ac.at.
Da ist er ja :-)
teal:~ 21:40 123% dig any wsr.ac.at
;; ANSWER SECTION:
wsr.ac.at. 86390 IN MX 10 wsrcom.wsr.ac.at.
wsr.ac.at. 86390 IN NS mario.gams.at.
wsr.ac.at. 86390 IN NS ns1.wsr.ac.at.
Und jetzt bekommt man ihn auch mit einer "ANY" Query. Da probieren wir
das doch gleich auch mit dem A Record:
teal:~ 21:40 124% dig a wsr.ac.at
;; ANSWER SECTION:
wsr.ac.at. 86400 IN A 143.130.16.131
teal:~ 21:41 126% dig any wsr.ac.at
; <<>> DiG 9.2.1 <<>> any wsr.ac.at
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10434
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;wsr.ac.at. IN ANY
;; ANSWER SECTION:
wsr.ac.at. 86365 IN A 143.130.16.131
wsr.ac.at. 86341 IN MX 10 wsrcom.wsr.ac.at.
wsr.ac.at. 86365 IN NS mario.gams.at.
wsr.ac.at. 86365 IN NS ns1.wsr.ac.at.
Tadaa!
D.h., bind 9 liefert auf eine ANY Query immer nur das zurück, was er
gerade im Cache hat, und das ist nicht notwendigerweise das volle RR-Set
für einen FQDN. (Möglicherweise war das eh immer schon so, aber es ist
mir noch nie aufgefallen).
Wilde Spekulation:
Ich weiß nicht, wie Postfix seine Name Queries ausführt, aber wenn es
ANY Queries statt getrennte Queries auf MX und A Records absetzt, sind
solche Effekte zu erwarten.
[Fup? Mit Providern hat das wohl nicht mehr viel zu tun]
Thomas Themel
> Ich weiß nicht, wie Postfix seine Name Queries ausführt, aber wenn es
> ANY Queries statt getrennte Queries auf MX und A Records absetzt, sind
> solche Effekte zu erwarten.
Scheint nach einem kurzen Blick auf die Sourcen nicht der Fall zu sein.
Da wird erst nach einem MX gefragt, und wenn keiner existiert nach einem
A-Record.
Die dns_lookup-Funktion hat sogar einen spezifischen Kommentar "it is
unwise to specify the T_ANY wildcard resource type".
> [Fup? Mit Providern hat das wohl nicht mehr viel zu tun]
Hm, de.comm.software.mailserver? de.alt.ufo? :)
Harold Winter
> allerdings macht "securityfocus.com" das nicht ganz richtig:
> sie schicken nach dem "rcpt-to" sofort ein "quit" und vergessen dabei
> auf die "header-lines".
> der gegenueberliegende mailserver atwortet somit mit "5xx" was diese
> mail ausloest.
Ist das vielleicht eine Art neuer Sport?
| Return-Path: <internet...@uole.com>
| Received: (qmail 468990 invoked from network); 2 Nov 2002 05:50:20 -0000
| Received: from unknown ([172.18.5.76]) (envelope-sender <>)
| by qmail2.highway.telekom.at (qmail-ldap-1.03) with QMQP
| for <>; 2 Nov 2002 05:50:20 -0000
| Received: (qmail 412094 invoked from network); 2 Nov 2002 05:50:19 -0000
| Received: from adsl-67-114-196-190.dsl.pltn13.pacbell.net (HELO net1)
| ([67.114.196.190]) (envelope-sender <internet...@uole.com>)
| by qmail3rs.highway.telekom.at (qmail-ldap-1.03) with SMTP
| for <*****@aon.at>; 2 Nov 2002 05:50:19 -0000
| Received: from [202.9.154.165] by net1
| (ArGoSoft Mail Server Plus for WinNT/2000, Version 1.8 (1.8.2.1)); Fri,
| 1 Nov 2002 20:41:35 -0800
| Message-ID: <7q28tqpkqn8qedw.011120022041@net1>
| Date: Fri, 1 Nov 2002 20:41:35 -0800
|
|
| QUIT
Werden hier ev. Adresslisten verifiziert?
Otmar Lendl
>
>D.h., bind 9 liefert auf eine ANY Query immer nur das zurück, was er
>gerade im Cache hat, und das ist nicht notwendigerweise das volle RR-Set
>für einen FQDN. (Möglicherweise war das eh immer schon so, aber es ist
>mir noch nie aufgefallen).
Bind 8 verhaelt sich nicht anders:
$ host -a fst.sbg.ac.at endjinn
fst.sbg.ac.at NS DSBMV3.EDVZ.sbg.ac.at
fst.sbg.ac.at NS DSBGPX.EDVZ.sbg.ac.at
$ host -t mx fst.sbg.ac.at endjinn
fst.sbg.ac.at MX 10 mh.sbg.ac.at
$ host -a fst.sbg.ac.at endjinn
fst.sbg.ac.at NS DSBMV3.EDVZ.sbg.ac.at
fst.sbg.ac.at NS DSBGPX.EDVZ.sbg.ac.at
fst.sbg.ac.at MX 10 mh.sbg.ac.at
ANY queries machen nur auf authoritativen nameservern wirklich sinn.
/ol
--
< Otmar Lendl (O.L...@eunet-ag.at) | EUnet AG Systems Engineer >
Guenther Fuchs
> 67.114.196.190
http://ordb.org/lookup/?host=67.114.196.190
Tippe in diesem Fall auf Spammer / Adressverifikation.