Benutzer mit den meisten Antworten
Exchange 2010 "530.5.7.1. client was not authenticated"

Frage
-
Hi Community,
first of all, I am German, so please excuse any possible misunderstandings or non-native statements ;-)
We are migrated to a new AD domain with a new Exchange Organization from Windows 2003/Exchange 2003 to Windows 2008/Exchange 2010.
My Problem is, that we have external colleagues who needs to attach their different mail clients with POP3 to our working Exchange 2010 Server. The access of MAPI clients and OWA works perfect. Sending, receiving as well sending to internal as sending to external email addresses works excepting with POP3.
I have configured the receive connector for clients with Exchange authentication. The certificate includes all fqdn etc.
Trying to connect from external Outlook 2003 client with POP3 works as well. Receiving mails works, sending mails to internal mail addresses works as well, but seding to external mail addresses brings the error message during sending process of outlook: "530.5.7.1. client was not authenticated"
Can you help me with this, or do you need any further information (what I suggest), then please contact me and I will try to inform you as far as I can do.
Thanks in advance and best regards,
Maiko
Antworten
-
Hallo Norbert...
ich hab´s ich hab´s ich hab´s ........ *luftsprung*
Es lag am smtp smarthost des Providers. Versende ich direkt über den MX - also direkt ins Internet - funktioniert der AutoReply...
Ich habe im Sendconnector unter "Network" die Markierung auf "Use domain name system (DNS) "MX" records to route mail automatically" gesetzt. Gut, dass ich beim INternetprovider den PTR bereits gesetzt habe und auf unsere public IP verknüpft habe.
Irgendwelche Bedenken, das so zu lassen? Dann müsste ich beim Mailprovider anklopfen und fragen, warum die unseren Exchange nicht über den Smarthost relayen lassen - ich meine, er authentifiziert sich doch über seinen Benutzernamen und Passwort, oder?
Danke für einen letzten Tipp
- Als Antwort markiert FCADMIN Dienstag, 16. Juli 2013 12:09
Alle Antworten
-
Du schreibst hier in einem deutschsprachigen Forum. ;) wie wär's dann mit deiner Muttersprache? Mach mal einen Test: der Default clientconnector jedes Exchange 2010 ist per Default korrekt konfiguriert. Er lauscht auf dem Port 587. damit sollte eigentlich das interne und externe senden per smtp für deine User möglich sein. Bye Norbert
-
OK - deutsches Forum - ich dachte, das wird allen zur Verfügung
gestellte... sorry.Unser Exchangeserve empfängt und sendet Mails von und
nach intern und extern. Die Anmeldung über OWA, MAPI, ActiveSync
funktioniert.Die Anmeldung von einem entfernten Client (nicht im
Netzwerk und/oder der Domäne), bei dem ich einen POP3 Zugriff
eingerichtet habe funktioniert für den Empfang von allen Mails
wunderbar. Der Versand nach intern funktioniert über Port 25 - also
offensichtlich den Default Empfangsconnector - auch. Nur nach extern
nicht.- Fehlermeldung: " 550 5.7.1 Unable to relay" in der Unzustellbarkeitsmail
Konfiguriere ich am entfernten Client den Postausgangsserver mit Port 587 funktioniert beides nicht.
- Fehlermeldung: "....Antwort des Servers: 530.5.7.1 Client was not authenticated"
Ich
habe in den Empfangsconnectoren bereits viele Kombinationen getestet -
in erster Linie würde ich gerne über den Client, also Port: 587,
verschicken. Ich weiß leider nicht, wo ich ggf. das Versenden für
authentifizierte Windows User von externen Clients konfigurieren kann,
wenn das möglich ist.Bin aktuell wieder auf den Standardeinstellungen der Empfangsconnectoren - es geht leider nicht.
Ein Tipp war, den TLS komplett zu deaktivieren - brachte auch nichts.
Nur Exchange User, oder nur Windows authentifizierte brachte auch nichts...
Keine
Ahnung, wo es noch hängt. Aufgrund der vielen Umkonfigurationsversuche
der Empfangsconnectoren - kann man die Standardconnectoren vielleicht
einfach noch mal generieren lassen und die "alten" Standards löschen -
ggf. bringt das ja was...Beim Exchange 2007 hat das prima funktioniert.
Danke für Eure Hilfe
-
Ichhabe in den Empfangsconnectoren bereits viele Kombinationen getestet -
in erster Linie würde ich gerne über den Client, also Port: 587,
verschicken. Ich weiß leider nicht, wo ich ggf. das Versenden für
authentifizierte Windows User von externen Clients konfigurieren kann,
wenn das möglich ist.Bin aktuell wieder auf den Standardeinstellungen der Empfangsconnectoren - es geht leider nicht.
Ein Tipp war, den TLS komplett zu deaktivieren - brachte auch nichts.
-
Hallo,die Einstellungen passen alle. Ich habe alles verglichen. Dabei ist mir noch etwas aufgefallen:
Neben
dem Versenden an externe Teilnehmer, indem man sich per POP3 am
Exchange von einem externen Client aus anmeldet, funktioniert auch der
Auto Reply an externe Adressen nicht - intern wie gehabt - alles schön.Bei
den Remote Domains habe ich in den Einstellungen unter "Message Format"
die beiden Haken gesetzt ("Allow automatic replies" und "Allow
automatic forward")Zertifikate habe ich auch geprüft und die genutzten Namen sind alle im SAN hinterlegt.
Kann mir denn keiner der geschätzten Exchange-Fachleute helfen?
-
Nein, denn der Client Connector hat solche EInschränkungen nicht. Der ist per Default so konfiguriert, dass man per SMTP Mails an interne und externe Empfänger versenden kann. Wenn das bei dir nicht so ist, dann stimmt was anderes nicht. Und um genau zu sein ""530.5.7.1. client was not authenticated" bedeutet, dass sich dein Client eben nicht authentifiziert hat. Deswegen wird das nicht funktionieren. Wäre eher die Frage, warum man dann trotzdem an interne Empfänger senden kann. ;) Ich würde also erstmal an der eigentlichen Authentifizierung ansetzen. Ein praktisches Tool dafür ist bspw:
http://www.skittel.de/software/smtpdiagpro/
HTH
Norbert
-
Hallo,
das Problem mit der externen Anmeldung am SMTP und das Versenden darüber an externe Adressen konnte gelöst werden.
Das Problem, dass der AutoRply an externe Adressen nicht funktioniert (nur an interne), besteht weiterhin (ich dachte fälschlicherweise, die Ursache sei die gleiche.
Lösung zum Versenden an externe Adressen über externe Verbindung zum Exchange:
- Im Exchange Web Service (EWS) Virtual Directory war die public URL nicht hinterlegt.
- in der Exchange Management Shell mit "Get-webservicesvirtualdirectory | fl identity,internalurl,externalurl" anzeigen lassen und falls eine der beiden URLs fehlt,
- mit "Set-WebServicesVirtualDirectory -Identity "EWS (default web site)" -ExternalUrl https.//externeURL.com/EWS -BasicAuthentication $true -InternalUrl https://interneURL.local/EWS" die entsprechenden URLs einsetzen.
Leider besteht das Problem "Autoreply an externe Adressen funktioniert nicht" nach wie vor... Hat vielleicht da jemand eine Idee?
Gruß. Maiko.
-
Was? Die externalURL des Webservice soll verhindern, dass man per SMTP Clientconnector Mails nach extern einliefern kann? Also das kann ich irgendwie nicht glauben. Kannst du das nachvollziehen, wenn du die URLs wieder zurückdrehst? Welches Autoreply meinst du überhaupt? Eventuell erklärst du das nochmal genauer. Der Thread ist hier nicht wirklich übersichtlich (sicher auch der tollen Forensoftware geschuldet. :()
Bye
Norbert
-
Hallo Norbert.
Ich bin auch sehr verwundert, dass es am EWS liegen soll, aber was soll ich sagen - kaum hatte ich die externe URL über die PS eingetragen, konnte ich über SMTPDiagPro (Danke nochmal für das Tool) Mails versenden, was vorher nicht funktionierte. Ich habe es auch noch mal an einem externen Client versucht, indem ich ein Pop Konto mit meinen Server URLs erstellt habe, was auch funktionierte (und vorher nicht). Ein Gegentest verifzierte es mir - ich konnte ohne die externe URL im EWS wieder nur intern versenden - auch über den Pop Account. Die Fehlermeldung (Authentifizierung fehlgeschlagen) erscheint mir hier also völliger Humbug...
Auf die EWS-Geschichte kam ich aber aufgrund meines nun letzten Problems mit unserem neuen Exchange 2010: die AtuoReply Funktion ist nur für interne Empfänger vorhanden. Habe ich bei einem Benutzer die AutoReply Funktion für interne und externe aktiviert (ich habe bei den Remotedomains die Default entsprechend konfiguriert, das AutoReply und Forward erlaubt ist), werden automatisierte Antworten nur an interne Versender geschickt. Schreibe ich den Account (mit konfiguriertem Autoreply) von einer externen Adresse an, bekommt diese externe Adresse keine Abwesenheitsnotiz.
Hast dazu eine Idee?
Danke und Gruß,
Maiko
-
die AtuoReply Funktion ist nur für interne Empfänger vorhanden. Habe ich bei einem Benutzer die AutoReply Funktion für interne und externe aktiviert (ich habe bei den Remotedomains die Default entsprechend konfiguriert, das AutoReply und Forward erlaubt ist), werden automatisierte Antworten nur an interne Versender geschickt. Schreibe ich den Account (mit konfiguriertem Autoreply) von einer externen Adresse an, bekommt diese externe Adresse keine Abwesenheitsnotiz.
Hast dazu eine Idee?
Wie genau hast du die Remote-Domain konfiguriert. Schick mal Screenshot oder
get-remotedomain * | fl allow*, auto*
Bye
Norbert
-
...Steht vor deinem Exchange ggf. noch was, was den OOF rausfiltert? Welchen Patchstand hat eigentlich dein Exchange?...
ExchangeVersion AdminDisplayVersion
--------------- -------------------
0.1 (8.0.535.0) Version 14.2 (Build 247.5)Vor dem Exchange steht lediglich eine Firewall, auf der die Ports 25, 587, 110, 443, 80 auf den Exchange geNATet sind.
Kein Edge etc. Oder worauf wolltest Du genau hinaus?
Ich bin immer noch der Meinung, dass es mit der Konfiguration der AutoDiscovery Pfade zusammenhängen könnte. Was meinst Ihr?
Gibt es eine Standardeinstellung, mit der es in jedem Fall funktioniert - bzw. wie müssen die Pfade genau lauten (internerServer.domain.local/...? bzw. https:// externerServerZugriff.com/....?)
- Bearbeitet FCADMIN Dienstag, 16. Juli 2013 10:08 update
-
Also ist dein Exchange schonmal nicht aktuell, dann wäre es nämlich 14.3 irgendwas (SP3 Rollup 1).
Ich wollte darauf hinaus, dass OOFs ohne Absender rausgehen und deswegen diverse Filter (auch Firewalls) sowas manchmal wegwerfen. Kannst du ja im Exchange eigentlich sehen, ob ein OOF generiert wird. Und es gibt keine "Standardeinstellung" mit der es immer überall funktioniert. Das hängt von deiner Umgebung ab, was da sinnvoll konfiguriert werden muß.
Bye
Norbert
- Als Antwort vorgeschlagen Norbert-Fehlauer Dienstag, 16. Juli 2013 11:25
-
Hallo Norbert...
ich hab´s ich hab´s ich hab´s ........ *luftsprung*
Es lag am smtp smarthost des Providers. Versende ich direkt über den MX - also direkt ins Internet - funktioniert der AutoReply...
Ich habe im Sendconnector unter "Network" die Markierung auf "Use domain name system (DNS) "MX" records to route mail automatically" gesetzt. Gut, dass ich beim INternetprovider den PTR bereits gesetzt habe und auf unsere public IP verknüpft habe.
Irgendwelche Bedenken, das so zu lassen? Dann müsste ich beim Mailprovider anklopfen und fragen, warum die unseren Exchange nicht über den Smarthost relayen lassen - ich meine, er authentifiziert sich doch über seinen Benutzernamen und Passwort, oder?
Danke für einen letzten Tipp
- Als Antwort markiert FCADMIN Dienstag, 16. Juli 2013 12:09
-
Es lag am smtp smarthost des Providers. Versende ich direkt über den MX - also direkt ins Internet - funktioniert der AutoReply...
Irgendwelche Bedenken, das so zu lassen?
Um genau zu sein, ist das meine bevorzugte Konfiguration. Dann hab ich nämlich den kompletten Überblick über alle Logfiles. ;) Bye Norbert -
...Ich wollte darauf hinaus, dass OOFs ohne Absender rausgehen und deswegen diverse Filter (auch Firewalls) sowas manchmal wegwerfen. Kannst du ja im Exchange eigentlich sehen, ob ein OOF generiert wird. ...
Hi Norbert, das war ja auch mein eigentlicher Auslöser, endlich auf die reichtige Spur zu kommen. Ich hatte ja vorher geschrieben, dass ich nicht genau verstanden habe, was genau Du wissen musstest mit "...steht vor dem Exchange noch etwas...". Deine Antwort hat mich auf die richtige Fährte geschickt. Dafür danke noch mal.