Skip to content

Unintuitive parsing result #98

Open
@sftse

Description

@sftse

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions