POP3 getMessage fails with 'Line "<==UUID==>" does not match header format'

[abulhol]

We are using zend-mail to fetch emails via POP3 and IMAP. For integration tests, we run an instance of Flying Rat (https://pypi.org/project/flyingrat/) to mock a mail server with POP3. We build multipart emails in Python using MIMEMultipart and send them to the server via smtplib (all standard code used there, nothing fancy).

Now when I try to fetch the emails in zend-mail via getMessage(), it fails with the following exception::

Line "--===============0544532757501787723==" does not match header format!
vendor/zendframework/zend-mail/src/Storage/Part.php(112):   Zend\Mail\Headers::fromString('MIME-Version: 1...')
vendor/zendframework/zend-mail/src/Storage/Message.php(56): Zend\Mail\Storage\Part->__construct(Array)
vendor/zendframework/zend-mail/src/Storage/Pop3.php(63): Zend\Mail\Storage\Message->__construct(Array)
ourclass.php(298): Zend\Mail\Storage\Pop3->getMessage(1)

I have tried to debug this and printed out the $params in Message.php _construct. It looks to me like zend-mail is not able to parse the headers correctly because Flying Rat does not support the TOP command and so the whole message is downloaded. Could this be a bug?

Here is the full debug output of the $params::

 (
     [handler] => Zend\Mail\Storage\Pop3 Object
         (
             [protocol:protected] => Zend\Mail\Protocol\Pop3 Object
                 (
                     [hasTop] =>
                     [socket:protected] => Resource id #9
                     [timestamp:protected] =>
                 )

             [has:protected] => Array
                 (
                     [uniqueid] =>
                     [delete] =>
                     [create] =>
                     [top] =>
                     [fetchPart] =>
                     [flags] =>
                 )

             [iterationPos:protected] => 0
             [iterationMax:protected] =>
             [messageClass:protected] => Zend\Mail\Storage\Message
         )

     [id] => 2
     [headers] => Content-Type: multipart/alternative;
  boundary="===============0544532757501787723=="
 MIME-Version: 1.0
 To: sandbox@example.net
 From: test@example.net
 Subject: Test Url in Text
 Message-Id: <157123321515.20730.13355415221665243427@vagrant.vm>

 --===============0544532757501787723==
 Content-Type: text/plain; charset="us-ascii"
 MIME-Version: 1.0
 Content-Transfer-Encoding: 7bit

 No URL here
 --===============0544532757501787723==
 Content-Type: text/html; charset="us-ascii"
 MIME-Version: 1.0
 Content-Transfer-Encoding: 7bit

 https://example.net
 --===============0544532757501787723==--

     [noToplines] => 1
 )

[abulhol]

I have further delved into the source code. The function public static function fromString($string, $EOL = self::EOL) in Headers.php which parses the full message in this case contains no condition for a break, so it is logical that the exception is thrown when the parser reaches the multipart message body. I wonder how this bug could go unnoticed until now?

[weierophinney]

This repository has been closed and moved to laminas/laminas-mail; a new issue has been opened at https://github.com/laminas/laminas-mail/issues/6.