SMTP-Fehler 550.5.7.60 SMTP; client does not have permissions to send as this sender

[peterg 15]

Hallo,

 

ich habe hier ein hoffentlich nur kleines Problem mit dem Programm „unterm Strich“. Das ist eine Controlling-/Management Software. Das Programm soll über unseren Exchange Server 2016 CU6 E-Mails verschicken können. Leider kommt beim Test des Postausgangs-SMTP in der Software folgende Fehlermeldung:

 

SMTP-Fehler 550.5.7.60 SMTP; client does not have permissions to send as this sender

 

Der Posteingang über “unterm Strich” funktioniert problemlos.
Der Exchange selbst funktioniert auch.

 

Die Hotline von unterm-Strich hat aufgegeben und sagt, dass dies kein ustrich-Problem ist. Mit dem Exchange 2016 haben Sie noch keine Erfahrung. Sie kennen aber einen Kunden wo das angeblich funktioniert, aber nicht die notwendigen Einstellungen am Exchange 2016.

 

In der Konfigurationsmaske von jedem User in ustrich gibt man für SMTP folgende Daten an:
- E-Mail Adresse: testuser@....de
- Server (in unserem Fall srv2-exch.xx.local)
- Sicherheit: unverschlüsselt (sollte laut ustrich auch so sein)
- Port: 25
- Benutzer: z.B. xx.local\testuser
- Passwort: das Domänenpasswort des Users

 

Im Web habe ich ähnliche Fehler gefunden und man sollte „NT-AUTORITÄT\SELBST“  in der Postfachstellvertretung  bei „Senden als“ eintragen. Hier kann ich aber nur auf die Liste aller Postfächer zugreifen und keinen „NT-AUTORITÄT\SELBST“ auswählen.

 

Am Exchange ist auch ein Empfangsconnector als interner Relay-Server konfiguriert. Der ustich-Server (ist auf einem eigenen Server 2016 als VM installiert) ist auch in der Bereichsdefinition enthalten. Ein Test mit Telnet funktioniert vom ustrich-Server aus. Die Berechtigungsgruppen beim internen Relay sind: Exchange-Server, Exchange-Benutzer und Anonyme Benutzer. Dann wollte ich aus ustrich als „anonymer Benutzer“ senden und das Passwort des Users in der Maske entfernen, aber dies ist ein Pflichtfeld.

 

Die Schutz vor "Schadsoftware" habe ich auch mal zum Test am Exchange abgeschaltet.

 

Nun bin ich etwas überfragt. Es wäre super, wenn jemand einen Tipp hätte.

 

Schöne Grüße,
Peter

[testperson 1.680]

Hi,

 

nutze mal Port 587 und wähle bei Verschlüsselung TLS.

Die U-Strich Anwendung soll dann immer über den "Testuser" raussenden oder trägt da jeder User seine eigenen Daten ein?

 

Gruß

Jan

[peterg 15]

Hallo,

 

bei ustrich ist jeder User angelegt. Da war nur beispielhaft. 

Ich habe bei Verschlüsselung "STARTTLS erzwingen" gewählt, dann wird er Port 587 angezeigt (den Port kann man nicht manuell eintragen).

 

Es kommt leider die gleiche Fehlermeldung. :-)

bearbeitet 8. August 2017 von peterg

[testperson 1.680]

Na dann schau mal ins SMTP Log. Mit welcher E-Mail-Adresse soll die Anwendung denn raussenden?

[peterg 15]

Die Protokollierung ist deaktiviert. Für welche Connectoren soll ich diese aktivieren?

-> Default Frontend und InternalRelay?

 

Der Nachrichtenversand über ustrich soll immer über den jeweiligen User erfolgen, welcher auch mit domäne/benutzername und Passwort, sowie Exchange-Server in der ustrich-Maske eingetragen ist. Das gilt für alle User. 

 

Daher wundert es mich, dass der User nicht die Berechtigung hat Mails über ustrich zu versenden.

[testperson 1.680]

Ich würde am Client Frontend loggen und in Ustrich eben Port 587 sowie TLS nutzen. Ansonsten am InternalRelay.

[peterg 15]

Hi,

 

ich habe nun mal die Protokollierung beim Default Frontend "Servername"  und beim InternalRelay aktiviert und das Senden über ustrich ausgeführt. Leider finde ich kein Protokoll für den Zeitpunkt. Es wird scheinbar nur zur vollen Stunde ein Log-File erstellt. Richtig?

 

Wo liegen eigentlich die Logs, die ich benötige?

 

Ich suche vergeblich unter: D:\ExchangeServer\TransportRoles\Logs\FrontEnd\....

 

Gruß,

Peter

[gelöscht 0]

Nein, das Log wird fast in Real-Time geschrieben.

 

Woher sollen wir wissen wie auf Deinem Server Logging Pfad konfiguriert ist? Get-TransportService hilft.

 

ASR

[NorbertFe 2.035]

Naja fast Real-Time ist aber auch sehr optimistisch. :) Aber im Zweifel hilft der Neustart des Transportservice, damit die ausstehenden Ereignisse ins Log geschrieben werden.