1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
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.
|
