summaryrefslogtreecommitdiffstats
path: root/README_FILES/BDAT_README
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--README_FILES/BDAT_README124
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.
+