Traveler 10.0.1: Problem mit eckigen Klammern in Attachmentname

[Tode]

Ich habe hier einen Traveler beim Kunden stehen, der kommt mit eckigen Klammern im Dateinamen nicht zurecht. Beim weiterleiten einer solchen Mail kommt:

2019 11:28:01 AM  Traveler: WARNING Test Username ParameterList could not parse ;   filename=AZURE[neu].docx Exception Thrown: javax.mail.internet.ParseException: Expected ';', got "[" 
[244C:000C-2554] 02/08/2019 11:28:01 AM  Traveler: SEVERE  Test Username  Exception Thrown: javax.mail.internet.ParseException: Expected ';', got "[" 
[244C:000C-2554] 02/08/2019 11:28:01 AM  Traveler: SEVERE  Test Username Exception Thrown: javax.mail.internet.ParseException: Expected ';', got "[" 
[244C:000C-2554] 02/08/2019 11:28:01 AM  Traveler: SEVERE  Test Username Notes Exception, DOC=831BCF6E576FF6A1C125839B00397F4A, field=Body  --- Domino ContentStore ---:  Server=CN=Server/O=Orga, DB=mail/tuser.nsf, Acting User=CN=Test Username/OU

Den "Bug" gab es in der Vergangenheit dokumentiert bei IBM mit verschiedenen Sonderzeichen (zuletzt mit den spitzen Klammern <>, gefixt in 9.0.1.18), aber für die eckigen Klammern habe ich das nirgends gefunden.

Das interessante: Auf meinem eigenen Test- Traveler mit der selben Traveler- Version kann ich das selbe Attachment ohne Fehler weiterleiten.

Betroffender Traveler: Domino 9.0.1FP8, Traveler 10.0.1 auf Windows
Mein Traveler: Domino 10.0.1, Traveler 10.0.1 auf Linux

Das ist ja wahrscheinlich irgendein Charset- setting. Wonach würdet Ihr suchen?

[Tode]

Ergänzung: Habe gerade die Serverdokumente und Konfigurationsdokumente beider Server verglichen... kein wesentlicher Unterschied...

[mezz]

mail.internet.ParseException deutet auf eine Mail im MIME-Format hin und wenn er da beim Parsen ins
straucheln kommt wegen dem Dateinamen, dann liegt das offenbar daran wie in dieser Mail der
Content-Disposition-Header aufgebaut ist (also vermutlich ist die Art und Weise wie der Absender den Header Kodiert hat ein Faktor).