diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 12:06:34 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 12:06:34 +0000 |
| commit | 5e61585d76ae77fd5e9e96ebabb57afa4d74880d (patch) | |
| tree | 2b467823aaeebc7ef8bc9e3cabe8074eaef1666d /html/BDAT_README.html | |
| parent | Initial commit. (diff) | |
| download | postfix-upstream/3.5.24.tar.xz postfix-upstream/3.5.24.zip | |
Adding upstream version 3.5.24.upstream/3.5.24upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
| -rw-r--r-- | html/BDAT_README.html | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/html/BDAT_README.html b/html/BDAT_README.html new file mode 100644 index 0000000..271aa06 --- /dev/null +++ b/html/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 <a href="http://tools.ietf.org/html/rfc3030">RFC 3030</a> CHUNKING (the BDAT command) +without BINARYMIME, in both <a href="smtpd.8.html">smtpd(8)</a> and <a href="postscreen.8.html">postscreen(8)</a>. 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/<a href="postconf.5.html">main.cf</a>: + # The logging alternative: + <a href="postconf.5.html#smtpd_discard_ehlo_keywords">smtpd_discard_ehlo_keywords</a> = chunking + # The non-logging alternative: + <a href="postconf.5.html#smtpd_discard_ehlo_keywords">smtpd_discard_ehlo_keywords</a> = chunking, silent-discard +</pre> +</blockquote> + +<p> Specify '-o <a href="postconf.5.html#smtpd_discard_ehlo_keywords">smtpd_discard_ehlo_keywords</a>=' in <a href="master.5.html">master.cf</a> +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, +<a href="postconf.5.html#smtpd_proxy_filter">smtpd_proxy_filter</a>, <a href="postconf.5.html#smtpd_milters">smtpd_milters</a>, 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, <a href="postconf.5.html#smtpd_proxy_filter">smtpd_proxy_filter</a> 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 <a href="http://tools.ietf.org/html/rfc3030">RFC 3030</a> 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 "<a href="postconf.5.html#reject_unauth_pipelining">reject_unauth_pipelining</a>" to block spambots, +then turn off Postfix's CHUNKING announcement as described above. +</p> + +<p> In <a href="http://tools.ietf.org/html/rfc4468">RFC 4468</a>, 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 <a href="http://tools.ietf.org/html/rfc3030">RFC 3030</a> which defines BDAT, is it a useless restriction +that Postfix will not enforce. </p> + +</body> + +</html> |