SPAM Abwehr - Ist markocupic/contao-altcha-antispam noch eine aktuelle Waffe?

Hallo zusammen,
wir haben auf einer Contao 4.13 Seite erhebliche "Probleme" mit SPAM aus einem Kontaktformular. Die Bordmittel mit der Sicherheitsabfrage sind eingesetzt, reduzieren das Aufkommen aber nur unwesentlich. Auf der Suche nach weiteren Möglichkeiten sind wir auf diese Erweiterung gestossen, da sie den Einsatz von ALTCHA ermöglicht. reCaptcha funktioniert sehr gut aber scheidet aus DSGVO Gründen bei uns aus.

Installation etc war kein Problem aber so richtig das Problem lösen tut die Erweiterung (bisher) noch nicht.

Mir fällt jetzt auf, dass die Erweiterung schon etwas länger nicht aktualisiert wurde. Die in der Erweiterung liegende lokale Version der public/altcha/js/altcha.js, liegt im ALTCHA Projekt in einer aktuellen Version vor. Ich hatte die mal ausgetauscht und "gefühlt" ist es weniger geworden aber nicht wie erwartet.

Ich frage mich nun, ob dass "einfach" nur noch Einstellungsfehler von mir sind oder ob die Erweiterungn in der vorliegenden Form evtl. nicht mehr für aktuelle Situationen verwendet werden kann?

Was denkt ihr? Welche aktuellen Ansätze sind bei euch unter Contao 4.13 erfolgreich?
Danke schon mal vorab!

ALTCHA ist ein PoW Schutz - und wenn es den Spammern egal ist wieviel CPU Ressourcen sie verbrauchen, dann hilft das nicht. Es kann auch sein, dass es eine Weile dauert, bis dass die Spam Bots von der jeweiligen Website abspringen, nachdem ALTCHA eingebunden wurde.

Man sollte vielleicht dazu erwähnen welche exakte Contao Version man hat?
Mir scheint, dass sich das Thema von Februar 2024 wiederholt.

Ich gehe stark davon aus, dass der Spam-Schutz von Contao wieder geknackt wurde.
Wir haben mehrere Instanzen mit aktueller Contao 4.13.56

Da kommen seit 28. Oktober konsequent 2 bis 4 Spam-Nachrichten pro Tag rein über das Kontaktformular. Das hält sich noch relativ in Grenzen, aber ist sicherlich nur eine Frage der Zeit bis das deutlich schlimmer wird.

Altes Thema dazu Siehe hier: https://community.contao.org/de/show...chutz-geknackt

Gibts noch weitere Betroffene davon bzw. ist das bei Contao 5 auch ein Thema oder ist die Umsetzung bzw. der Schutz da anders programmiert?

Wurde letzte Woche tatsächlich auch bei einer 5.3.40 mit dem Standard-Spamschutz vom Kunden darauf aufmerksam gemacht, dass Spam durchkommt. Die Installation hat dann Altcha gekriegt, seitdem nichts mehr.
Ansonsten hatte ich das bis jetzt nur mit Installationen (alle auf 5.3) die RSAS verwendet hatten, mit dem Standard-Spamschutz wars dann immer weg, daher hatte ich das einfach auf RSAS geschoben.
Schon etwas auffällig, die Spam-Anfragen sind auch immer recht ähnlich, genauer hatte ich mir das aber auch noch nicht angesehen…

Muss mich leider korrigieren, der Kunde hat auch mit Altcha weiterhin mehrere Spam-Anfragen erhalten. :/ Werde mich also mal noch näher damit befassen müssen.

Zitat:

---

Zitat von Stranger

Gibts noch weitere Betroffene davon bzw. ist das bei Contao 5 auch ein Thema oder ist die Umsetzung bzw. der Schutz da anders programmiert?

---

Contao 4.13.56. Seit einigen Wochen ca. 3-10 Spampostings täglich über Formulare. Die Postings ähneln sich je nach Formular und kommen von mitunter sehr unterschiedlichen IP-Adressen. Beispiel-Posting:

Code:

---

Datum: 04.11.2025 12:13
Ihr Vorname: yMesPMHpxRxHAsdTC
Ihr Nachname: qpWlWSnOSdnRRgZD
Ihre E-Mailadresse: quvewowaxef394@gmail.com
Ihr Betreff: xCwMtKUoPSwNkzQAIGmUc
Ihre Nachricht: eshQVkOioOjaDsTnAFr

---

Zitat:

---

Zitat von Spooky

ALTCHA ist ein PoW Schutz - und wenn es den Spammern egal ist wieviel CPU Ressourcen sie verbrauchen, dann hilft das nicht. Es kann auch sein, dass es eine Weile dauert, bis dass die Spam Bots von der jeweiligen Website abspringen, nachdem ALTCHA eingebunden wurde.

---

Danke Dir, Spooky, leider kann ich das nicht wirklich beobachten. Es ist über die Woche weniger geworden (~2-3} aber über das Wochenende kamen wieder 14 ... Das scheint Deinen Hinweis auf den CPU Verbrauch zu stützen :-(

Ich hatte eine kleine Messung eingebaut, die die Zeit vom Aufruf des Forms bis zum Versenden prüft. Die Bots scheinen echt schlauer geworden zu sein ... Die warten (fast) alle "realistische" Eingabezeiten ab :(

Scheint momentan aber auch wirklich zugenommen zu haben. Auch 2 andere Seiten melden erhöhtes Aufkommen (alles 4.13.56er)

Wir haben dieselbe Art von Spam mittlerweile auch bei ein paar Kunden festgestellt.

Bei mehrseitigen Formularen (z.B. mit mp_forms) habe ich noch keinen Spam beobachtet oder gemeldet bekommen. Da ist es den Bots vielleicht zu umständlich, bis zum Ende durch zu klicken.

Ich hab jetzt bei 2 Projekten zum Test die Altcha Erweiterung installiert.

Bei der einen Seite habe ich im Feld "Maximale Iterationen" 100.000 eingetragen. Danach war dann Ruhe.

Bei der anderen Seite hatte ich zunächst das gleiche eingetragen und es kamen noch einzelne durch. Daraufhin habe ich dann noch die normale Sicherheitsfrage aktiviert, das hat auch nicht gereicht.
Anschließend die Iterationen auf 10.000 gestellt, da bin ich dann aber selbst nicht mehr durchs Formular gekommen.
Im Endeffekt dann auf 20.000 gestellt und nun scheint auch hier Ruhe zu sein.

- - - - - - - - - - - - - - - - - - - - - - - -

Update 11.11. 10:36:
Zu früh gefreut, gestern gabs bei der zweiten Seite mit 20.000 Iterationen schon wieder 2 Nachrichten.

Auffällig ist, dass das wirklich immer zufällige Aneinanderreihungen von Klein- und Großbuchstaben sind und als Mail-Adresse wird immer (zumindest was ich gesehen habe) eine @gmail.com Adresse verwendet.

Die KI sagt:

Seit Ende Oktober 2025 (das deckt sich mit deinen Beobachtungen) wurde auf mehreren Botnetz-Foren eine neue Form-Spam-Kampagne dokumentiert, die:

• automatisiert Contao-, Joomla- und WordPress-Formulare ansteuert,
• Headless Chrome / Playwright nutzt,
• und JavaScript-basierte CAPTCHAs wie Altcha oder hCaptcha korrekt löst,
• aber keinen Text-Spam oder Links enthält — es geht eher um Systemauslastung und Testläufe.

Die Idee ist also nicht, Werbung zu posten, sondern Spam-Erkennungssysteme auszutesten.

Das erklärt auch, warum du „zufällige Zeichen“ bekommst, aber teils sinnvolle Checkboxen aktiviert sind.

Das sieht also danach aus als ob das alles ein Test ist. Vermutlich wollen die testen wer sich wehrt und wer nicht. Wer sich nicht wehrt und Maßnahmen ergreift, wird dann wahrscheinlich demnächst richtig mit Spam bombardiert oder anderweitig gehackt.

Ein Kunde (B2B) fragte darüber hinaus, ob man Anfragen verbieten kann bei denen eine @gmail.com Adresse verwendet wird? Das kann man natürlich mit nem Hook programmieren, aber das ist wahrscheinlich zu speziell, um es als Feature direkt in Contao aufzunehmen.

Die KI schlägt u.a. vor die Ausfüllzeit des Formulars zu vergrößern, Honeypot einsetzen (also ggf. zusätzlicher Einsatz von Rocksolid AntiSpam?), Textmusterkernnung und IPs zu begrenzen bzw. einzuschränken.

Am einfachsten erscheint mir das hier:
"Wenn z. B. 5 + Pflichtfelder nur aus >= 15 zufälligen Buchstaben bestehen, ablehnen."

"Wenn du Zugriff auf Access Logs hast, kannst du wiederkehrende IPs identifizieren."

Schlussfolgerung: Die aktuelle Spamwelle könnte durch eine relativ einfache Prüfung auf Zufallszeichen verhindert werden. Kann man darüber hinaus nicht in Contao eine Funktion programmieren, die das Ausfüllen des Formulars aus bestimmten Ländern verbietet oder kann man das schlecht verifizieren? Oder Whitelist, so dass man im Contao Formular oder per config.yml festlegen kann, dass bspw. nur noch Anfragen aus DE, AT und CH möglich sind?

Update 12.11. 01:30:
Heute kamen wieder 2 Mails rein. Die verwenden jetzt auch andere komische .com und .org Mail-Adressen, die nichts mehr mit Google zu tun haben. Damit hat sich das Thema definitiv erledigt, dass man Google Mail-Adressen aussperrt.

Bei uns hat die SPAM-Welle kein klares Muster. Die Adressen sind vielfältig und die ausgefüllten Felder auch. Man selbst sieht zwar auf den ersten Blick, dass das Müll ist aber die bisherigen Abwehrmechanismen habne es nicht abfangen können :(.

Ich hatte letzte Woche dann eine Art Wrapper erstellt, der, zusätzlich zu ALTCHA, die Formulareingaben vor dem Absenden prüft.

Ich habe eine minimale und eine maximale Ausfüllzeit zum Einstellen verwendet. Das ist aber weniger Wirkungsvoll als gedacht, weil die schlauen Biester die Zeiten tatsächlich variieren... Aber ein paar werden ausgefischt.

Dann habe ich zusätzlich noch freie Honeypot-Felder, die man in beliebiger Anzahl verwenden kann. Und auch verschiedene Typen. Text, Textarea und Checkbox.
Damit habe ich schon einige mehr rausgefischt. Aber nicht alle. Kamen immer noch einige durch.

Dann habe ich zusätzlich einen JS-Token erstellen lassen, den einfache Bots vielleicht nicht erzeugen können. Und siehe da, nun ist seit Montag Ruhe... Ich habe rel. ausführliche Logs die mir zeigen warum eine Nachricht verhindert wird und es ist tatsächlich der JS-Token, der es gebracht hat und die meisten Ablehnungsgründe erzeugt.

Ich versuche mal ob ich es hinbekomme, dass als Erweiterung ins Repository zu stellen.

Hallo,

Ein Kunde von mir hat heute auch Spam übers Kontaktformular gemeldet -
er hat allerdings die aktuelle 5.3 Version von Contao!

Danke allen, die sich darüber Gedanken machen ...
Anx

Ich denke, dass sich Kunden langfristig daran gewöhnen müssen, dass Spam durchkommt. Mit neuen Abwehrmethoden wird man hier auf Dauer und zu Zeiten von KI nicht weiterkommen.

Naja, Aufgeben ist ja keine Lösung. Man kann einfach KI gegen KI einsetzen. Das Spiel geht immer weiter ;)
Auf Dauer hält sicherlich keine Methode, da hast du schon Recht, aber da muss man dann eben immer wieder nachjustieren.

Kommt jetzt eigentlich noch was für den Contao Core 4.13 oder müssen wir jetzt den Kunden sagen, dass das Thema von der LTS nicht abgedeckt wird, da es kein direktes Sicherheitsthema ist?
Ist nicht böse gemeint. Ich frage nur ganz offen, damit wir Planungssicherheit haben und uns ggf. um andere Lösungsmöglichkeiten kümmern können/müssen.

Zitat:

---

Zitat von Stranger

Kommt jetzt eigentlich noch was für den Contao Core 4.13

---

Contao 4.13 ist Security Only, das bekommt schon lange keine Bugfixes mehr.

Zitat:

---

Zitat von Spooky

Contao 4.13 ist Security Only, das bekommt schon lange keine Bugfixes mehr.

---

Das weiß ich, daher hab ich mich ja genau so artikuliert wie ich es getan habe ;)
Ist in meinen Augen aber kein Bug, sondern schon sicherheitsrelevant. Aber das ist sicherlich Interpretationssache.

Zitat:

---

Zitat von Stranger

Ist in meinen Augen aber kein Bug, sondern schon sicherheitsrelevant.

---

In welcher Hinsicht?

Zitat:

---

Zitat von Stranger

Das weiß ich, daher hab ich mich ja genau so artikuliert wie ich es getan habe ;)
Ist in meinen Augen aber kein Bug, sondern schon sicherheitsrelevant. Aber das ist sicherlich Interpretationssache.

---

Keine Interpretationssache, das wäre ein Layer 8 Problem, die Sicherheitslücke sitzt vor dem Computer.

Über vermehrte E-Mails können sich Scammer und Spam-E-Mail-Verschicker keinen direkten Zugriff zum System erschleichen.

Spam kommt überall vor, nicht nur durch Kontaktformulare.
Hiermit wäre das Sicherheitsrisiko also die ungeschulte Person im Unternehmen, nicht das CMS, welches ein durch KI ausgefülltes Kontaktformular nicht verhindern konnte.

Das BSI stellt Leitlinien zur Informationssicherheit dar, welche jedes Unternehmen implementieren kann:
https://www.bsi.bund.de/DE/Themen/Un...hutz_node.html
https://www.bsi.bund.de/DE/Themen/Un...2_08_node.html

Es informiert auch über Risiken:
https://www.bsi.bund.de/DE/Themen/Un...ness_node.html

Der AG oder Verantwortliche sollte seine Mitarbeiter schulen.

Dasselbe Thema hatte man mit Contao 4.9 und 4.13, als 4.9 schon lange keine Bugfixes mehr erhielt, die 4.13 aber ein verstärktes Captcha als Bugfix erhalten hatte.
Hier entstand aus Langeweile auch nur ein inoffizieller Patch von einem "damals-nur-" Contributor für eine 4.9, welche schon aus dem Security-Support raus war:
https://github.com/zoglo/contao-captcha

Daher sagst du deinen Kunden:
- 4.13 ist veraltet und erhält nur noch Security-Patches bis Februar '26
- Neue Features wie Captcha-Verbesserungen fließen nur in neue Versionen ein
- Wenn Kunde Altcha verwenden will, dann das Plugin von Markocupic oder auf eine neuere Version (die nicht LTS ist) setzen, Altcha gibt es seit Contao 5.4

Wie du es deinen Kunden verkaufst, das weißt du als Marketing und Internet-Agentur besser.

Hallo Zusammen,
wir können das vermehrte Spam-Aufkommen unter oben benanntem Muster auch für die Version 5.6.4 bestätigen.
Der zusätzliche Einsatz von "contao-altcha-antispam" oder "rocksolid-antispam" brachte keine Verbesserung.

Danke an alle für die Lösungsfindung und ggf. Abhilfe durch JS-Token o.ä..

... noch als Ergänzung, soeben kam auch über das Formular des Contao-Partnerprogramms folgende Nachricht:

Code:

---

Name: YmHPCcqXubIvPpLWWdzgGzyq
E-Mail-Adresse: ***@gmail.com
Nachricht: vKkACrbWKOITSrDTyHmlH

---

Hallo zusammen,

unter der aktuellen 5.3 nimmt der Spam zu - bei einigen Projekten in den letzten Tagen festgestellt.

Beobachte weiter und habe auch die Erweiterung von Marco installiert.

Schaun mer mal :cool:

Wir sind aktuell auch davon betroffen - und zwar über dieses Schema:

Firma: FuoyYLovilKMirVdDgRE
Vorname: csgoXKNDDDBvkuet
Nachname: ZGpBVASGdEPJJBSMFlUoL
E-Mail: ....@gmail.com
Telefon: 9816083928
Interesse: ja

oder
Dein Name: cNNLvUFjtRWnTzkty
Deine E-Mail: ....@gmail.com
Deine Telefonnummer: 8761961928
Deine Information, Dein Tipp für uns: aTTpowdYbHUaovmTetcRofTa

Was für mich auffällig ist, dass die Telefonnummer trotz Eingabeprüfung 'Telefonnummer' in dieser Form durchgeht.
Ist die Validierung tatsächlich so vage, dass das durchgehen kann?

Zitat:

---

Zitat von derRenner

Ist die Validierung tatsächlich so vage, dass das durchgehen kann?

---

Die Validierung kann nicht prüfen, ob eine Telefonnummer tatsächlich existiert, falls du das meinst. Die Validierung prüft nur, ob die Eingabe als Telefonnummer intepretiert werden kann - erlaubt also bspw. keine Buchstaben, oder andere Sonderzeichen, die in einer Telefonnummer nicht vorkommen können. Nur (, ), +, / sind erlaubt: https://regex101.com/r/wlyfRO/1

nein, ich meine, wie sie aufgebaut ist.
Das sind ja "nur" Zahlenketten. Ich hätte erwartet, dass eine sie zumindest mit + oder einer Null oder so beginnen müsste.

Zitat:

---

Zitat von derRenner

Das sind ja "nur" Zahlenketten. Ich hätte erwartet, dass eine sie zumindest mit + oder einer Null oder so beginnen müsste.

---

Eine Telefonnummer muss kein + enthalten oder mit 0 beginnen.

wieder was gelernt, dass rgxp = phone wohl nicht zwingend
expects a valid phone number (numeric characters, space [ ], plus [+], minus [-], parentheses [()] and slash [/])
enthalten muss

ja, und da steht's auch: erwartet

OK, dann werd ich da mal über einen Hook an die Sache rangehen.
Welcher Hook wird hier empfohlen? validateFormField ? Oder hat hier sogar jemand was in der Schublade liegen?

Zitat:

---

Zitat von derRenner

OK, dann werd ich da mal über einen Hook an die Sache rangehen.
Welcher Hook wird hier empfohlen? validateFormField ? Oder hat hier sogar jemand was in der Schublade liegen?

---

Was genau möchtest du machen?

Zitat:

---

Zitat von Spooky

Was genau möchtest du machen?

---

Testen, damit ich das bzw. ob ich das "abfangen" kann.
ALTCHA dürfte wohl nicht (mehr) greifen - zumindest nicht für diese Fälle.

Was genau testen meinst du denn? Auf eine bestimmte Art von Telefonnummer prüfen? Dafür könntest du ja eine eigene Regular Expression einsetzen.

Kann es sein, dass sich solche Art Spam lohnt, weil das Formular eine automatische Antwort-Mail an den Versender (also in dem Fall ...@gmail.com) enthält?
Ich Frage deshalb, weil bisher keiner meiner Kunden erhöhtes Spam aufkommen gemeldet hat (weder Kunden mit 4.13, noch welche mit 5.3 bzw. 5.6). Ich habe den Leuten immer abgeraten eine automatische Antwort an den Versender schicken zu lassen und mich damit durchsetzen können.

Ist irgendwie das Wahrscheinlichste, aber wüsste dennoch nicht was denen das bringt.
Habe es aber auch bei Installationen, die keine Antwort schicken, glaube also nicht, dass die das prüfen. Du hattest vermutlich bis jetzt einfach "Glück".

Hallo zusammen.

@mlweb
Ich finde das ist eine sehr gute Beobachtung. Ein Auto-E-Mail-Responder ließe sich genau für so einen Schabernack missbrauchen.
Person A sorgt durch das falsche Ausfüllen des Formulars dafür, dass eine Antwort-E-Mail von Person B an Person C gesendet wird.
Das Ganze könnte man z. B. dafür nutzen um ein Postfach zu DDOSen, oder man möchte das die Mailadresse von Person B auf einer Blacklist landet...


Bei genauerer Betrachtung könnte ich mir aber auch sehr gut vorstellen, dass das ganze gar kein Spam ist, sondern base64 codierter Schadcode. (@base64 wahrscheinlich eher anders codiert, das wäre zu simpel)
Wenn alle Eingaben des Formulars im Backend zu einem String zusammengesetzt werden, hätte man eine lange Zeichenkette die Schadcode enthält der erstmal niemandem auffällt.
Und wenn diese lange Zeichenkette dann weiterverarbeitet werden würde, z.B. durch eine Escape- oder eine Parse-Funktion, könnte es sein, dass die (evtl. ältere) Bibliothek zum Parsen des Strings eine CEV-Lücke enthält und so den Schadcode ausführt oder die Daten zu einer SQL-Injection umwandelt.


Vielleicht gibt es ja jemanden der Zeit und Lust hat alle Kombinationsmöglichkeiten auszuprobieren und zu entschlüsseln :-)
Ihr Vorname: yMesPMHpxRxHAsdTC
Ihr Nachname: qpWlWSnOSdnRRgZD
Ihr Betreff: xCwMtKUoPSwNkzQAIGmUc
Ihre Nachricht: eshQVkOioOjaDsTnAFr

Falls da irgendetwas mit 'SELECT' oder 'INSERT INTO' raus kommt würde ich mir Gedanken machen.:eek:

Möglicherweise zielen diese Angriffe aber gar nicht gegen Contao, sondern eher gegen WordPress oder die Formulardatenverarbeitung von node.js oder einem anderen Backend-System :rolleyes:

Es kann auf jeden Fall nicht schaden sich auch mal die IP-Adressen der Absender anzusehen.
(Vorausgesetzt Ihr hab Zugriff auf die Log-Files des Web-Servers.)
(Evtl. lassen sich auch 'einfach' die entsprechenden IP's blocken.)

Für den Fall, dass in den Logs eine IP dabei ist, bei der https://www.abuseipdb.com/ anschlägt, würde ich nicht zögern und eine Meldung an das BSI abgeben.


Beste Grüße

Update meinerseits:
ich habe bei meiner "befallenen" Seite - gesamt 3 sehr kleine Formulare - anhand der Struktur der eingetragenen Telefonnummer gehandelt:
- obwohl kein Pflichtfeld, war die Telefonnummer immer ausgefüllt
- die Telefonnummer war immer nach gleichem Schema » ohne führender Null

folgende Anpassungen:
- Telefon Validierung war ja bereits gegeben
- Telefonnummer auf Pflichtfeld » war denen egal und kam dann trotzdem durch ... zeigte sich ja schon dahingehend, weil das Feld immer ausgefüllt war

danach habe ich
- Pflichtfeld
- Validierung auf 'Eigene' gestellt
- Eintrag unter 'Eigener regulärerer Ausdruck': /^(0|\+43)[0-9\/\s]+$/

Damit soll die Telefonnummer mit einer führenden Null oder +43 beginnen. Was scheinbar auch für's Erste mal Früchte trägt » heute noch kein Fake/Spam durchgekommen. Mal abwarten und hoffen, dass das fürs Erste ausreicht.

Bei drei Installationen trotz der ALTCHA Erweiterung 2-3 Spammails am Tag. 2 bei Ionos, eine bei Strato.

Den Tipp werde ich mal versuchen [emoji869] Danke Bernhard

Zitat:

---

Zitat von Samson1964

Contao 4.13.56. Seit einigen Wochen ca. 3-10 Spampostings täglich über Formulare. Die Postings ähneln sich je nach Formular und kommen von mitunter sehr unterschiedlichen IP-Adressen. Beispiel-Posting:

Code:

---

Datum: 04.11.2025 12:13
Ihr Vorname: yMesPMHpxRxHAsdTC
Ihr Nachname: qpWlWSnOSdnRRgZD
Ihre E-Mailadresse: quvewowaxef394@gmail.com
Ihr Betreff: xCwMtKUoPSwNkzQAIGmUc
Ihre Nachricht: eshQVkOioOjaDsTnAFr

---

---

Bei uns und diversen Kunden leider genauso seit Kurzem. Contao 4.13 mit einer Kombination aus Contao-eigenem Spamschutz und Altcha. Täglich diverse Spamnachrichten, die durchgehen (deutlich mehr als 2-3) und immer von gleichem Format wie oben von Samson1964 einkopiert.

Kann ich bei mindestens einer 4.13 Installation bestätigen. Der Kunde bekommt etwa 2-3 Spam-Mails am Tag, die nach dem gleichen Schema aufgebaut sind. Ist hier schon eine Lösung in Sicht?

Leider ist es eine mehrsprachige Website, sonst hätte ich die Lösung mit der Telefonnummer übergangsweise verwendet :)

https://gist.github.com/fritzmg/7829...429065c5fb6394

Kleiner Hinweis am Rande: Bisher schicken nur Chromium basierte Brower (Chrome, Edge, Opera) diesen Header mit.

Es wäre möglich zu untersuchen, ob im Nachrichtenfeld (so dieses im Formular vorhanden) zumindest ein Leerzeichen vorhanden ist. Es ist unwahrscheinlich, dass eine Nachricht nur aus einem Wort besteht.
Wie würde hier die regular expression aussehen?

Zitat:

---

Zitat von snarosy

Wie würde hier die regular expression aussehen?

---

https://regexone.com/lesson/whitespaces