30
Exchange zu viele SMTP Hops
Hallo,
der Versender erhält folgende Fehlermeldung vom Empänger:
Als Empfänger wird Office365 (Exchange) verwendet. Leider finde ich nicht, wo man die maximale Anzahl der Hops einstellen kann.
Kann mir hier jemand weiterhelfen?
Viele Grüße,
der Versender erhält folgende Fehlermeldung vom Empänger:
550 5.0.350 Remote server returned an error -> 554 To many mail hops (30 max) Als Empfänger wird Office365 (Exchange) verwendet. Leider finde ich nicht, wo man die maximale Anzahl der Hops einstellen kann.
Kann mir hier jemand weiterhelfen?
Viele Grüße,
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2270934599
Url: https://administrator.de/contentid/2270934599
Printed on: April 25, 2024 at 17:04 o'clock
30 Comments
Latest comment
Hi,
diese stellt man nicht ein. Diese HOPs werden dann zu viel, wenn die Email zwischen zwei Mailservern hin und her geschickt wird und nicht mehr aufhört. Jede Sendung bzw Weiterleitung wird mit einem Hop hoch gezählt, bis irgendwann jemand sagt: Jetzt reichts. :c)
diese stellt man nicht ein. Diese HOPs werden dann zu viel, wenn die Email zwischen zwei Mailservern hin und her geschickt wird und nicht mehr aufhört. Jede Sendung bzw Weiterleitung wird mit einem Hop hoch gezählt, bis irgendwann jemand sagt: Jetzt reichts. :c)
Das ist schon klar, aber ich werde doch irgenwo die Zahl auf 40 Stellen können.
Moin,
wie NordicMike schon sagte:
Warum willst du die hoch stellen? Der Wert von 30 bedeutet, dass die Mail 30 mal hin und her geschickt wurde. Normalerweise sollte die Mail nicht hin und her geschickt werden. Wenn du den Wert auf 40 stellst, dann wird sie einfach öfters hin und hergeschickt bevor sie abbricht. Du solltest eher einmal die Mail-Konfiguration prüfen wieso die mail hin und her geschickt wird, anstatt den Wert zu erhöhen.
Anlaufpunkt: https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/non-d ...
Gruß
Doskias
wie NordicMike schon sagte:
Zitat von @NordicMike:
diese stellt man nicht ein. Diese HOPs werden dann zu viel, wenn die Email zwischen zwei Mailservern hin und her geschickt wird und nicht mehr aufhört. Jede Sendung bzw Weiterleitung wird mit einem Hop hoch gezählt, bis irgendwann jemand sagt: Jetzt reichts. :c)
diese stellt man nicht ein. Diese HOPs werden dann zu viel, wenn die Email zwischen zwei Mailservern hin und her geschickt wird und nicht mehr aufhört. Jede Sendung bzw Weiterleitung wird mit einem Hop hoch gezählt, bis irgendwann jemand sagt: Jetzt reichts. :c)
Warum willst du die hoch stellen? Der Wert von 30 bedeutet, dass die Mail 30 mal hin und her geschickt wurde. Normalerweise sollte die Mail nicht hin und her geschickt werden. Wenn du den Wert auf 40 stellst, dann wird sie einfach öfters hin und hergeschickt bevor sie abbricht. Du solltest eher einmal die Mail-Konfiguration prüfen wieso die mail hin und her geschickt wird, anstatt den Wert zu erhöhen.
Anlaufpunkt: https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/non-d ...
Gruß
Doskias
Moin,
lg,
Slainte
Das ist schon klar, aber ich werde doch irgenwo die Zahl auf 40 Stellen können.
nein, und das macht auch keinen Sinn. Schau dir die Received Header an, oder mach einen Trace - dann siehst du wo das Ping-Pong passiert.lg,
Slainte
Zur Erklärung, ich bin der Empfänger.
Der Versender verwendet auch Office365. Anbei die Hops. Meiner Meinung nach verlässt die Mail gar nicht den Server des Versenders.
Der Versender verwendet auch Office365. Anbei die Hops. Meiner Meinung nach verlässt die Mail gar nicht den Server des Versenders.
HOP UHRZEIT (UTC) VON ZU MIT RELAYZEIT
1 16.03.2022
14:37:43 VI1PR10MB1583.EURPRD10.PROD.OUTLOOK.COM VI1PR10MB1583.EURPRD10.PROD.OUTLOOK.COM mapi *
2 16.03.2022
14:37:43 VI1PR10MB1583.EURPRD10.PROD.OUTLOOK.COM AS4PR10MB5420.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
3 16.03.2022
14:37:45 EUR05-AM6-obe.outbound.protection.outlook.com email.versender.de SMTP-TLS 2 Sek.
4 16.03.2022
14:37:46 email.versender.de VI1EUR06FT019.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
5 16.03.2022
14:37:47 VI1EUR06FT019.eop-eur06.prod.protection.outlook.com AM0PR03CA0053.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
6 16.03.2022
14:37:47 AM0PR03CA0053.eurprd03.prod.outlook.com AM6PR10MB1894.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
7 16.03.2022
14:37:49 EUR05-VI1-obe.outbound.protection.outlook.com email.versender.de SMTP-TLS 2 Sek.
8 16.03.2022
14:37:52 email.versender.de VI1EUR06FT038.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 3 Sek.
9 16.03.2022
14:37:52 VI1EUR06FT038.eop-eur06.prod.protection.outlook.com AS9PR06CA0167.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
10 16.03.2022
14:37:52 AS9PR06CA0167.eurprd06.prod.outlook.com AM6PR10MB1880.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
11 16.03.2022
14:37:54 EUR04-DB3-obe.outbound.protection.outlook.com email.versender.de SMTP-TLS 2 Sek.
12 16.03.2022
14:38:47 email.versender.de VI1EUR06FT045.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 53 Sek.
13 16.03.2022
14:38:48 VI1EUR06FT045.eop-eur06.prod.protection.outlook.com AS9PR06CA0416.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
14 16.03.2022
14:38:48 AS9PR06CA0416.eurprd06.prod.outlook.com AM0PR10MB3588.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
15 16.03.2022
14:38:50 EUR02-AM5-obe.outbound.protection.outlook.com email.versender.de SMTP-TLS 2 Sek.
16 16.03.2022
14:38:51 email.versender.de VI1EUR06FT053.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
17 16.03.2022
14:38:52 VI1EUR06FT053.eop-eur06.prod.protection.outlook.com AM6PR10CA0008.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
18 16.03.2022
14:38:52 AM6PR10CA0008.EURPRD10.PROD.OUTLOOK.COM AM0PR10MB2020.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
19 16.03.2022
14:38:53 EUR05-AM6-obe.outbound.protection.outlook.com email.versender.de SMTP-TLS 1 Sek.
20 16.03.2022
14:38:55 email.versender.de AM7EUR06FT043.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 2 Sek.
21 16.03.2022
14:38:55 AM7EUR06FT043.eop-eur06.prod.protection.outlook.com AS8PR04CA0061.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
22 16.03.2022
14:38:55 AS8PR04CA0061.eurprd04.prod.outlook.com AM6PR10MB2469.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
23 16.03.2022
14:38:58 EUR04-VI1-obe.outbound.protection.outlook.com email.versender.de SMTP-TLS 3 Sek.
24 16.03.2022
14:38:59 email.versender.de VI1EUR06FT038.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
25 16.03.2022
14:38:59 VI1EUR06FT038.eop-eur06.prod.protection.outlook.com AS9PR06CA0126.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
26 16.03.2022
14:39:00 AS9PR06CA0126.eurprd06.prod.outlook.com HE1PR1001MB1402.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
27 16.03.2022
14:39:03 EUR05-AM6-obe.outbound.protection.outlook.com email.versender.de SMTP-TLS 3 Sek.
28 16.03.2022
14:39:04 email.versender.de VI1EUR06FT014.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
29 16.03.2022
14:39:05 VI1EUR06FT014.eop-eur06.prod.protection.outlook.com AS8PR05CA0004.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 Sek.
30 16.03.2022
14:39:05 AS8PR05CA0004.eurprd05.prod.outlook.com DB8PR10MB3579.EURPRD10.PROD.OUTLOOK.COM Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
Und das sieht für dich so aus als sei das sinnvoll hier nochmal 10 Hops drauf zu legen?
Versender kontaktieren, Fehler in der Konfiguration suchen und beheben lassen.
PS: Habe ich mit Exchange Online auch schon erlebt. Aber wenn die Leute meinen sie müssten die Cloud benutzen dann müssen sie auch lernen sie zu bedienen und mit ggf. Fehlern Seitens des Betreibers zu leben.
Versender kontaktieren, Fehler in der Konfiguration suchen und beheben lassen.
PS: Habe ich mit Exchange Online auch schon erlebt. Aber wenn die Leute meinen sie müssten die Cloud benutzen dann müssen sie auch lernen sie zu bedienen und mit ggf. Fehlern Seitens des Betreibers zu leben.
Habt ihr beide ein Out Of Office Reply oder eine ähnliche automatisch antwortende Regel drinnen?
Und das sieht für dich so aus als sei das sinnvoll hier nochmal 10 Hops drauf zu legen?
Exakt mein Gedanke 
Sieht aus als hättet ihr eine Regel oder Transportrule am start das die Mail wieder an "email.versender.de" zurückschickt.
Zitat von @NordicMike:
Habt ihr beide ein Out Of Office Reply oder eine ähnliche automatisch antwortende Regel drinnen?
Habt ihr beide ein Out Of Office Reply oder eine ähnliche automatisch antwortende Regel drinnen?
Nein, nicht.
Zitat von @ukulele-7:
Und das sieht für dich so aus als sei das sinnvoll hier nochmal 10 Hops drauf zu legen?
Spoiler-Alarm: Die richtige Antwort ist neinUnd das sieht für dich so aus als sei das sinnvoll hier nochmal 10 Hops drauf zu legen?
Versender kontaktieren, Fehler in der Konfiguration suchen und beheben lassen.
Wenn die Mail aber offensichtlich zurück geschickt wird und er der Empfänger ist, dann müsste doch der "Fehler" bzw. die Umleitungsregel die zum Absender zurück geht, beim TO liegen, oder? Denn hier wird die mail ja zuerst "zurückgeleitet" ich würde die ganze Mail-Kette betrachten und erstmal beim Empfänger schauen.Für mich sieht es so als als würde der Empfänger ja zum Sender zurück schicken, der dann wiederum zum Empfänger weiterleitet. Die erste Weiterleitung, mit der alles Anfängt, müsste doch aber beim Empfänger liegen. Oder liege ich da falsch?
Gruß
Doskias
Zitat von @mmpmmp:
Zitat von @NordicMike:
Habt ihr beide ein Out Of Office Reply oder eine ähnliche automatisch antwortende Regel drinnen?
Nein, nicht.Habt ihr beide ein Out Of Office Reply oder eine ähnliche automatisch antwortende Regel drinnen?
Eine Andere Regel?
oder (was der Admin nachschauen müsste), ggf. eine Regel im Nachrichtenfluss?
Gruß
Doskias
Zitat von @SlainteMhath:
Sieht aus als hättet ihr eine Regel oder Transportrule am start das die Mail wieder an "email.versender.de" zurückschickt.
Und das sieht für dich so aus als sei das sinnvoll hier nochmal 10 Hops drauf zu legen?
Exakt mein Gedanke Sieht aus als hättet ihr eine Regel oder Transportrule am start das die Mail wieder an "email.versender.de" zurückschickt.
Von Empfängerseite sind keine Regeln abgeändert worden. Da ist der Server weitestgehend out of the box. Die Empfangsdomäne ist als Authoritative eingetragen.
Von Versenderseite kann ich nichts sagen, aber auf andere Domänen (nicht von Office365 verwaltet) entsteht nicht dieses Problem.
Zitat von @Doskias:
Eine Andere Regel?
oder (was der Admin nachschauen müsste), ggf. eine Regel im Nachrichtenfluss?
Gruß
Doskias
Zitat von @mmpmmp:
Zitat von @NordicMike:
Habt ihr beide ein Out Of Office Reply oder eine ähnliche automatisch antwortende Regel drinnen?
Nein, nicht.Habt ihr beide ein Out Of Office Reply oder eine ähnliche automatisch antwortende Regel drinnen?
Eine Andere Regel?
oder (was der Admin nachschauen müsste), ggf. eine Regel im Nachrichtenfluss?
Gruß
Doskias
Nein, keine Regel, welche nur im Ansatz hiermit zu tun hätte.
Nein, nicht.
Also entweder sind dein/deine Send-Connectoren verbogen, ihr habt eine TransportRule am Server die Mail "refekltiert" oder der Empfänger hat eine entsprechende Regel in Outlook direkt oder im OOR eingestellt.Check das mal
Um die Ursache ein bisschen mehr einzukreisen benötigst du eine dritte Domäne oder einen Freemailer, mit dem du eine Email an dich schicken kannst. Wenn der Fehler dort auch vor kommt, liegt es an dir bzw dem Empfänger. Wenn der Fehler dort nicht vor kommt, liegt es am Versender.
1Zitat von @Doskias:
Für mich sieht es so als als würde der Empfänger ja zum Sender zurück schicken, der dann wiederum zum Empfänger weiterleitet. Die erste Weiterleitung, mit der alles Anfängt, müsste doch aber beim Empfänger liegen. Oder liege ich da falsch?
Gruß
Doskias
Zitat von @ukulele-7:
Und das sieht für dich so aus als sei das sinnvoll hier nochmal 10 Hops drauf zu legen?
Spoiler-Alarm: Die richtige Antwort ist neinUnd das sieht für dich so aus als sei das sinnvoll hier nochmal 10 Hops drauf zu legen?
Versender kontaktieren, Fehler in der Konfiguration suchen und beheben lassen.
Wenn die Mail aber offensichtlich zurück geschickt wird und er der Empfänger ist, dann müsste doch der "Fehler" bzw. die Umleitungsregel die zum Absender zurück geht, beim TO liegen, oder? Denn hier wird die mail ja zuerst "zurückgeleitet" ich würde die ganze Mail-Kette betrachten und erstmal beim Empfänger schauen.Für mich sieht es so als als würde der Empfänger ja zum Sender zurück schicken, der dann wiederum zum Empfänger weiterleitet. Die erste Weiterleitung, mit der alles Anfängt, müsste doch aber beim Empfänger liegen. Oder liege ich da falsch?
Gruß
Doskias
Da ich ja der Empfänger bin, aber keine Connectoren oder Regeln eingerichtet wurden, müssten diese bei den Defaults von Microsoft liegen.
müssten
Richtig. Da der moderne Admin jeadoch mit "Allem" rechnet, kontrolliert er dies und überlässt es nicht der Theorie oder Glaskugel ;c)Zitat von @NordicMike:
Um die Ursache ein bisschen mehr einzukreisen benötigst du eine dritte Domäne oder einen Freemailer, mit dem du eine Email an dich schicken kannst. Wenn der Fehler dort auch vor kommt, liegt es an dir bzw dem Empfänger. Wenn der Fehler dort nicht vor kommt, liegt es am Versender.
Um die Ursache ein bisschen mehr einzukreisen benötigst du eine dritte Domäne oder einen Freemailer, mit dem du eine Email an dich schicken kannst. Wenn der Fehler dort auch vor kommt, liegt es an dir bzw dem Empfänger. Wenn der Fehler dort nicht vor kommt, liegt es am Versender.
Versender -> Empfänger = Fehler wie beschrieben
Versender -> Linux-Mail-Server = kein Fehler
Linux-Mail-Server -> Empfänger = kein Fehler
des weiteren:
Empfänger -> Versender = kein Fehler
Empfänger -> Linux-Mail-Server = kein Fehler
Linux-Mail-Server -> Versender = kein Fehler
Zitat von @mmpmmp:
Da ich ja der Empfänger bin, aber keine Connectoren oder Regeln eingerichtet wurden, müssten diese bei den Defaults von Microsoft liegen.
Da ich ja der Empfänger bin, aber keine Connectoren oder Regeln eingerichtet wurden, müssten diese bei den Defaults von Microsoft liegen.
Hast du denn Zugriff auf die Transportregeln? Wir haben zum Beispiel eine Transportregel, die dem Praktikanten das senden von Mails nach extern verbietet und die Mails an den vorgesetzten des Praktikanten umleitet. Das kann der Praktikant in seinen regeln nicht sehen und folglich auch nicht verhindern. So eine Transportregel können nur die Exchange-Admins konfigurieren und sehen. Wenn man die nicht auf dem Schirm hat (durch einen MA-Wechsel zum Beispiel) führen die oft beim Nachfolger zur Verwirrung.
Leider besteht auch die Möglichkeit das MS etwas geändert hat und dadurch dieses Verhalten entsteht. Sei es ein bewusstes Update oder ein Fehler irgendwo im Backend. Ich würde jetzt erstmal sagen das eine Fehlkonfiguration auf Absender oder Empfänger-Seite wahrscheinlich ist aber ausgeschlossen ist das nicht.
Jetzt wird es interessant, es gibt auch noch einen Linux Mailserver.
Dann beschreibe mal den gesamten Zusammenhang, vor allem die Domaineinstellungen.
Dann beschreibe mal den gesamten Zusammenhang, vor allem die Domaineinstellungen.
PS: Sind kürzlich schon Mails zwischen diesen beiden Adressen erfolgreich zugestellt worden?
Zitat von @NordicMike:
Jetzt wird es interessant, es gibt auch noch einen Linux Mailserver.
Dann beschreibe mal den gesamten Zusammenhang, vor allem die Domaineinstellungen.
Jetzt wird es interessant, es gibt auch noch einen Linux Mailserver.
Dann beschreibe mal den gesamten Zusammenhang, vor allem die Domaineinstellungen.
Der Linux-Mail-Server ist ein privater Mail Server ohne Zusammenhang. Hat weder mit Versender noch Empfänger zu tun. Wurde nur zum testen verwendet.
Ist auch eine andere Domain.
Zitat von @ukulele-7:
PS: Sind kürzlich schon Mails zwischen diesen beiden Adressen erfolgreich zugestellt worden?
PS: Sind kürzlich schon Mails zwischen diesen beiden Adressen erfolgreich zugestellt worden?
Nein. Ist seit dem Systemwechsel des Versenders das erste Mal. Dieses war aber schon zum 01.01.2022. Ich kann mir aber irgenwie nicht vorstellen, dass ich der erste Empfänger mit Office365 bin.
Zitat von @Doskias:
Hast du denn Zugriff auf die Transportregeln? Wir haben zum Beispiel eine Transportregel, die dem Praktikanten das senden von Mails nach extern verbietet und die Mails an den vorgesetzten des Praktikanten umleitet. Das kann der Praktikant in seinen regeln nicht sehen und folglich auch nicht verhindern. So eine Transportregel können nur die Exchange-Admins konfigurieren und sehen. Wenn man die nicht auf dem Schirm hat (durch einen MA-Wechsel zum Beispiel) führen die oft beim Nachfolger zur Verwirrung.
Ansonsten das verhalten wie schon beschrieben von einer anderen Domain einmal testen oder es ist nur wenn du von einem Sender etwas empfängst?
Zitat von @mmpmmp:
Da ich ja der Empfänger bin, aber keine Connectoren oder Regeln eingerichtet wurden, müssten diese bei den Defaults von Microsoft liegen.
Da ich ja der Empfänger bin, aber keine Connectoren oder Regeln eingerichtet wurden, müssten diese bei den Defaults von Microsoft liegen.
Hast du denn Zugriff auf die Transportregeln? Wir haben zum Beispiel eine Transportregel, die dem Praktikanten das senden von Mails nach extern verbietet und die Mails an den vorgesetzten des Praktikanten umleitet. Das kann der Praktikant in seinen regeln nicht sehen und folglich auch nicht verhindern. So eine Transportregel können nur die Exchange-Admins konfigurieren und sehen. Wenn man die nicht auf dem Schirm hat (durch einen MA-Wechsel zum Beispiel) führen die oft beim Nachfolger zur Verwirrung.
Ich habe Zugriff auf die Transportregeln, wurden aber nie angefasst.
Hast du mal geprüft ob ein anderer Mail-Account des Versenders auf diese eine und auf eine andere Mail-Adresse schicken kann?
Zitat von @Doskias:
Hast du mal geprüft ob ein anderer Mail-Account des Versenders auf diese eine und auf eine andere Mail-Adresse schicken kann?
Hast du mal geprüft ob ein anderer Mail-Account des Versenders auf diese eine und auf eine andere Mail-Adresse schicken kann?
Ja. Alle Accounts beim Versender können zu keinem Account beim Empfänger eine Mail senden.
Kann der Versender zu einem anderem M365 Tenanten senden?
Habe nun endlich eine Antwort erhalten. Angeblich ja.
Ja, dann ist es ein Fall für die Microsoft Hotline. Versender ist M365, Empfänger ist M365, DNS ist ja richtig eingestellt...
