summaryrefslogtreecommitdiffstats
path: root/proto/BDAT_README.html
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--proto/BDAT_README.html178
1 files changed, 178 insertions, 0 deletions
diff --git a/proto/BDAT_README.html b/proto/BDAT_README.html
new file mode 100644
index 0000000..7839904
--- /dev/null
+++ b/proto/BDAT_README.html
@@ -0,0 +1,178 @@
+<!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=us-ascii">
+
+</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:&lt;sender@example.com&gt;</b>
+ S: 250 2.1.0 Ok
+ C: <b>RCPT TO:&lt;recipient@example.com&gt;</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, is it a useless restriction
+that Postfix will not enforce. </p>
+
+</body>
+
+</html>