Probleme beim Mailversand aus Drittprogramm

[Maniska]

Hallo zusammen,

ich habe folgendes Konstrukt:

Auf der einen Seite einen Exchange Sever 2013 auf Windows Server 2012, auf der anderen Seite ein Programm zur Mailverschlüsselung und verschlüsselten Übertragung auf virtualisiertem openSUSE 42.2. Die beiden sind getrennt durch eine Firewall. Auf dem Exchange Server existiert ein Empfangsconnector zum anonymen Versenden. Dort ist unter anderem die IP des Verschlüsselungsservers eingetragen, das Versenden darüber funktioniert auch (getestet)

Das Verschlüsselungsprogramm nutzt eden internen Postfix um die Mails an unseren Exchange zu schicken, dieser schickt das dann weiter.

Fall 1: ich sende eine Mail vom Verschlüsselungsserver an eine interne Mailadresse --> Tut, Mail wird zügig versendet und kommt an.

Fall 2: ich sende an eine externe Mailadresse --> Tut nicht, Mailverarbeitung dauert länger, es kommt eine Bouncemeldung zurück.

Zitat

relay=mailserver.domäne.local[xxx.xxx.xxx.xxx]:25, delay=5.1, delays=0.01/0.03/0.01/5, dsn=5.7.1, status=bounced (host mailserver.domäne.local[xxx.xxx.xxx.xxx] said: 550 5.7.1 Unable to relay (in reply to RCPT TO command))

Was habe ich schon versucht:

• Connector getestet, --> Anonymer Versand nach außen geht
• auf SMTP Authentifizierung umgestellt --> selbes Fehlerbild, intern geht, extern nicht
• SMTP Host von "localhost" auf Exchange umgestellt --> selbes Fehlerbild, intern geht, extern nicht
• Message Tracking Log duchsucht, da sehe ich nichts das mit weiterhilft
• mit den jeweilgen Dienstleistern auf die Systeme geschaut, die schieben sich gegenseitg den schwarzen Peter zu, sind also keine Hilfe

Jemand eine Idee die dieses Verhalten erklären könnte?

Edit: Was ich noch nicht gemacht habe war ein Neustart des Exchange, das werde ich erst am Wochende tun können.

 

Bearbeitet 22. November 2017 von Maniska

[Eye-Q]

Bist Du dir sicher, dass die Mail den richtigen Weg nimmt, also der Exchange den richtigen Empfangsconnector "anbietet"? Am einfachsten zu testen ist das, indem Du in jedem Empfangsconnector einen anderen Namen eingibst, mit dem sich der Empfangsconnector melden soll. Wenn Du dich dann vom openSUSE-Server per Kommandozeile auf Port 25 (oder welchen Port auch immer Du nutzt) des Exchange-Servers verbindest, siehst Du, mit welchem Hostnamen und somit welchem Empfangsconnector sich der Exchange meldet.

Standardmäßig ist es so, dass anonym über einen Empfangsconnector eingelieferte E-Mails nicht an externe Empfänger weitergeleitet werden dürfen, sonst wäre der Exchange ja ein offenes Relay. Hier gibt es eine entsprechende Anleitung, wie ein Empfangsconnector eingestellt werden muss, damit auch anonyme Einsender nach extern schicken dürfen.

[Maniska]

Da über diesen Empfangsconnector auch unser ERP System seit Jahren erfolgreich Mails versendet, der "Vorgängerserver" des Verschlüsselungssystems unter Windows wunderbar schicken konnte (selbe IP) und ich auch manuell (von einem anderen System) eine Nachricht raus schicken konnte (siehe Punkt "Connector getestet, --> Anonymer Versand nach außen geht"), gehe ich davon aus, dass der Fehler wo anders liegt.

Via Telnet bekomme ich "bad Port" zurück, was mich nicht wundert, weil Telnet zwischen den Netzen nicht erlaubt ist.

Ich verstehe nicht, warum interne Mails verarbeitet werden, Externe aber nicht, und zwar NUR VON DIESEM System. Das einzige was hierbei anders ist, ist dass diese Maschine in einem seperaten Netz steht.

Dann dürfte er aber doch nur entweder ganz (Mails zum Mailserver werden unanbhängig von der Zieladresse durchgelassen) oder gar nicht (weder intern noch extern geht) funktionieren.

 

Wie gesagt, Hersteller sagt "liegt am Exchange", Systemhaus sagt "Exchange ist sauber konfiguriert, liegt an dem anderen Server", ich sage, toll, bringtmir aber nichts, wenn es nicht geht, geht's nicht, sollte aber gehen.

Was ich jetzt brauch ist ein Anhaltspunkt wo ich suchen kann, um dann dem einen oder anderen Dienstleister mit Logs vors Schienbein treten zu können um zu sagen "dein System ist es".

Bearbeitet 24. November 2017 von Maniska

[SaJu]

Wenn Du Logs brauchst und es keine gibt, heißt das Zauberwort "Wireshark" bzw. "tcpdump" auf Linux-Seite.

tcpdump kannst Du auch in eine Art Log-Datei umleiten, so dass Du es einfach innerhalb von Wireshark genauer analysieren kannst.

Schau, wo wer was über den Port 25 hin schickt. Wenn ein Empfänger falsch konfiguriert ist, hast Du Nachweise im tcpdump, dass das entsprechende System falsch konfiguriert ist.

[Maniska]

Das Problem lag dann doch an der Firewall, genauer gesagt an einem fehlerhaften NAT-Eintrag.

Nu gehts