Adding upstream version 3.5.24.upstream/3.5.24upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 124 insertions, 0 deletions

diff --git a/README_FILES/BDAT_README b/README_FILES/BDAT_README
new file mode 100644
index 0000000..1248804
--- /dev/null
+++ b/README_FILES/BDAT_README
@@ -0,0 +1,124 @@
+PPoossttffiixx BBDDAATT ((CCHHUUNNKKIINNGG)) ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+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
+
+DDiissaabblliinngg BBDDAATT ssuuppppoorrtt
+
+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.
+
+IImmppaacctt oonn eexxiissttiinngg ccoonnffiigguurraattiioonnss
+
+  * 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.
+
+EExxaammppllee SSMMTTPP sseessssiioonn
+
+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: EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+        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: MMAAIILL FFRROOMM::<<sseennddeerr@@eexxaammppllee..ccoomm>>
+        S: 250 2.1.0 Ok
+        C: RRCCPPTT TTOO::<<rreecciippiieenntt@@eexxaammppllee..ccoomm>>
+        S: 250 2.1.5 Ok
+        C: BBDDAATT 1100000000
+        C: ....ffoolllloowweedd bbyy 1100000000 bbyytteess......
+        S: 250 2.0.0 Ok: 10000 bytes
+        C: BBDDAATT 112233
+        C: ....ffoolllloowweedd bbyy 112233 bbyytteess......
+        S: 250 2.0.0 Ok: 123 bytes
+        C: BBDDAATT 00 LLAASSTT
+        S: 250 2.0.0 Ok: 10123 bytes queued as 41yYhh41qmznjbD
+        C: QQUUIITT
+        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.
+
+BBeenneeffiittss ooff CCHHUUNNKKIINNGG ((BBDDAATT)) ssuuppppoorrtt wwiitthhoouutt BBIINNAARRYYMMIIMMEE
+
+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.
+
+DDoowwnnssiiddeess ooff CCHHUUNNKKIINNGG ((BBDDAATT)) ssuuppppoorrtt
+
+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.
+