1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
//! Core transport traits and per-send option types.
//!
//! `Transport` models implementations that accept structured
//! [`email_message::Message`] values, while `RawTransport` models
//! implementations that send an explicit envelope plus RFC822 bytes.
//! Provider-specific options are carried through [`TransportOptions`] so the
//! core API stays transport-agnostic.
//!
//! # Quick start
//!
//! ```rust
//! use email_transport::email_message::OutboundMessage;
//! use email_transport::{SendOptions, SendReport, Transport, TransportError};
//!
//! async fn deliver<T: Transport>(
//! transport: &T,
//! message: &OutboundMessage,
//! ) -> Result<SendReport, TransportError> {
//! transport.send(message, &SendOptions::default()).await
//! }
//! ```
//!
//! Terminology:
//!
//! - A *transport* is the Rust abstraction/implementation used to send mail.
//! - A *provider* is the external service or protocol identity behind a
//! transport, such as `"resend"`, `"postmark"`, or `"smtp"`.
//! - An *instance* is one configured use of a provider, such as
//! `"transactional"` or `"marketing"`.
//!
//! # Adapter helpers (public API)
//!
//! Several utility functions are deliberately public so adapter crates can
//! share kernel logic without re-implementing it. They are part of the 1.0
//! semver surface:
//!
//! - [`accepted_recipient_emails`], derive the `To + Cc + Bcc` envelope
//! recipient list from a [`Message`].
//! - [`structured_accepted_for`], populate [`SendReport::accepted`] in a
//! structured-`Transport` adapter, honoring a [`SendOptions::envelope`]
//! override only when the adapter advertises
//! [`Capabilities::custom_envelope`].
//! - [`standard_message_headers`], render `Sender`, `Date`, and
//! `Message-ID` as a `Vec<Header>` for adapters whose provider API treats
//! them as custom headers.
//!
//! # Features
//!
//! The default feature set enables `serde`.
//!
//! - `serde`: serialization for send metadata plus registry-driven
//! deserialization of provider options.
//! - `schemars`: JSON Schema implementations for public wire types.
//! - `tracing`: the PII-conscious `TracingTransport` wrapper.
//!
//! # Platform support
//!
//! Native targets require transports and their returned futures to be
//! thread-safe. On `wasm32`, [`RuntimeBound`] and [`MaybeSend`] drop those
//! bounds so transports may hold browser or worker handles. The `tracing`
//! feature uses a web-compatible clock on `wasm32-unknown-unknown`.
//!
//! [`Message`]: email_message::Message
pub use ;
pub use TracingTransport;
pub use *;
/// Re-export of [`email_message`] so leaf consumers can reach the typed
/// outbound message and address model through a single dependency on
/// `email-transport`. Provided as a facade, the `email-message` crate
/// remains separately publishable and consumable.
pub use email_message;
/// Re-export of the `serde` crate so the [`string_newtype!`] macro can
/// reach into serde's traits via `$crate::__macro_serde::*` instead of
/// the bare `::serde` path when the `serde` feature is enabled. Downstream
/// users who invoke [`string_newtype!`] therefore do **not** need to declare
/// `serde` as a direct dependency themselves; it flows through
/// `email-transport`'s re-export.
///
/// Not part of the curated rustdoc surface; do not name directly.
pub use serde as __macro_serde;
/// Re-export of the `schemars` crate so the [`string_newtype!`] macro can
/// generate [`schemars::JsonSchema`] impls without requiring downstream macro
/// users to declare `schemars` as a direct dependency.
///
/// Not part of the curated rustdoc surface; do not name directly.
pub use schemars as __macro_schemars;