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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Postfix BDAT (CHUNKING) support</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel='stylesheet' type='text/css' href='postfix-doc.css'>
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
BDAT (CHUNKING) support</h1>
<hr>
<h2>Overview </h2>
<p> Postfix SMTP server supports RFC 3030 CHUNKING (the BDAT command)
without BINARYMIME, in both smtpd(8) and postscreen(8). It is enabled
by default. </p>
<p> Topics covered in this document: </p>
<ul>
<li><a href="#disable"> Disabling BDAT support</a>
<li><a href="#impact"> Impact on existing configurations</a>
<li><a href="#example"> Example SMTP session</a>
<li> <a href="#benefits">Benefits of CHUNKING (BDAT) support without BINARYMIME</a>
<li> <a href="#downsides">Downsides of CHUNKING (BDAT) support</a>
</ul>
<h2> <a name="disable"> Disabling BDAT support </a> </h2>
<p> BDAT support is enabled by default. To disable BDAT support
globally: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
# The logging alternative:
smtpd_discard_ehlo_keywords = chunking
# The non-logging alternative:
smtpd_discard_ehlo_keywords = chunking, silent-discard
</pre>
</blockquote>
<p> Specify '-o smtpd_discard_ehlo_keywords=' in master.cf
for the submission and smtps services, if you have clients
that benefit from CHUNKING support. </p>
<h2> <a name="impact"> Impact on existing configurations </a> </h2>
<ul>
<li> <p> There are no changes for smtpd_mumble_restrictions,
smtpd_proxy_filter, smtpd_milters, or for postscreen settings,
except for the above mentioned option to suppress the SMTP server's
CHUNKING service announcement. </p>
<li> <p> There are no changes in the Postfix queue file content,
no changes for down-stream SMTP servers or after-queue content
filters, and no changes in the envelope or message content that
Milters will receive. </p>
</ul>
<h2> <a name="example"> Example SMTP session</a> </h2>
<p> The main differences are that the Postfix SMTP server announces
"CHUNKING" support in the EHLO response, and that instead of sending
one DATA request, the remote SMTP client may send one or more BDAT
requests. In the example below, "S:" indicates server responses,
and "C:" indicates client requests (bold font). </p>
<blockquote>
<pre>
S: 220 server.example.com
C: <b>EHLO client.example.com</b>
S: 250-server.example.com
S: 250-PIPELINING
S: 250-SIZE 153600000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-DSN
S: 250-SMTPUTF8
S: 250 CHUNKING
C: <b>MAIL FROM:<sender@example.com></b>
S: 250 2.1.0 Ok
C: <b>RCPT TO:<recipient@example.com></b>
S: 250 2.1.5 Ok
C: <b>BDAT 10000</b>
C: <b>..followed by 10000 bytes...</b>
S: 250 2.0.0 Ok: 10000 bytes
C: <b>BDAT 123</b>
C: <b>..followed by 123 bytes...</b>
S: 250 2.0.0 Ok: 123 bytes
C: <b>BDAT 0 LAST</b>
S: 250 2.0.0 Ok: 10123 bytes queued as 41yYhh41qmznjbD
C: <b>QUIT</b>
S: 221 2.0.0 Bye
</pre>
</blockquote>
<p> Internally in Postfix, there is no difference between mail that
was received with BDAT or with DATA. Postfix smtpd_mumble_restrictions,
policy delegation queries, smtpd_proxy_filter and Milters all behave
as if Postfix received (MAIL + RCPT + DATA + end-of-data). However,
Postfix will log BDAT-related failures as "xxx after BDAT" to avoid
complicating troubleshooting (xxx = 'lost connection' or 'timeout'),
and will log a warning when a client sends a malformed BDAT command.
</p>
<h2> <a name="benefits">Benefits of CHUNKING (BDAT) support without
BINARYMIME</a> </h2>
<p> Support for CHUNKING (BDAT) was added to improve interoperability
with some clients, a benefit that would reportedly exist even without
Postfix support for BINARYMIME. Since June 2018, Wietse's mail
server has received BDAT commands from a variety of systems. </p>
<p> Postfix does not support BINARYMIME at this time because: </p>
<ul>
<li> <p> BINARYMIME support would require moderately invasive
changes to Postfix, to support email content that is not line-oriented.
With BINARYMIME, the Content-Length: message header specifies the
length of content that may or may not have line boundaries. Without
BINARYMIME support, email RFCs require that binary content is
base64-encoded, and formatted as lines of text. </p>
<li> <p> For delivery to non-BINARYMIME systems including UNIX mbox,
the available options are to convert binary content into 8bit text,
one of the 7bit forms (base64 or quoted-printable), or to return
email as undeliverable. Any conversion would obviously break digital
signatures, so conversion would have to happen before signing. </p>
</ul>
<h2> <a name="downsides">Downsides of CHUNKING (BDAT) support</a>
</h2>
<p> The RFC 3030 authors did not specify any limitations on how
clients may pipeline commands (i.e. send commands without waiting
for a server response). If a server announces PIPELINING support,
like Postfix does, then a remote SMTP client can pipeline all
commands following EHLO, for example, MAIL/RCPT/BDAT/BDAT/MAIL/RCPT/BDAT,
without ever having to wait for a server response. This means that
with BDAT, the Postfix SMTP server cannot distinguish between a
well-behaved client and a spambot, based on their command pipelining
behavior. If you require "reject_unauth_pipelining" to block spambots,
then turn off Postfix's CHUNKING announcement as described above.
</p>
<p> In RFC 4468, the authors write that a client may pipeline
commands, and that after sending BURL LAST or BDAT LAST, a client
must wait for the server's response. But as this text does not
appear in RFC 3030 which defines BDAT, it is a useless restriction
that Postfix will not enforce. </p>
</body>
</html>
|
