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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
//-
// Copyright (c) 2024, Jason Lingle
//
// This file is part of Crymap.
//
// Crymap is free software: you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the Free Software
// Foundation, either version 3 of the License, or (at your option) any later
// version.
//
// Crymap is distributed in the hope that it will be useful, but WITHOUT ANY
// WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
// FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
// details.
//
// You should have received a copy of the GNU General Public License along with
// Crymap. If not, see <http://www.gnu.org/licenses/>.
//! The "bridge" between the common SMTP/LMTP inbound server and the specific
//! service implementations.
//!
//! The common server and the service are modelled as separate actors to permit
//! a simple implementation of each service as a single async function, which
//! gives flexibility in streaming the delivered message body.
//!
//! Data passed from the common server to the service are "requests", and data
//! passed the other way are "responses".
use Cow;
use ;
use *;
/// An SMTP response, excluding the continuation/final distinction.
>,
pub ,
);
/// The HELO/EHLO/LHLO commands.
///
/// This will occur twice on a connection where the remote host uses STARTTLS.
/// A valid AUTH command.
/// A `MAIL FROM` command.
/// An `RCPT TO` command.
/// The start of the message data.
///
/// Upon receiving `DataRequest`, the service will immediately indicate whether
/// it wishes to accept the data on the request's `respond` channel.
///
/// It then consumes `data` until EOF or it encounters an error, at which point
/// it drops `data`. Once `data` is dropped, it reads the value out of
/// `recipient_responses`. If that channel is closed, the server aborted the
/// transfer and the buffered message must be discarded. Otherwise, the server
/// is expecting the delivery to proceed.
///
/// The channel received from `recipient_responses` is used to send each
/// response required after delivery. For SMTP, this will be only one response.
/// For LMTP, it will be one response for each successful `RecipientRequest`
/// since the last reset.