Exchange SMTP und QMAIL (Plesk) Smarthost Problem - Mailversand nicht möglich

K

kamikaze

New Member
Hallo zusammen,

versuche mal in diesen Forum reinzuschreiben vll ist das Problem bekannt und ich vermute das es vll mit Qmail und Exchange Server Probleme geben.

Also auf unseren Root-Server Suse 10.1 64bit, läuft Plesk 8.3, Qmail drauf.
Qmail scheint korrekt zu laufen, denn wenn ich jetzt in Outlook ein EMail Konto einrichte empfange ich Emails und kann auch ohne Probleme über Authentifizierung EMails über diesen Rootserver versenden. Funktioniert soweit alles bestens.

Nun möchte über einen Exchange Server, via Smarthost über diesen Rootserver versenden, da ich den SMTP-Server vom Internet Provider nicht mehr nutzen kann den ich vorher als Smarthost ohne Authentifizierung eingerichtet hatte. Nun nehme ich das gleiche Konto was ich auch vorher in Outlook getestet habe, mit den gleichen Angaben und richte damit auf dem Exchange den Smarthost mit der jeweiligen Authentifierung ein.
Die Emails bleiben alle vom Exchange in der Queue und geht keine raus.
Nehme ich jetzt irgendein Email KOnto von nem Bekannten das sich nicht auf diesen Root-Server befindet, und richte damit den Smarthost auf dem Exchange ein mit der Authentifierung gehen die Emails sofort raus.

Also liegt das Problem dennoch auf dem Rootserver obwohl Email-Dienst mit Outlook perfekt funktionert, beim Emapfang nie ein Problem und auch nicht beim Versand über Outlook.

Kann mir da einer Weiterhelfen?
 
Schau doch mal in den Logfiles des Root-Servers.
Und hat Exchange nicht auch ein Fehlerprotokoll?

huschi.
 
Also für die Logs vom Exchange warte ich noch bis ich die bekomme ich selbst habe kein Zugriff auf diesen Server.

Und auf dem Root Server hab ich in messages, mail.info, mail.warn, mail.error geschaut aber nix finden können. Suche ich in den falschen Logs?
 
Ich denke das Problem liegt beim Exchange Server. Warum wird denn dieser nicht selbst zum Versenden von Mails benutzt? Der Umweg über den Rootserver ist doch eine ziemliche Krücke, wie ich finde.
 
Natürlich wäre es besser den Exchange zu benutzen aber nach aussen hat der Server keine feste IP-Adresse daher ist es besser über dem Rootserver zu versenden.
 
HI Leute,

ich kämpfe gerade ebenfalls an diesem Problem und hoffe es hat jemand eine Lösung, oder kann mir helfen eine zu finden.

Der Exchange ist so konfiguriert per POP3-Connector die Mails abzurufen und per SMTP an den Smarthost zu verschicken.
Der POP3-Download vom Exchange klappt prima.
Der Exchange ist konfiguriert und mittels Username und Passwort unter dem SMTP-Connector eingetragen. Bei Lokale Bridgeheads ist der lokale Server eingetragen. Alles nach Best-Practice.
Aber der Versand klappt nicht. Komischerweise hat es ein/zweimal für einige Stunden funktioniert. Erklären kann ich es nicht. Aber spätestens nach einem Neustart des Exchange ist es damit vorbei gewesen. Ein erweiterter Eventlog Eintrag des Exchange sagt folgendes:

Fehler bei der Nachrichtenübermittlung an Host 'XXX.XXX.XXX.XXX' während der Übermittlung an die Remotedomäne 'mail.domain.tld' aus folgendem Grund: Der Remote-SMTP-Dienst hat die AUTH-Vereinbarung zurückgewiesen.
. Das fehlerverursachende SMTP-Verb ist 'AUTH'. Die Antwort des Remote- servers lautet '250-www.domain.tld
250-STARTTLS
250-PIPELINING
250 8BITMIME

Ich kann mich aber von diesem Exchnage Server aus über telnet und dem im SMTP-Connector konfigurierten User mittels smtp-auth einloggen und mails versenden. Auch per Mail-Client klappt die Anmeldung.
Wieso geht es dann trotzdem nicht?
Ein telnet auf dem rootserver mit "telnet localhost 25"
gibt mir auch nur zurück:
250-www.domain.tld
250-STARTTLS
250-PIPELINING
250 8BITMIME

Müßte dort nicht auch
250-smtp-auth=login
stehen?
wie ist es bei euch auf den Servern?
System rootserver:
suse 10.1 + plesk 8.3 + qmail
System exchange:
SBS 2003 fully patched mit SP2 für den Exchange

Das Passwort habe ich schon x-mal gechecked und es besteht nur aus klein-Buchstaben und Zahlen und ist 6 Zeichen lang.

Vielleicht liegt es am rootserver, er nicht "Microsoft"-konform antwortet?
Auf jeden Fall macht es mich stutzig, dass 250-smtp-auth=login nicht mit auftaucht.
Maillogs auf dem Rootserver geben bis auf diesen Eintrag (und die POP3-Connectionszum abholen) nichts wieder:
Code: 
Aug 10 02:17:37 www relaylock: /var/qmail/bin/relaylock: mail from xxx.xxx.xxx.xxx:x (h-xxx.xxx.xxx.xxx.host.de.colt.net)

Als es mal für eine kurze Zeit geklappt hat (warum auch immer, es hatte sich nichts verändert) tauchte natürlich noch der smtp-auth Eintrag auf:

Code: 
Aug  9 00:14:54 www smtp_auth: SMTP connect from unknown@h-xxx.xxx.xxx.xxx.host.de.colt.net [xxx.xxx.xxx.xxx]
Aug  9 00:14:54 www smtp_auth: smtp_auth: SMTP user auth@goldjunge.at : /var/qmail/mailnames/domain.tld/auth logged in from unknown@h-xxx.xxx.xxx.xxx.host.de.colt.net [xxx.xxx.xxx.xxx]

Danke und Gruß
BruceLee
 
Da ich kein Plesk und Qmail verwende kann ich Dir keine Detail-Lösung geben, aber zumindest mal die richtige Richtung aufzeigen:

Die SMTP-AUTH-Capability wird wohl erst angezeigt werden, nachdem eine sichere Verbindung ausgehandelt worden ist (->STARTTLS). Entweder die Qmail-Config so ändern, dass es ohne SSL-Verschlüsselung geht, oder besser, dem Exchange beibringen, eine verschlüsselte Verbindung zu nehmen.
 
HI Linuxadmin,

danke für das Feedback. Ich werde deine Ansätze durchführen. Was mich aber wundert ist, dass bis vor kurzem ein 250-smpt-auth=login vorhanden war.
Ich kann nicht sagen, ob dies auf meinem rootserver der Fall war, aber zumindest kann man das plötzliche Fehlen des 250-smpt-auth=login-Eintrages in etlichen Foreneinträgen bei parallels von Plesk nachlesen.

EDIT:
vorhin ist plötzlich eine Mail durch, ohne dass sich etwas geändert hat.
Im Exchange Evelnlog tauchen plötzlich Einträge seit einer Stunde auf, die sehr merkwürdig sind:

Exakte kopie (keine Tippfehler):

Code: 
Fehler bei der Nachrichtenübermittlung an Host 'xxx.xxx.xxx.xxx' während der Übermittlung an die Remotedomäne  'mail.domain.tld' aus folgendem Grund: Der Remote-SMTP-Dienst hat die AUTH-Vereinbarung zurückgewiesen.
. Das fehlerverursachende SMTP-Verb ist 'AUTH'.  Die Antwort des Remote- servers lautet '250-www.domain.tld
250-STARTTLS
250-PIPELINING
250 8BITMIME
N CRAM-MD5 PLAIN
250-STARTT'.

Weiß jemand was das jetzt plötzlich soll?


Gruß und Danke
BruceLee
 
Last edited by a moderator:
ok, so langsam habe ich die Faxen dicke. Eine Lösung scheint in
weiter Ferne. Andere Leute mit dem Problem, haben als Lösung geäußert:
...und plötzlich ging es einfach, aber keine Ahnung warum.

Kann ich nicht mittels eines Eintrages dem Host einfach den Mailversand erlauben ohne sich authentifizieren zu müssen?
Nach dem Motto: IP x.....du bist in der "Whitelist" und darfst einfach so mailen!

Zum Beispiel mittles /etc/hosts.allow
und darin dann
tcp-env: {IP Adresse} : setenv RELAYCLIENT ?

Geht sowas? Ist das der richtige Ansatz? (Abgesehen davon, den eigentlichen Fehler zu beheben!)
Ist das richtig oder muss ich noch irgendwie dafür sorgen, dass xinetd oder qmail überhaupt wissen, was tcp-env ist und es laden?

Für jede Hilfe dankbar.

Grüße

BrucLee
 
Lösung?!

Hallo,

ich habe auch einen Qmail Server und mehrere Exchangeserver die diesen über eine Smarthost nutzen.
Je nach Qmailpatch wird die SMTP-Auth erst nach der erfolgreichen TLS-verbindung angeboten. Aus SIcherheitsgründen auch richtig so. Exchange hat damit aber Probleme. Die TLS-Verbindung wird nur erfolgreich wenn der Exchange das Zertifikat vom QMail kennt.

Bei Exchange einen Connector einrichten der TLS benutzt mit entsprechenden SMTP-Logindaten.
Das Zertifikat vom QMail-Server im Exchange(Windows)System importieren.

Nun kann exchange eine TLS-Verbindung aufbauen um sich danach zu Authentifizieren.

Hoffe das hilft dir.

gruß
stevie
 
Hi Stevie,

danke, daran hatte ich auch schon gedacht. Dafür müßte ich aber die
Domain mit einem eigenen SSL-Zertifikat einrichten, was wiederum eine
weitere IP mit sich bringt und somit weitere Kosten verursacht.

Oder hast du es anders gemacht?

Grüße und vielen Dank

BruceLee
 
Hallo,

ich habe einfach ein eigenes Zertifikat erzeugt.
Du musst ja ein Zertifikat haben, um TLS zu nutzen. Das Zertifikat, am besten das Root CA, in Exchange importieren.
Das kostet dich nichts.

Wenn du den dienst offiziel anbieten willtst ist es schon schöner mit einem gekauften Zertifikat. Dann brauchst du es, wenn alles korrekt ist auch nicht bei Exchange importieren. Es wird dann von den Offiziellen Root CAs accpeptiert.

Gruß
Steffen
 
Hallo Stevie,

aber dieser Vorschlag würde nur funktionieren, wenn das Haupt-Zertifikat des Rootservers auf die Domain ausgestellt ist, die sich per TLS über den Exchange anmelden soll. Oder verstehe ich dich falsch?

Oder hast du das gar nicht so? Falls ja, sehen alle anderen Plesk-Kunden beim Aufrufen der Plesk-Verwaltungs-Website ein Zertifkat, welches auf einen expliziten Kunden ausgestellt ist. Und das kann ich nicht machen.
Also müßte eine weieter IP und ein Zertifikat her.

Viele Grüße und Dank

BruceLee
 
Hallo Bruce,

ich nutze Plesk nicht, daher kann ich die Fragen nicht ganz genau beantworten.
Das Zertifikat, was du ausstelltst, wird nur auf den Namen des SMTP servers (QMAIL) angewendet. Also entweder auf die IP/DNS des SMTP oder die IP/DNS nach dem HELO.
Es hat also nix mit einer Webseite zu tun.
Ich habe ein Zertifikat auf die Domain ausgestellt, unter der man den SMTP-Server erreicht. Diese Domain habe ich als verbindung bei Exchange angegeben. Und das Zertifikat muss diese Domain abdecken.

Ich hoffe das es nun etwas klarer geworden ist.

Gruß
Stevie

PS:
http://qmail.jms1.net/smtp-service.shtml
Dort steht wie man ein Zertifikat erstellt.
 
Last edited by a moderator:
Hallo Stevie,

vielen Dank. Leider ist es so, dass es sich dabei um einen Rootserver handelt,
der mehrere Domains hostet. Da ich auf die Domain aber nur ein SSL Zertifikat legen kann, wenn ich dafür eine weitere IP anlege, ist der tatsächliche Name und der PTR Eintrag des SMTP Servers nun mal die Stammdomain des Rootservers und nicht die des Kunden.
Ich habe mal testweise einfach das Zertifikat der Stammdomain des Rootservers genommen. Leider gibt es dann die Fehlermeldung im Exchnage, dass das Zertifikat abegelaufen sei, obwohl es von Geotrust erstellt und noch bis Mitte 2009 gültig ist.
Ich denke ich werde dieses Problem anders angehen müssen.
Vielen Dank für deine Mithilfe.
Ich melde mich, sobald ich eine Lösung oder eine Behelfslösung gefunden habe.
Grüße
BruceLee
 
You must log in or register to reply here.
Back
Top