diff options
Diffstat (limited to 'README_FILES/BDAT_README')
| -rw-r--r-- | README_FILES/BDAT_README | 124 |
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. + |