Du willst es genau wissen, da solltest Du schon ein bischen mehr Zeit einbringen.

Wir haben:
enctype="application/x-www-form-urlencoded" (also kein Upload)
und das Problem auf einer Nicht-Unix-Maschine

Es ist ein POST, also wird aus STDIN gelesen.

Auf jeder UNIX-Maschine wird aus STDIN im binmode :raw gelesen, das kannst Du in perldoc -f binmode nachschauen.

Das heißt, ':raw' ist auf jedem UNIX der Default, ein binmode(STDIN, ':raw'); hat keine Auswirkung, weil das ohnehin so ist.

Ein bischen weiter ausgeholt:
Der POST kann vom Formular aus dem Browser kommen oder von einem anderen UserAgent. Kommt der POST aus dem Browser, ist es sogar von Interesse, ob das mit binmode STDOUT über den Webserver zum Browser gesendet wurde. Dieses Interesse betrifft mehrzeilige Eingabefelder, wenn diese mit Text vorbelegt werden sollen. Hier zeigen Browser auf Unix/Win auch unterschiedliche Verhaltensweisen aber das nur nebenbei zum besseren Verständnis über Handler im Allgemeinen, wie das STDIN und STDOUT nunmal sind.

Nun, es gibt 'Experten', die versuchen, in Parametern, welche Du aus einem einzeiligen input-Field erwartest, Zeilenumbrüche oder ein CTRL^Z einzubauen, was mit einem UA, der nicht ein gewöhnlicher Browser ist, selbstverständlich funktioniert. Da ist jedoch nur eine Vermutung, dass es bei Dir solche Requests gibt, welche den Fehler verursachen können.

Ein anderer Grund für UA-seitige Maipulationen sind Versuche, in einem 'Mail-Formular' über die offene Subject-Eingabe dem Request einen BCC oder CC unterzujubeln und damit das Formular zum SPAM zu missbrauchen.

Mit diesen, meinen Vermutungen, kannst Du gezielt weitermachen, stelle das P nach mit einem UA (LWP::UserAgent).

Es kann also sein, dass bei Dir Request ankommen, die manipuliert sind. Und da passiert folgendes, wenn serverseitig der Layer nicht :raw ist sondern :text (nicht Unix systems)

STDIN wird nicht byte-semantisch (binary) gelesen sondern zeichenorientiert. In den Request eingebaute DOS-Escape-Sequenzen werden nicht als Oktetten (Bytes) gewertet sondern als Zeichen, da kann es schon passieren, dass da Oktetten als ein EOF gedeutet werden.

Vor ein paar Jahren hatte ich mal ein ähnliches Problem beim Öffnen von Dateien auf XP, da hat im Handle das letzte Byte gefehlt, weil der Handler im text-Modus geöffnet wurde (CR, CRLF-Problem beim Öffnen einer Datei im textmodus).