diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-07 16:18:56 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-07 16:18:56 +0000 |
| commit | b7c15c31519dc44c1f691e0466badd556ffe9423 (patch) | |
| tree | f944572f288bab482a615e09af627d9a2b6727d8 /proto/BDAT_README.html | |
| parent | Initial commit. (diff) | |
| download | postfix-upstream.tar.xz postfix-upstream.zip | |
Adding upstream version 3.7.10.upstream/3.7.10upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
| -rw-r--r-- | proto/BDAT_README.html | 178 |
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..1891c7b --- /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=utf-8"> + +</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> |