ablock

Hallo, das Problem liegt gar nicht beim exchange server, sondern beim isa-server. Wir haben den Verkehr an der internen und externen Schnittstelle mitgesnifft. An der Internen Schnittstelle kommen die Pakete korrekt an. An der externen Schnittstelle kommen die Pakete nur fast alle richtig an. Bis zur erfolgreichen Authentifizierung ist alles ok.. Dann schickt der Exchange Server ein Paket mit einer MAIL FROM: und RCPT TO: Nachricht. Der Isa Server löscht daraus den MAIL FROM: Teil und lässt nur das RCPT TO: durch. Wenn ich mit Telnet die beiden Nachrichten in getrennten Paketen schicke, ist alles ok. Ich habe momentan keine Ahnung, warum der ISA Server den MAIL FROM: Teil löscht, zumal kein SMTP-Filter aktiv ist (zumindest weder in der Add-inns Abteilung der Konfiguration, noch in den Firewallrichtlinien für SMTP) A.Block

Hallo, danke für die Antwort, folgender Berfehl get-sendconnector smtp.1und1.de | format-list liefert: AddressSpaces : {smtp:*;1} AuthenticationCredential : System.Management.Automation.PSCredential Comment : ConnectedDomains : {} ConnectionInactivityTimeOut : 00:10:00 DNSRoutingEnabled : False DomainSecureEnabled : False Enabled : True ForceHELO : False Fqdn : s2.bs-an.de HomeMTA : Microsoft MTA HomeMtaServerId : S2 Identity : smtp.1und1.de IgnoreSTARTTLS : False IsScopedConnector : False IsSmtpConnector : True LinkedReceiveConnector : MaxMessageSize : 10MB Name : smtp.1und1.de Port : 25 ProtocolLoggingLevel : Verbose RequireTLS : False SmartHostAuthMechanism : BasicAuth SmartHosts : {smtp.1und1.de} SmartHostsString : smtp.1und1.de SourceIPAddress : 0.0.0.0 SourceRoutingGroup : Exchange Routing Group (DWBGZMFD01QNBJR) SourceTransportServers : {S2} UseExternalDNSServersEnabled : False – Hallo, zumindest habe ich es geschafft, Exchange zu überreden, kein TLS zu verwenden, indem ich in der Verwaltungsshell eingegeben habe: set-sendconnector "smtp.1und1.de" -ignorestarttls 1 Die Anmeldung beim Smarthost klappt jetzt, allerdíngs sendet Exchange dann die SMPT-Kommandos MAIL FROM: und RCPT TO: in einem Paket. Der Smarthost reagiert darauf mit einem Fehler: 503 Bad sequence of commands Der Fehler taucht nicht auf, wenn ich die Kommandos per Telnet eingebe. Mfg A. Block

Hallo, in einer virtuellen HyperV-Maschine unter Server 2008 Enterprise läuft bei uns ein exchange 2007 auf windows 2003 R2 SP2 64 Bit. Die virtuelle Maschine ist Member-Server einer Active Directory Domäne abcd. Der DNS Name der Domäne lautet abcd.local. 1und1 hostet für uns eine Domäne abcd.de. Der FQDN des Servers lautet S2.abcd.local. Die Email-Adressen der Active-Directory-Benutzer lauten: vorname.nachname@abcd.de Wir haben nun einen benutzerdefinierten Sendeconnector eingerichtet, der den 1und1-Relay smtp.1und1.de als FQDN enthält. Als Authentifizierung haben wir Standardauthentifizierung gewählt. In einem ersten Anlauf haben wir nun versucht, Mails zu versenden. Sie blieben alle in der Warteschlange hängen. Mit den Troubleshoot-Tools haben wir dann herausgefunden, dass kein passendes Zertifikat für den Exchange Server mit Namen S2.abcd.de gefunden wurde (Das vorhandene selbstsignierte lautete auf S2.abcd.local). Wir haben dann mit dem Zertifikatsdienst ein von AD-Controller signiertes Zertifikat für S2.abcd.de erstellt und mit Import-ExchangeCertificate im Exchange-Server importiert. Die Nachrichten bleiben aber weiter in der Sendqueue hängen. In den ProtocolLogs für SmtpSend steht dann: .... 220 go ahead (vom 1und1 Server) sending certificate (vom Exchange Server) und danach ist Schluss. Wir haben dann den Datenverkehr mitgesnifft und nachdem der Exchange Server ein Paket StartTLS gesendet hat, sendet er noch eins (müsste das Zertifikat sein). Nach 10 Sekunden kommt dann vom 1und1 Server: 454 TLS negotiation failed. Wir haben dann im Sendeconnector bei der Authentifizierung TLS abgewählt. Mysteriöserweise sendet der Exchange Server immer noch ein StartTLS Paket. Wir haben dann testweise die Authentifizierung auf keine eingestellt. Auch in diesem Fall sendet der Exchange Server ein StartTLS Paket. Auch nach einem kompletten Neustart des Servers bleibt das so. Ein zweiter Punkt, den wir nicht verstehen, taucht bei den Troubleshooting Tools auf. Im Verlaufe der Tests für den Fall, dass Nachrichten in einer Warteschlange hängen bleiben, versucht der Exchange Server den 1und1 Server zu kontaktieren. Auch den Verkehr haben wir mitgesnifft und der Exchange Server sendet in der ehlo-Nachricht keinen Namen mit. Dies bemängelt der 1und1 Server natürlich und die weitere Kommunikation klappt nicht, da der 1und1 Server nur Falsche-Reihenfnolge-von-Befehlen-Nachrichten zurück sendet. Wir sind für jeden Tipp echt dankbar, wo wir noch hinschauen können, A. Block