TLSA Record not found, Mails haengen in der Queue...

[Uwe.Prions]

Hi ihr

Ich habe heute drei ausgehende Mails, die in der Queue haengen.

The TLSA records for mailin1.o***v.de could not be looked up: Response records could not be validated

die stehen noch auf pending delivery. Fehler 4.4.4.

Einen TLSA Record scheint es nicht zu geben, hab das mit nem online tool gesucht.

Wie kommt der NSP denn darauf, dass er den braucht? Mir ist der ganze Mechanismus nicht klar...

Danke fuer jeden Tipp.

Viele Gruesse
Uwe Prions

 

[869288141]

Hallo Uwe,
ohne die vollständige E-Mail-Domain des Empfängers zu kennen, ist es schwierig dein Resultat nochmals zu prüfen.
Ich hab es in der Vergangenheit (NSP 13er) schon gesehen, dass der Empfänger einen nicht korrekten TLSA Eintrag veröffentlicht hatte.
Alternativ mit Hilfe von Wireshark einmal die Request mitschneiden.


Grüße,
Daniel

 

[JanJäschke]

Hallo Uwe,

die Meldung ist hier recht eindeutig udn es wurde zum Zeitpunkt der Zustellung ein TLSA Record gefunden.
Da dieser vorhanden ist wird er auch berücksichtigt und versucht zu validieren. Schlägt diese Validierung fehl kommt es nicht zur Zustellung, andernfalls wäre der Mechanismus nicht sinnvoll.

Die Ursache kann nun unterschiedlicher Natur sein. Wenn du mir die ganze Domäne nennen kannst (gerne auch als PN falls zu sensibel) kann ich das noch einmal gegenprüfen.
Also Zwischenlösung könntest du in Partnern Standard-Einstellungen, Tab Transportsicherheit, DANE deaktivieren. Dadurch wird kein DANE gemacht und somit die Transport sicherheit bei dem ein oder anderen Partner etwas geringer. (Das dürfte die Minderheit sein.)

LG
Jan

 

[Uwe.Prions]

Kein Problem, geht um mailin1.oediv.de

 

[Uwe.Prions]

kann ich das auch nur fuer den Partner deaktivieren?

 

[Uwe.Prions]

DANE war schon deaktiviert:

...das ist dann komisch, das die Mails noch in der Queue haengen...

Gruss Uwe

 

[JanJäschke]

Guten Morgen Uwe,

ist die Queue mittlerweile abgearbeitet oder liegen die E-Mails noch mit dem Fehler drin?

Gruß
Jan

 

[Uwe.Prions]

Hi Jan

die ist jetzt leer. Allerdings wohl weil nach 24 h die Versuche abgebrochen wurden. Eine erneute Mail eines Kollegen am Samstag ist allerdings nach 23 h durchgegangen...



LG
Uwe

 

[JanJäschke]

Hallo Uwe,

ich habe eben schon einmal mit der Entwicklung grob geschaut was noch los sein könnte:
Die Fehlermeldung ist vom Wortlaut leider etwas irreführend, es wird an dieser Stelle geschaut ob ein TLSA Record existiert und nicht versucht diesen zu prüfen. Somit ist nicht der (fehlende) TLSA Record selbst schuld.

Mögliche Ursachen wären also eher so etwas wie: DNS Server nicht erreichbar, antwortet nicht, Antwort kaput usw.
Hieraus ergibt sich die Frage ob es für euch denkbar ist ein Log zu erstellen und uns dieses einmal zur Verfügung zu stellen?

Wir prüfen auf unserer Seite auf jeden Fall einmal wieso es zur TLSA Prüfung kommt obwohl DANE deaktiviert ist.

Die beste Lösung um die Zustellung zu gewährleisten wäre somit aktuell DNSSEC zu deaktivieren.


Gruß
Jan

 

[Uwe.Prions]

Log: Klar, gerne. Was soll ich tun?

 

[JanJäschke]

Super

Da ihr das Problem ja anscheinend reproduzieren können einmal folgende Kategorien im Troubleshooting beim Logging alle Gateway Rollen aktivieren:

• DNS Service
• Mail delivery service
• Mailvalidation
• Network connections
• Proxy System

Danach das Verhalten einmal nachstellen. Wenn alles wie gewünscht nicht funktioniert hat das Loggign im Troubleshooting wieder deaktivieren.
In Der Nachrichten Verfolgung prüfen über welches Gateway die E-Mail versendet werden sollte, von diesem den Dienst einmal neustarten.
Dann bitte den Messagetrack inklusive der Log Dateien an mich
(Log Datei passend zum Zeitstempel +/- eine Datei)

Gruß
Jan

 

[Uwe.Prions]

log ist per pn unterwegs.. Die neue Mail haengt wieder in der Queue.

 

[Uwe.Prions]

Nach 16 Minuten ist die Mail zugestellt worden. Also wohl nach dem naechsten Versuch nachdem ist den Gateway Service neu gestartet hatte.

 

[JanJäschke]

Hallo Uwe,

falls du mehrere Gateways hast starte das andere auch einmal neu.
Falls das nur zufällig geholfen hatte wirst du vorerst DNSSEC deaktivieren müssen.
Dein Log hilft uns auf jeden Fall weiter wir sind jedoch verwundert wieso genau es nicht klappt.
Hier versuchen wir das Problem noch nachzustellen, bisher ohne Erfolg.

(Fragst du direkt einen öffentlichen DNS Server an oder einen internen/per Windows?)

Gruß
Jan

 

[Uwe.Prions]

Hi Jan

nur ein Gateway. Ich meine, ich frage unseren internen DC und der holt sich das von aussen...

falls ich noch was tun kann oder ihr bei uns mal draufschauen wollt, nur zu. Bei uns ists ruhig da Urlaubszeit...

LG
Uwe

 

[Patrick]

Hallo zusammen,

wir hatten gerade dasselbe Problem mit der Domäne vescore.com und haben nun DNSSEC deaktiviert. (NSP 14.0.5)

Dein Log hilft uns auf jeden Fall weiter wir sind jedoch verwundert wieso genau es nicht klappt.

Gab es mittlerweile Erkenntnisse, die der Verwunderung entgegengewirkt haben?

 

[869288141]

Hallo Patrick,

(Fragst du direkt einen öffentlichen DNS Server an oder einen internen/per Windows?)

welchen DNS Server nutzt du?!


Gruß,
Daniel

 

[JanJäschke]

Hallo Patrick,

Ja gab es und es gab noch einen Fall der aber einen anderen Grund hatte wo das Log nicht hilft ^^
Bei Bedarf kann ich eine Konsolenanwendung zur Verfügung stellen mit welcher du einen Test machen kannst um den Fehler einzugrenzen.

Gruß
Jan

 

[869288141]

Bei Bedarf kann ich eine Konsolenanwendung zur Verfügung stellen mit welcher du einen Test machen kannst um den Fehler einzugrenzen.

Wäre es nicht sinnvoller, die Funktion unter Troubleshooting zu integrieren? Weil der % Satz an Kunden, die hier aktiv sind und diesen Beitrag in 4 Monaten wieder finden, halte ich für sehr gering.

 

[JanJäschke]

Das hängt ganz von der Analyse ab. Wir können natürlich etwas integrieren was niemals wieder gebraucht wird wenn die Ursache der beiden Probleme behoben werden können und das logging in dem Bereich verbessert werden kann