Description
mail-parser
encodes mailboxes and groups slightly different to RFC5322 3.4 Address Specification, printed below reordered for better reading.
display-name = phrase
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
name-addr = [display-name] angle-addr
mailbox = name-addr / addr-spec
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
group-list = mailbox-list / CFWS / obs-group-list
group = display-name ":" [group-list] ";" [CFWS]
address = mailbox / group
address-list = (address *("," address)) / obs-addr-list
Instead of address-list
being a Vec<Address>
with
enum Address {
Group(..),
Mailbox(..),
}
mail-parser
will parse all addresses either as a Vec<Group>
or Vec<Addr>
. While this is not a bug per se, this does lead to additional cycles to map the parsed result to the context-free grammar of the RFC.
The header To: <[email protected]>, <[email protected]>
will be parsed as two simple addresses, but if a single group gets added, all of the normal addresses will be parsed into their own group without a name. Because of this, subsequent handling of the results returned by mail-parser
has to be robust against these different encodings of what should probably be handled semantically the same. This is even more confusing because if the group is in the middle of regular addresses, this will result in three groups:
To: <[email protected]>, group: (some text);, <[email protected]>
If this in intended, it would make more sense to only ever return groups so users are a bit less prone to shooting themselves in the foot.