Struct MailParts

pub struct MailParts {
    pub alternative_bodies: Vec1<BodyPart>,
    pub inline_embeddings: Vec<Resource>,
    pub attachments: Vec<Resource>,
}

Parts which can be used to compose a multipart mail.

This can be used to crate a mail, possible having attachments with multiple alternative bodies having embedded resources which can be referred to by the bodies with content ids. This embeddings can be both body specific or shared between bodies.

Limitations

Any non alternative body will be either an attachment or an body with a inline disposition header in a multipart/related body. Which means you can not use this mechanism to e.g. create a multipart/mixed body with multiple disposition inline sub-bodies which should be displayed side-by-side. Generally this is not a very good way to create a mail, through a valid way nevertheless.

Fields

alternative_bodies: Vec1<BodyPart>

A vector of alternative bodies

A typical setup would be to have two alternative bodies one text/html and another text/plain as fallback (for which the text/plain body would be the first in the vec and the text/html body the last one).

Note that the order in the vector /// a additional text/plainis the same as the order in which they will appear in the mail. I.e. the first one is the last fallback while the last one should be shown if possible.

inline_embeddings: Vec<Resource>

A number of embeddings which should be displayed inline.

This is normally used to embed images then displayed in a html body. It is not in the scope of this part of the library to bind content id’s to resources to thinks using them to display the embeddings. This part of the library does “just” handle that they are correctly placed in the resulting Mail. The mail-templates crate provides more functionality for better ergonomics.

attachments: Vec<Resource>

A number of embeddings which should be treated as attachments

Implementations

impl MailParts

pub fn compose(self) -> Mail

Create a Mail instance based on this MailParts instance.

If this instance contains any attachments then the returned mail will be a multipart/mixed mail with the first body containing the actual mail and the other bodies containing the attachments.

If the MailParts.inline_embeddings is not empty then the mail will be wrapped in multipart/related (inside any potential multipart/mixed) containing the actual mail in the first body and the inline embeddings in the other bodies.

The mail will have a multipart/alternative body if it has more then one alternative body (inside a potential multipart/related inside a potential multipart/mixed body). This body contains one sub-body for each BodyPart instance in MailParts.alternative_bodies.

Each sub-body created for a BodyPart will be wrapped inside a multipart/related if it has body specific embeddings (with content disposition inline).