179 lines
5.8 KiB
HTML
179 lines
5.8 KiB
HTML
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"https://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>
|