Tach!
Was willst du denn dann erlauben?
Na z.B. brauche ich bei der Abfrage eine PLZ keinen String von 64kb zu akzeptieren.
Alleine schon die Tatsache, dass solche Strings unnötig ressourcen brauchen, begrenze ich die schon.
Wenn der Wert einmal als PHP-String vorliegt, was bei $_POST definitiv der Fall ist, ist kein großer Blumentopf mehr zu gewinnen. Der Speicher ist bereits belegt. Neuer zusätzlicher Speicher wird erst belegt, wenn der Wert in einen anderen String eingefügt oder anderweitig verändert wird. Reine Variablenumkopierungen ohne weitere Änderungen verdoppeln den Speicherbedarf nicht, dafür sorgt das Copy-On-Change-Prinzip. Erst wenn Werte auseinanderlaufen, wird intern kopiert, ansonsten nur quasi referenziert.
Als ich noch jung war, gabs mal Dinge wie SQL-Injection u.a., keine Ahnung, was da heute noch relevant ist.
Nicht bei Email.
PHPs mail()-Funktion wurde vor langer Zeit (noch innerhalb der 4er Reihe) sicherer gemacht. $to und $subject schlucken gefahrlos alles, was man ihnen vorsetzt. Zeilenumbrüche werden entsorgt. Für $message gibt es sowieso keine Beschränkungen. Bleibt noch $additional_headers. Da man hier die einzelnen Zeilen mit CRLF getrennt übergeben muss, kann das natürlich auch ein Angreifer ausnutzen. Das ist ein Punkt, den man beachten muss. Wenn also Zeilenumbrüche in Werten für zum Beispiel die From-Zeile enthalten sind, dann ist da was faul. Vermutlich ist auch $additional_parameters anfällig. Das wird so selten benötigt, das muss man dann im Einzelfall betrachten.
(Gegen SQL-Injection (also, natürlich nur, wenn es um Datenbank und nicht um Email geht) hilft die kontextgerechte Behandlung von einzufügenden Werten. Prüfungen auf Länge oder bestimmten Inhalt sind für SQL-Injection nicht weiter relevant.)
dedlfix.