well, this is a bit unfortunate as semicolon is often used by various email clients (including Outlook) to delimit the recipients email addresses in the GUI when composing message, however when being sent, the email addresses are actually delimited by commas as can be checked by inspecting headers of a received email with two recipients.
So the delimiter which Rebex parser uses to delimit the different email addresses in the To, BCC and CC headers is a comma as defined by Section 3.4 of RFC 2822. I am sorry but we cannot consider semicolon as a valid delimiter here because it would certainly break a lot of other properly formed email headers. Moreover semicolon has already got another special meaning, as it delimits group addresses.
So to sum it up the problem here is the semicolon and if there was a comma instead, everything would be parsed well by Rebex Secure Mail:
To: Peter Peterson, firstname.lastname@example.org
However, your example unfolded us a possibility to further improve our parser, which we will look into. The opportunity lies in the fact that a username in email@example.com almost certainly will not include spaces... So if we take advantage of this fact, we would start treating your header like this:
- Address: firstname.lastname@example.org
- Displayname: PeterPeterson;
- User: jack.jackson
We know it is not perfect, as there will be only one resulting MailAddress in the collection but this is the most we can do with the improper header you encountered.
Moreover if you consider a slight modification of your original header - just change the name:
To: Jack Jackson; email@example.com
Then it can be clearly seen that to differentiate whether to treat the two entities separately or as one is more complicated task which is out of the reach of Rebex Secure Mail component.