Send email to multiple recipients

[JekRock]

Is it possible to send an email to multiple recipients?
Calling MessageBuilder.to multiple times or specifying addresses with a separator (either , or ;) returns the InvalidUser error

[DK26]

I'm now working on a high-level facade for lettre which one of its features does exactly that. You can achieve that with lettre as you said, by using the MessageBuilder.to multiple times.

Using lettre 0.10.0

use lettre::address::AddressError;
use lettre::message::MessageBuilder;

#[inline]
fn split(input: &str) -> impl Iterator<Item = &str> {
    input
        .split([',', ';'].as_ref())
        .map(|part| part.trim())
        .filter(|&part| !part.is_empty())
}

pub trait MultipleAddressParser {
    fn to_addresses(self, addresses: &str) -> Result<MessageBuilder, AddressError>;
}

impl MultipleAddressParser for MessageBuilder {
    fn to_addresses(mut self, addresses: &str) -> Result<Self, AddressError> {
        for address in split(addresses) {
            self = self.to(address.parse()?);
        }
        Ok(self)
    }
}

You can then use MessageBuilder.to_addresses("[email protected]; [email protected]").unwrap() directly.

[paolobarbolini]

Also your implementation suffers from the same issue as #690.

In general I think it'd be more helpful long term if we better documented the difference between Mailbox and Mailboxes instead of making APIs that end up making the end user do things like manual string concatenation when a strongly typed API could have been used.

[DK26]

In this case, yes.

It truly depends on the builder type. If the builder was a non-consuming builder then your upper example would have worked because the method would have been borrowing a mutable self with &mut self. But in the case of a consuming builder (such as the MessageBuilder) then you need to re-assign like in your second example, because the ownership of self is moved the moment you call the method.

https://doc.rust-lang.org/1.0.0/style/ownership/builders.html

[DK26]

Also your implementation suffers from the same issue as #690.

In general I think it'd be more helpful long term if we better documented the difference between Mailbox and Mailboxes instead of making APIs that end up making the end user do things like manual string concatenation when a strongly typed API could have been used.

My example is a high-level API on top of lettre which serves in cases where the client uses strings to navigate logic, designed for a specific use-case. I do not suggest or advice lettre how to design their API. It seemed relevant to what the author of the topic asked so I posted it but it's not to be seen as a PR in no way.

Yes, it would make sense to create Mailboxes type maybe. I'm still learning lettre myself and not aware of everything it has to offer yet.

[paolobarbolini]

Also your implementation suffers from the same issue as #690.
In general I think it'd be more helpful long term if we better documented the difference between Mailbox and Mailboxes instead of making APIs that end up making the end user do things like manual string concatenation when a strongly typed API could have been used.

My example is a high-level API on top of lettre which serves in cases where the client uses strings to navigate logic, designed for a specific use-case. I do not suggest or advice lettre how to design their API. It seemed relevant to what the author of the topic asked so I posted it but it's not to be seen as a PR in no way.

Yes, it would make sense to create Mailboxes type maybe. I'm still learning lettre myself and not aware of everything it has to offer yet.

P.S the down vote is rather distasteful considering the time and effort I burned here.

Sorry for the down vote. I appreciate the time you put into answering this and into the async-sendmail crate I see on your profile.

A high level wrapper is fine, lettre doesn't and will never be able to provide a high level API for every possible thing out there, so it's inevitable that wrappers for various things become necessary. What I didn't like about yours though, which I didn't take the time to express correctly in my previous messages, is the fact that it reinvents the API from impl FromStr for Mailboxes with the same shortcomings as our implementation, if not more because it seems to promote a style of doing everything with strings, since it allows using ; as a separator.

Anyway, this discussion went very much off the rails 😅. I'll try expanding the examples and the documentation to make these points simpler to understand.

[DK26]

I don't understand the usage with Mailboxes but all I did is manually using .to() by splitting the E-mails string and parsing each E-mail into a Mailbox object, returning error on failure.

I checked your source code:

impl FromStr for Mailboxes {
    type Err = AddressError;

    fn from_str(src: &str) -> Result<Self, Self::Err> {
        src.split(',')
            .map(|m| m.trim().parse())
            .collect::<Result<Vec<_>, _>>()
            .map(Mailboxes)
    }
}

It seems to be doing the same with the following exceptions:

1. It doesn't split on ; which is a common splitter for E-mail clients.
2. It creates a collection of Mailboxes (which I haven't encountered yet any examples on how to use, but I think that ultimately they'd end up doing the same: converting strings to Mailbox and using them).
3. It doesn't take into account splitting empty string E-mails like in my code.

I checked the final product of my MessageBuilder in a debug print, to see if I'm getting the same results as in issue #690

But I think mine shows correctly on lettre 0.10.0-rc.5:

MessageBuilder {
    headers: Headers {
        headers: [
            HeaderValue {
                name: HeaderName(
                    "From",
                ),
                raw_value: "DK Automations <[email protected]>",
                encoded_value: "\"DK Automations\" <[email protected]>",
            },
            HeaderValue {
                name: HeaderName(
                    "To",
                ),
                raw_value: "DK <[email protected]>, DK 2nd <[email protected]>, [email protected]",
                encoded_value: "DK <[email protected]>, \"DK 2nd\" <[email protected]>, [email protected]",
            },
            HeaderValue {
                name: HeaderName(
                    "Cc",
                ),
                raw_value: "DK <[email protected]>, DK 2nd <[email protected]>",
                encoded_value: "DK <[email protected]>, \"DK 2nd\" <[email protected]>",
            },
            HeaderValue {
                name: HeaderName(
                    "Bcc",
                ),
                raw_value: "DK <[email protected]>, DK 2nd <[email protected]>",
                encoded_value: "DK <[email protected]>, \"DK 2nd\" <[email protected]>",
            },
            HeaderValue {
                name: HeaderName(
                    "Reply-To",
                ),
                raw_value: "Heh <[email protected]>",
                encoded_value: "Heh <[email protected]>",
            },
            HeaderValue {
                name: HeaderName(
                    "Subject",
                ),
                raw_value: "Rust Test",
                encoded_value: "Rust Test",
            },
        ],
    },
    envelope: None,
}

Again, I am not a expert. Especially on lettre but it does seem correct. And at least, better than on issues #690 .
I'm totally relying on lettre so if there is a bug there with the parser, I'll inherit it. But it wasn't my goal to fix it.