Incorrect Handling of Extended Header Attributes in the Parser

[more7dev]

The parser incorrectly treats extended header attributes as main attributes.
For example, in the header attribute x-keepsent: XXXX:XXXX-XXXX:XXXX; type=4; name=$KeepSent, the name attribute is mistakenly treated as a main attribute in the method \Webklex\PHPIMAP\Header::extractHeaderExtensions.
This behavior is problematic because it causes the name attribute to be recognized as a main attribute rather than an extension attribute. Consequently, the method \Webklex\PHPIMAP\Part::isAttachment mistakenly identifies the content as an attachment.

The issue lies in the header parser’s design.
Parsed headers’ values are stored in the attributes array, the key being header name (i.e. x-keepsent) and values being an object of class Attribute.
However when parsing extensions, i.e. type=4; name=$KeepSent, this convention is broken. The attributes array is populated with keys type and name as if they were actual header attributes. The extensions should be somehow attached to the existing object, representing the header being extended.

Considering our example x-keepsent: XXXX:XXXX-XXXX:XXXX; type=4; name=$KeepSent:
Expected behavior

attributes['x-keepsent'] = Attribute { values: [“XXXX:XXXX-XXXX:XXXX, type: 4, name: $KeepSent”, “XXXX:XXXX-XXXX:XXXX”]}

Actual Results

attributes['x-keepsent'] = Attribute { values: [“XXXX:XXXX-XXXX:XXXX, type: 4, name: $KeepSent”, “XXXX:XXXX-XXXX:XXXX”]}
attributes['type'] = 4
attributes['name'] = $KeepSent

[lm-cmxkonzepte]

I just stumbled across this problem as well. The x-keepsent-header seems to come from IBM Notes. The message content is recognized as an attachment, leading to an empty message.