Mar 18, 2008, updated at Jun 17, 2008 (UTC)

6703

Smarthost funktioniert nicht.

Hallo zusammen,
ich wende mich an euch, da ich miene Möglichkeiten ausgeschöpft habe.

Zu meiner Konfiguration:

- Exchange 2003 ENT unter Windows 2000 Advanced, virtuell als Failover Cluster Konfiguriert.
- IronPort C150 Appliance als Mail Gateway, derzeit nur eingehend (göttlicher Spamfilter)

Nun sollen auch ausgehende Mails über den Ironport laufen.

Dazu wurde folgendes Konfiguriert:

- Virtueller SMTP Server: Smarthost ironport.domain.com
- SMTP Connector, "Gesamte Mail über diesen Connector an diese Smarthost weiterleiten": ironport.domain.com

Folgendes wurde beachtet:

- Firewall (IPTables) lässt SMTP Kommunikation zwischen den Servern zu
- Ironport Akzeptiert Relay von Exchange

Folgender Effekt tritt bei genannter Konfiguration auf:

- Mail wird von Outlook 2007 gesendet und liegt in "gesendete objekte"
- Mail kommt nicht an
- Mail wird von Ironport nicht registiert
- Es wird keine Fehlermail von Exchange zurückgesendet
- Es gibt keine Einträge im Eventlog

Die Mail ist also einfach verschwunden, nirgends wird ein Fehler gemeldet, jedoch auch kein Erfolg.

Würde mich über Denkanstöße freuen!

Gruß

Please also mark the comments that contributed to the solution of the article

Content-Key: 83418

Url: https://administrator.de/contentid/83418

Printed on: April 16, 2024 at 14:04 o'clock

28 Comments

Latest comment

Hallo

Dann mal nen paar denkanstöße

Wo landest Du denn wenn Du versuchst vom Exchange aus auf "ironport.domain.com" zuzugreifen? Hast Du einen entsprechenden Alias im DNS vergeben?

Wohin leitet der "IronPort" weiter? Hat der auch einen Smarthost eingetragen? Hier alles richtig?
Oder löst er selbst die Namen per DNS auf? Hier alle DNS config I.O.?

Sind die Mails noch in der Warteschlange beim Exchange? (Exchange versucht die Mails XX Stunden zuzustellen bevor ein NDR Report erstellt wird.) (Glaube standard war 24/48 Std. bin mir aber nicht ganz sicher, also nicht steinigen wenn es nicht ganz stimmt mit der Stundenzahl....

)

So, kannst ja mal berichten, vieleicht fallen mir dann noch ein paar denkanstösse ein ....

Good luck!!

Gruß
Sven

Hallo

Dann mal nen paar denkanstöße

Wo landest Du denn wenn Du versuchst vom
Exchange aus auf
"ironport.domain.com" zuzugreifen?
Hast Du einen entsprechenden Alias im DNS
vergeben?

Jup, die DNS Auflösung ist ok, ich kann auch eine Telnet Verbindung vom Exchange zum Ironport herstellen

Wohin leitet der "IronPort"
weiter? Hat der auch einen Smarthost
eingetragen? Hier alles richtig?
Oder löst er selbst die Namen per DNS
auf? Hier alle DNS config I.O.?

Für den Ironport habe ich kein spezielles Ziel konfiguriert. Allerdings scheint hier -dieses- Problem nicht zu liegen, da er schon gar keinen Maileingang den er weiterleiten könnte registiert.

Sind die Mails noch in der Warteschlange
beim Exchange? (Exchange versucht die Mails
XX Stunden zuzustellen bevor ein NDR Report
erstellt wird.) (Glaube standard war 24/48
Std. bin mir aber nicht ganz sicher, also
nicht steinigen wenn es nicht ganz stimmt mit
der Stundenzahl....

)

Es befanden / finden sich keine Mails in der Warteschlange. Auch bis heute gab es keine Fehlemeldungen oder Replies vom Exchange Server.

Muss IPTables eventuell mehr freigeben als nur den SMTP Port?

Danke jedenfalls für die Antwort!

Dann scheint eher was mit dem Connector nicht zu passen.

Welchen Adressraum hast Du denn in dem Connector eingetragen?
Ist der Alte Connector auch noch Aktiv?

Als Adressraum sollte am besten ein "*" eingetragen sein, damit er diesen weg
für alle E-Mail Adressen nimmt, die er nicht selbst auflösen kann.

Schau mal was da bei Dir eingetragen ist....

Gruß
Sven

Als Adressraum ist ein "*" mit dem Wert Kosten=1 gesetzt.

Was meinst du mit dem "alten" connector?

Gruß

Den Connector den es vorher gab?! Oder hast Du den bestehenden verändert?

Hab grad oben noch mal nachgelesen und da ist mir noch aufgefallen, das Du in dem
Virtuellen SMTP Server auch einen Smarthost eingetragen hast. Den brauchst Du nicht, weil
der Exchange alles über den Connector abwickelt.
Nimm mal bei dem Virtuellen SMTP den Smarthost wieder raus. Nicht das er sich deswegen verhaspelt....

Gruß
Sven

Der Eintrag aus dem virteullen Server wurde ohne Effekt entfernt.

Ich habe in der Tat den bestehenden COnnector einfach um den Smarthost modifiziert.

So, hmm, jetzt scheint es langsam spannend zu werden....

Du sagtest das Du per Telnet auf den "Iron" kommst. Hast Du per Telnet auch schon mal ne Mail
abgeschickt? Oder nur getestet ob Du drauf kommst?!

Ich kann eine Mail über den Ironport nur an intern versenden.

ehlo mailserver.domäne.com

mail from: ich@domain.com

rcpt to: er@domain.com

data

xxx .

Das klappt, aber nicht an Adressen die z.B. bei GMX liegen.

Ich frage mich also langsam wie er überhuapt zwischen incoming und outgoing mails unterscheiden kann... er behandelt die Telnet Mail als Incoming Mail, und legt die gmx testmails deshalb in /dev/null ab, weil ich konfiguriert habe das dort alle einkommenden Mails landen sollen, die nicht an uns gerichtet sind.

Moin Moin,

hab mir den IronPort mal angesehen. Klingt garnicht schlecht.
Nur leider findet man zur Konfiguration auf der HP leider wenig...
Bist Du schon weiter gekommen? Oder immernoch der gleiche stand wie gestern?

Gruß
Sven

Moin,
ich bin noch nicht wesentlich weiter. So wie es aussieht entscheidet er anhand der Host Access Liste wer sender, und wer empfänger ist.
Jeder der in der Regel "Relay" im Host Acceess Table matcht wird als sender behandelt.
Ich werde das gleich mal testen, kann aber wahrscheinlich erst ab 11.30 wieder intensiver dran arbeiten.

Ich habe es jetzt soweit geschafft, als das der Ironport Mails als "Outgoing" klassifiziert, und auch die dazugehörigen mailserver findet.

Was mir jedoch auffällt ist, das sich offenbar keine smtp verbindung zum GMX Server vom Ironport aus bekomme.

Ich prüfe also nochmal IPTables..

Supi, schon wieder einen schritt weiter !!

kann es sein das GMX dich (IronPort) noch nicht als "glaubwürdigen" Absender erkennt (Reverse Lookup?!)

Sonst versuch doch mal ne andere Adresse?! (Schicke Dir meine gleich per PM)
Macht er das immernoch das die Mails erst 60min. in den Queue stellt?

Gruß
Sven

kann es sein das GMX dich (IronPort) noch
nicht als "glaubwürdigen"
Absender erkennt (Reverse Lookup?!)

Jup, er stellt sie erst in den queue, was aber nach meinen Informationen eine Normale Reaktion ist, wenn er den Zeilserver nicht erreichen kann.

Ein Reverse Lookup auf die IP des Ironport ist noch nicht gegeben, allerdings hatten wir hier generell sehr lange keinen Reverse DNS Eintrag, noch bis vor wenigen Wochen.
Da haben nur reltiv wenige Mailserver Probleme gemacht, an GMX sollte es auch ohne Reverse DNS gehen.

Hm, wenn er das Ziel nicht erreichen kann ... ? Das würde ja heissen das er noch nicht weiß nach wo er die outgoing Mail hinliefern soll...

Kannst Du von dem IronPort aus ping'en oder nen tracert machen (Manche Produkte haben das onboard) vieleicht kann man dann sehen wo es hin geht bzw. wo es hängt...?

Und mit dem Reverse, erinnere mich grad, hatte wir ja gestern schon geklärt da er über das andere Gate geht bleibt ja hier alles wie gehabt! Sorry my fault!

So, werd erst mal Mahlzeit machen .... bis später.

[edit]
Hab grad noch deine Message gesehen. Jo, der MX ist richtig aufgelöst! Komisch das er dann nicht liefert.... *grübel* werd mir mal beim essen nen Kopf machen.

Hast Du vieleicht in der IPTables Firewall den "Ausgehenden" E-Mail verkehr auf eine bestimmte IP als Absender beschränkt? (Quasi das nur der Mailserver der Versendende sein darf?)
Und das jetzt geblockt wird, da es ja nun vom IronPort kommt....

Ich denke nicht, ausser ich übersehe hier etwas, Auszug aus IPTables:

/sbin/iptables -A good-dmz -p tcp -d ironport --dport smtp -j ACCEPT
/sbin/iptables -A good-dmz -p tcp ! --syn --sport smtp -j ACCEPT

/sbin/iptables -A dmz-bad -p tcp ! --syn ironport --sport smtp -j ACCEPT
/sbin/iptables -A dmz-bad -p tcp -s ironport --sport smtp -j ACCEPT

/sbin/iptables -A bad-dmz -p tcp -d ironport --dport smtp -j ACCEPT

Die Firewall steht ganz aussen?

Frage wegen der Chain "good-dmz". Bezieht sich das auf LAN->DMZ ?
Die andere wird dann wahrscheinlich DMZ -> Inet und umgekehrt sein.
Auf welchen Adaptern "horchen" denn die Chains?

Die Firewall steht ganz aussen?

Frage wegen der Chain "good-dmz".
Bezieht sich das auf LAN->DMZ ?
Die andere wird dann wahrscheinlich DMZ
-> Inet und umgekehrt sein.
Auf welchen Adaptern "horchen"
denn die Chains?

Die Firewall steht ganz aussen, und zwischen dmz und internem Netz.

Es ist eine 1-Firewall DMZ ;)

Innen: good eth0
Aussen: bad eth1
Grenznetz: dmz eth2

Sagst Du in der DMZ->BAD Chain, in der ersten Regel "Alle ausser" (!) "ironport" zulassen,
und erst in der zweiten Regel "Alle von" "ironport" zulassen

oder was macht noch mal die --syn Option... (Ist schon ein wenig her mit IPTables)

Sagst Du in der DMZ->BAD Chain, in der
ersten Regel "Alle ausser" (!)
"ironport" zulassen,
und erst in der zweiten Regel "Alle
von" "ironport" zulassen

oder was macht noch mal die --syn Option...
(Ist schon ein wenig her mit IPTables)

syn kontrolliert TCP pakete die zur kommunikations-initialisierung dienen, also keinen payload haben, auf Übereinstimmung mit der Regel das "!" bedeutet, dass die Regel nur bei Paketen greift, die "nicht syn" sind.

ehrlich gesagt weiss ich nicht so recht was das soll, da ich nicht der Urheber dieses Scriptes bin.

Ich werde die entsprechenden Zeilen mal auskommentieren und sehen was passiert.

!

Nachdem ich

/sbin/iptables -A bad-dmz -p tcp -d ironport --dport smtp -j ACCEPT

in

/sbin/iptables -A bad-dmz -p tcp -d ironport -j ACCEPT

geändert habe (natürlich nru testweise) geht es!

also fehlt noch mind. ein Port ausser 25

BAD->DMZ die Chain müßte doch für eingehende Mails sein?!
Komisch das dann die ausgehenden Mail funktionieren?!

Ah, kann es vieleicht sein das er keine DNS Auflösung machen kann um die Mail auszuliefern?
Sprich das DNS Anfragen blockiert sind?

[edit]
Vergiss es, Du konntest ja auch meinen MX Auflösen. DNS ist es dann nicht.

DNS läuft doch über udp oder? demnach dürfte es nicht daran liegen, da ich nur eine tcp regel modifiziert habe.

Hast ja recht.... (Gut Morgen Lumpi)

Was steht den in der Anderen Chain noch interessantes?
Sprich vorher war ja ausgehend ohne den IronPort geroutet. Von da her müsstest Du ja in der andern Chain ja alles drin haben was Du brauchst....

Kannst Dich ja vieleicht darüber einzeln rantasten was fehlt (Viel Spaß beim suchen, von wegen Ostern....)

Ne ma im erst, da müsste des Rätsels Lösung doch zu finden sein?!!!

Jo.. kann nicht mehr viel fehlen :/

Trotzdem mach ich erstmal feierabend. Morgen mach ich in ruhe ein paar arbeiten im Serverraum, villeicht ist mir bis dahin etwas eingefallen.

Ja dann schönen Feierabend! Und schöne Feiertage....

Bis denne

Falls es noch jemanden interessiert

Seit heute funktioniert die von mir gewünschte konfiguration.

Lösung (nach Anfrage bei kostenpflichtigem Support): Der Ironport C150 hat ein Bug, wurde als Default Route einmal etwas von Hand eingetragen, kann dieser Eintrag nicht mehr in "usedns" geändert werden.

Ein Löschen der SMTP-Routingtabelle und Neuerstellen erzeugt einen Default eintrag mit ALL = usedns :P

Da wäre ich natürlich nie im Leben drauf gekommen.

German Question Exchange Server Microsoft