From 5e61585d76ae77fd5e9e96ebabb57afa4d74880d Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 14:06:34 +0200 Subject: Adding upstream version 3.5.24. Signed-off-by: Daniel Baumann --- html/BDAT_README.html | 178 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 html/BDAT_README.html (limited to 'html/BDAT_README.html') 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 @@ + + + + + + +Postfix BDAT (CHUNKING) support + + + + + + + +

Postfix +BDAT (CHUNKING) support

+ +

Overview

+ +

Postfix SMTP server supports RFC 3030 CHUNKING (the BDAT command) +without BINARYMIME, in both smtpd(8) and postscreen(8). It is enabled +by default.

+ +

Topics covered in this document:

+ +

Disabling BDAT support + +
Impact on existing configurations + +
Example SMTP session + +
Benefits of CHUNKING (BDAT) support without BINARYMIME + +
Downsides of CHUNKING (BDAT) support + +

+ +

Disabling BDAT support

+ +

BDAT support is enabled by default. To disable BDAT support +globally:

+ +

+/etc/postfix/main.cf:
+    # The logging alternative:
+    smtpd_discard_ehlo_keywords = chunking
+    # The non-logging alternative:
+    smtpd_discard_ehlo_keywords = chunking, silent-discard
+

+ +

Specify '-o smtpd_discard_ehlo_keywords=' in master.cf +for the submission and smtps services, if you have clients +that benefit from CHUNKING support.

+ +

Impact on existing configurations

+ +

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.
+ +
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.
+ +

+ +

Example SMTP session

+ +

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).

+ +

+    S: 220 server.example.com
+    C: EHLO client.example.com
+    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: MAIL FROM:<sender@example.com>
+    S: 250 2.1.0 Ok
+    C: RCPT TO:<recipient@example.com>
+    S: 250 2.1.5 Ok
+    C: BDAT 10000
+    C: ..followed by 10000 bytes...
+    S: 250 2.0.0 Ok: 10000 bytes
+    C: BDAT 123
+    C: ..followed by 123 bytes...
+    S: 250 2.0.0 Ok: 123 bytes
+    C: BDAT 0 LAST
+    S: 250 2.0.0 Ok: 10123 bytes queued as 41yYhh41qmznjbD
+    C: QUIT
+    S: 221 2.0.0 Bye
+

+ +

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. +

+ +

Benefits of CHUNKING (BDAT) support without +BINARYMIME

+ +

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.

+ +

Postfix does not support BINARYMIME at this time because:

+ +

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.
+ +
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.
+ +

+ +

Downsides of CHUNKING (BDAT) support +

+ +

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. +

+ +

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.

+ + + + -- cgit v1.2.3