MIME::Parser hat diese genialen abschnitt:

First, let's get something straight: this is an evil, EVIL practice, and is incompatible with RFC-1521... hence, it's not valid MIME.
If your mailer creates multipart boundary strings that contain newlines when they appear in the message body, give it two weeks notice and find another one. If your mail robot receives MIME mail like this, regard it as syntactically incorrect MIME, which it is.

Why do I say that? Well, in RFC-1521, the syntax of a boundary is given quite clearly:

     boundary := 0*69<bchars> bcharsnospace
     bchars := bcharsnospace / " "
     bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"
                  / "," / "-" / "." / "/" / ":" / "=" / "?"
All of which means that a valid boundary string cannot have newlines in it, and any newlines in such a string in the message header are expected to be solely the result of folding the string (i.e., inserting to-be-removed newlines for readability and line-shortening only).

Yet, there is at least one brain-damaged (or malicious) user agent out there that composes mail like this:

     MIME-Version: 1.0
     Content-type: multipart/mixed; boundary="----ABC-
      123----"
     Subject: Hi... I'm a dork!
     This is a multipart MIME message (yeah, right...)
     ----ABC-
      123----
     Hi there!
We have got to discourage practices like this (and the recent file upload idiocy where binary files that are part of a multipart MIME message aren't base64-encoded) if we want MIME to stay relatively simple, and MIME parsers to be relatively robust.

Thanks to Andreas Koenig for bringing a baaaaaaaaad user agent to my attention.