Auf einen Schlag 100% Fehlermeldungen (viele "Relaying denie

CodeFather · Beitrag von **CodeFather** » 14.01.2011, 09:30

Ja, schwierig sowas...

Meinem Kollegen, der den Versand durchgeführt hat, ist zumindest nicht aufgefallen, dass der Versand irgendwie langsamer ausgeführt wurde. Das muss aber nix heißen

Sobald ein weiterer Versand durchgeführt wurde, werde ich auf jeden Fall berichten. 100% sicher können wir ja eigentlich erst sein, wenn der Fehler wieder aufgetreten ist oder wenn tatsächlich eine passende Fehlerstelle gefunden wurde...

Beitrag von **mirko** » 13.01.2011, 12:37

mhh und genau dieses \"sporadisch\" ist immer das Problem überhaupt einen Fehler zu finden. Theoretisch kann ich den Cache auch für immer rausnehmen, da eigentlich das Windows-System auch einen DNS-Cache führt, damit sollte sich das zeitmässig nicht viel nehmen.

CodeFather · Beitrag von **CodeFather** » 13.01.2011, 11:17

Hallo und ein schönes neues Jahr zunächst einmal!

Gestern wurde mal wieder ein Versand durchgeführt, diesmal mit der erhaltenen Spezialversion ohne Cache. Waren allerdings nur ca. 2600 Adressen.

Der beschriebene Fehler ist dabei zumindest nicht aufgetreten. Da er bisher nur sporadisch auftrat, muss das ja aber auch erstmal noch nichts heißen...

Beim nächsten Versand melde ich mich wieder und erstatte Bericht...

CodeFather · Beitrag von **CodeFather** » 13.12.2010, 09:36

Danke, habe ich erhalten und melde mich nach dem nächsten Versand...

Beitrag von **mirko** » 09.12.2010, 20:37

Wenn der Fehler dann noch auftritt wissen wir zumindest, dass es nicht am Cache liegt. Wird der Cache eigentlich temporär im Speicher gehalten oder wird der irgendwohin geschrieben?

Temporär pro Versandthread, der von Windows selbst wird natürlich von Windows länger gehalten.

Ich schicke Dir mal meine meine Emailadresse per PN, da kannst Du mir ja mal die Testversion hinschicken. Wie gesagt, kann es dann aber ein paar Tage dauern bis der nächste Versand ansteht und wir das testen...

Ist halt immer blöd wenn so ein Verhalten nicht wirklich reproduzierbar und nur selten zu beobachten ist. Vielen Dank aber schon mal für die rege Beantwortung meiner Postings... Und gelernt habe ich jetzt auch schon\'ne Menge, seit ich mich mit dem Thema hier beschäftige :biggrin:

Mache ich morgen.

CodeFather · Beitrag von **CodeFather** » 09.12.2010, 17:33

Die Spezialversion könnte ich gerne mal testen. Ich glaube diesen Monat will mein Kollege noch einen Email-Versand durchführen. Die könnte ich ihm dann unterjubeln.

Wenn der Fehler dann noch auftritt wissen wir zumindest, dass es nicht am Cache liegt. Wird der Cache eigentlich temporär im Speicher gehalten oder wird der irgendwohin geschrieben?

Ich schicke Dir mal meine meine Emailadresse per PN, da kannst Du mir ja mal die Testversion hinschicken. Wie gesagt, kann es dann aber ein paar Tage dauern bis der nächste Versand ansteht und wir das testen...

Ist halt immer blöd wenn so ein Verhalten nicht wirklich reproduzierbar und nur selten zu beobachten ist. Vielen Dank aber schon mal für die rege Beantwortung meiner Postings... Und gelernt habe ich jetzt auch schon\'ne Menge, seit ich mich mit dem Thema hier beschäftige :biggrin:

Beitrag von **mirko** » 09.12.2010, 14:10

Es scheint für mich so, als ob immer eine Anfrage nach der MX Adresse an den DNS-Server gesendet wird und im Anschluss auf die Antwort noch eine Anfrage nach dem A-Record um letztlich die IP-Adresse des MX-Hostnamen aufzulösen.

Der bestimmt alle Namen der MX-Hostnamen und speichert diese in ein array/Feld. Und dann läuft ne Schleife

for i = 1 to laenge des array {
SMTPhostname = array;

umwandlung name in IP adresse
konnektiere host
versuche mail zu schicken
beende verbindung zum host

hat versand funktioniert, gibt es ein break, wenn nicht geht es oben bei for weiter
}

Soweit so gut, aber in den Datenpaketen ist die Transaction-ID, welche meines Wissens zur Identifizierung des UDP-Paketes bei der Rückanwort verwendet wird, bei allen MX-Abfragen identisch (0xa3ce). Somit könnte doch ein Fehler bei der Zuordnung der Antworten vom DNS-Server passieren, oder?

Du kannst fragen stellen, so tief beschäftige ich mich damit nicht. Das sind alles Winsock-Anfragen, das Winsock-System macht das auf Netzwerkebene und nutzt dafür natürlich auch wieder den DNSCache des Windows-Systems.

Wenn alles streng synchron laufen würde, könnte man vielleicht auf die Zuordnung über die Id verzichten aber es scheint, als ob sich Abragen zur MX-Adresse und dem A-Record teilweise zeitlich etwas vermischen, was in dem Fall eine Zuordnung nicht 100% sicher machen würde und ggf. zu dem von mir beschriebenen Fehler führen könnte...?

Vermischen kann sich das nicht, der macht das bei 1 Thread(!) immer nach und nach. Bei mehreren Threads vermischt sich das dann. Spielt aber keine Rolle die Netzwerkpakete haben eine eindeutige Kennung so diese auch den Weg eindeutig wieder zurückfinden.

Beitrag von **mirko** » 09.12.2010, 13:54

Beim Zugriff auf den internen Cache kann auch nichts schief gehen? Sorry, dass ich ständig nachhake, aber ich habe keine Idee wie das sonst ausserhalb vom SuperMailer passieren kann und mit dem SMTP-Protokoll-Ausschnitt lassen sich auch die \"Relay denied\"-Fehler erklären...

Ich hoffe nicht.

Ich kann dir ja mal ne Spezial-Version schicken, da mache ich den Cache vorher raus, so dass er jedesmal den Server bestimmen muss.

CodeFather · Beitrag von **CodeFather** » 09.12.2010, 11:13

Ich habe mir jetzt nochmal die gesamte Netzwerkprotokollierung genauer angeschaut, die ich beim auftreten des Fehler mitgeschnitten habe.

Obiges gilt immer noch. XXX@willi-bayer.de wird unter der MX-IP von XXX@wiesmueller-kraenzel.de kontaktiert (wie oben beschrieben), aber mir ist dabei noch folgendes bei den DNS-Abfragen aufgefallen:

Es scheint für mich so, als ob immer eine Anfrage nach der MX Adresse an den DNS-Server gesendet wird und im Anschluss auf die Antwort noch eine Anfrage nach dem A-Record um letztlich die IP-Adresse des MX-Hostnamen aufzulösen.

Soweit so gut, aber in den Datenpaketen ist die Transaction-ID, welche meines Wissens zur Identifizierung des UDP-Paketes bei der Rückanwort verwendet wird, bei allen MX-Abfragen identisch (0xa3ce). Somit könnte doch ein Fehler bei der Zuordnung der Antworten vom DNS-Server passieren, oder?
Wenn alles streng synchron laufen würde, könnte man vielleicht auf die Zuordnung über die Id verzichten aber es scheint, als ob sich Abragen zur MX-Adresse und dem A-Record teilweise zeitlich etwas vermischen, was in dem Fall eine Zuordnung nicht 100% sicher machen würde und ggf. zu dem von mir beschriebenen Fehler führen könnte...?

Ist jetzt nur eine Vermutung oder Idee, aber vielleicht hilft es ja weiter um den Fehler zu lokalisieren. Irgendwo muss das Problem ja schließlich stecken...

CodeFather · Beitrag von **CodeFather** » 08.12.2010, 15:55

Die Fehlermeldungen bezogen sich nicht auf eine Emailadresse, sondern sind für drei aufeinanderfolgende Emailversandversuche von unterschiedlichen Emailadressen vom SuperMailer ausgegeben worden. Also:

Alles ok bzw. immer mal ein Fehler, dass Adresse ungültig usw.

Email X: Read Timeout ()
Email X+1: Socket Error # 10054 Connection reset by peer. ()
Email X+2: Socket Error # 11001 Host not found. ()

Von da ab war der kontaktierte Server immer der, der vorhergehenden Adresse und lehnt aufgrund von \"Relaying denied\" den Versand bzw. den Empfang ab bis SuperMailer neugestartet wird...

Beim Zugriff auf den internen Cache kann auch nichts schief gehen? Sorry, dass ich ständig nachhake, aber ich habe keine Idee wie das sonst ausserhalb vom SuperMailer passieren kann und mit dem SMTP-Protokoll-Ausschnitt lassen sich auch die \"Relay denied\"-Fehler erklären...

Beitrag von **mirko** » 08.12.2010, 14:03

Ich habe auch nach einer Stelle gesucht an der er aus dem Tritt geraten könnte aber da ist keine. Es wird ein interner Cache gebildet, der hält die letzten 500 Domains nach dem @ und passende MX-Server nach Priorität dazu. Kommen also 200 Anfragen nach t-online.de, dann muss ich nicht 200x fragen wie ist der MX-Server, das reicht einmal und spart Zeit. Gibt es keinen MX-Server oder der kann nicht bestimmt werden, dann wird einfach der Domainname nach dem @ als Server probiert. Klappt es nicht, geht es halt nicht.

Read Timeout ()
Socket Error # 10054 Connection reset by peer. ()
Socket Error # 11001 Host not found. ()

^^ das klingt eher nach Probleme mit der Internetverbindung, der bekam keine Rückmeldung mehr, danach wurde die Verbindung zum Zielserver getrennt und danach funktionierte die Domainauflösung nicht mehr bzw. den Servernamen gibt es nicht.

CodeFather · Beitrag von **CodeFather** » 08.12.2010, 13:06

So hätte ich das Vorgehen im Normalfall auch vermutet...

Laut dem SMTP-Protokoll-Auszug, den ich meinem Post hinzugefügt habe, ist dies aber doch nicht der Fall. Es wird der SMTP-Server entsprechend dem MX-Eintrag zur Domain der vorherigen(!) Emailadresse kontaktiert, der dann mit \"Relaying denied\" abweist, was in dem Fall ja dann auch richtig ist. Bei der nächsten wird dann wieder der, der vorherigen verwendet, also immer um eins versetzt...

Ich habe eben nochmal versucht ein weiteres Mal dieses Verhalten zu provozieren, ist mir aber leider nicht gelungen. Irgendwann im Sendeverlauf scheint etwas zu geschehen, was den SuperMailer wie oben beschrieben \"aus dem Tritt\" bringt.

Ist es vielleicht möglich, dass die MX-IP vom SuperMailer aus z.B. performancegründen wiederverwendet wird, wenn der Domainname der nächsten Emailadresse gleich ist und da dann manchmal was falsch läuft?

Beim letzten Mal traten die folgenden drei Fehler auf, bevor keine einzige Email mehr durchging und jeweils der falsche SMTP-Server angefragt wurde:
Requested mail action okay, completed
Read Timeout ()
Socket Error # 10054 Connection reset by peer. ()
Socket Error # 11001 Host not found. ()

Wie gesagt, nach einem SuperMailer-Neustart geht es sofort wieder. Auch mit den Adressen die vorher abgewiesen wurde. Daher und vor allem aufgrud des SMTP-Protokollmitschnitts fällt mir nichts ein, was ausser dem SuperMailer sonst zu diesem Fehler führen könnte. Ausser die DNS-Abfrage würde jeweils nochmal das Ergebnis der letzten Abfrage liefern. Davon gehe ich jetzt aber mal nicht aus...

Hilfe!

Beitrag von **mirko** » 07.12.2010, 21:41

Habe ich angeschaut, finde ich aber kein Problem. Der kann auch nicht einen falschen Server nehmen, weil anhand der E-Mail-Domain der MX-Server bestimmt wird (bzw. mehrere davon), danach wird sofort der Versand an diesen Zielserver durchgeführt. Ist das erledigt, egal ob erfolgreich oder nicht, dann wird die nächste E-Mail-Adresse genommen und das ganze geht wieder von vorn los. Nach jeder E-Mail wird die Verbindung zum Zielserver getrennt und danach zum nächsten Server wieder aufgebaut, das ist natürlich sehr zeitaufwändig aber geht nicht anders bei dieser Versandvariante.

CodeFather · Beitrag von **CodeFather** » 07.12.2010, 12:11

Das gebe ich meinem Chef aber mal besser nicht so weiter... :d_gutefrage:

Beitrag von **mirko** » 07.12.2010, 11:03

Muss ich erst nachprüfen und simulieren. Im Moment geht das nicht, kurz vor Weihnachten ist immer der meiste Stress des Jahres. Am 24.12. 18 Uhr ist Weihnachten vorbei, dann sind alle glücklich.