Shouldn't "Sender" be a single string of the Envelope-Struct?

[TornaxO7]

Hi! According to the RFC5322 sender should be only one address, if I'm seeing it right:

Or am I missunderstanding the text?

[djc]

I guess you're right, but RFC 3501 specifies that there can be one or more senders in an envelope:

env-sender = "(" 1*address ")" / nil

(The 1* means that there must be at least one, according to RFC 2234.)

Note that IMAP's representation of the underlying message's headers may deviate/generalize, I guess. In this case, I can't really think of a case where multiple senders would be needed, but given the limited downside (just one sender appears in the list), I think I want to stick with RFC 3501.

[TornaxO7]

Hm... ok. What do you think? Should I also stick to RFC 3501 or do you think that it's fine if I use only one address in the sender header?

[djc]

I don't know, what are you trying to do? You could always stick to one address only for now if that makes live easier for you, and change your code later if it turns out multiple senders are required after all.

[TornaxO7]

I don't know, what are you trying to do?

I'm refactoring a part of himalaya-cli and I'm using an evenlope struct for example, which looks like this:

pub struct Envelope {
    // ----------------
    // Must-Fields
    // ----------------
    pub from:           Vec<String>,
    pub message_id:     u32,
    pub to:             Vec<String>,

    // --------------------
    // Optional fields
    // --------------------
    pub bcc:            Option<Vec<String>>,
    pub cc:             Option<Vec<String>>,
    pub custom_headers: Option<HashMap<String, Vec<String>>>,
    pub date:           Option<String>,
    pub in_reply_to:    Option<String>,
    pub reply_to:       Option<Vec<String>>,
    pub sender:         Option<String>,
    pub signature:      Option<String>,
    pub subject:        Option<String>,
}

Hm... I think that I'll add an annotation for further discussion in the code and stick to a single String now for the times being.