Commit 2025f314ff4e5528e8aed1839dd4c4867b0b8aa2

updated spec to org-mode
doc/postmaster-spec.txt
(236 / 269)
  
33
44* Capabilities
55
6*** Listen on arbitrary network interfaces with different configurations
7
68*** Accept e-mail for local users
79
810*** Inject e-mail messages
……
1313
1414*** Full-Pipelining
1515
16*** Ultra-Pipelining
16 Upon receiving MAIL FROM and RCPT TO, Postmaster determines the responsible
17 target for this (part of the) transaction. If that target is an ESMTP relay
18 or an LMTP local mailer, Postmaster opens a connection, says HELO, MAIL
19 FROM and RCPT TO, and from then on just acts as a proxy between the client
20 and the target.
1721
22 Full pipelining always involves the mail spool, because Postmaster may have
23 to take that session over if the outgoing connection fails for non-protocol
24 reasons, i.e. network failure.
1825
19* Configuration
26*** Ultra-Pipelining
2027
21*** Command line syntax
28*** Spam Counter-Measures
2229
23*** Configuration file
30***** SPF support via <http://www.libspf2.org/>.
2431
25* RFC (non-)conformance
32* Configuration
2633
27/etc/postmaster.cf:
28===================
34*** Example =postmaster.cf=
2935
30 | [core]
31 | logger = syslog
32 | user-id = "postmaster"
33 | group-id = "nobody"
34 | pid-file = "/var/run/postmaster.pid"
35 | spool-directory = "/var/spool/mailqueue"
36 | local-mailer = procmail
37 |
38 | [syslog]
39 | ident = "postmaster"
40 | facility = "mail"
41 |
42 | [logfile "system-wide-logfile"]
43 | file = "/var/log/postmaster-%Y-%m-%d"
44 |
45 | [pipe "procmail"]
46 | exec = "/usr/bin/procmail" "-f" "${MAIL_FROM}" "-d" "${RCPT_TO}"
47 | max_rcpt_to = 16
48 |
49 | [relay "relay.example.org"]
50 | name = relay.example.org # redundant
51 | address = 10.0.0.1
52 | address = 10.0.0.2
53 |
54 | [smtpd "mx.example.net"]
55 | name = mx.example.net # redundant
56 | listen-port = 25 # default would have been mx.example.net:25
57 | routing-table = extern
58 |
59 | [smtpd "localhost"]
60 | listen-port = ipv6-localhost:submission # ::1:587
61 | logger = system-wide-logfile
62 | routing-table = local-routes
63 | local-rcpt-to = yes
64 |
65 | [route]
66 | postmaster joe
67 | postmaster@acme.example.net postmaster
68 | postmaster@acme.example.org postmaster
69 |
70 | file "/etc/postmaster.rt"
71 |
72 | [route "extern"]
73 | @example.com @example.org
74 | @example.org mx.example.net
75 |
76 | [route "local-routes"]
77 | # simulate sendmail for processes that can connect to localhost
78 | root@ postmaster
79 | bin@ postmaster
80 | cron@ postmaster
81 | games@ postmaster
36 : [core]
37 : logger = syslog
38 : user-id = "postmaster"
39 : group-id = "nobody"
40 : pid-file = "/var/run/postmaster.pid"
41 : spool-directory = "/var/spool/mailqueue"
42 : local-mailer = procmail
43 :
44 : [syslog]
45 : ident = "postmaster"
46 : facility = "mail"
47 :
48 : [logfile "system-wide-logfile"]
49 : file = "/var/log/postmaster-%Y-%m-%d"
50 :
51 : [pipe "procmail"]
52 : exec = "/usr/bin/procmail" "-f" "${MAIL_FROM}" "-d" "${RCPT_TO}"
53 : max_rcpt_to = 16
54 :
55 : [relay "relay.example.org"]
56 : name = relay.example.org # redundant
57 : address = 10.0.0.1
58 : address = 10.0.0.2
59 :
60 : [smtpd "mx.example.net"]
61 : name = mx.example.net # redundant
62 : listen-port = 25 # default would have been mx.example.net:25
63 : routing-table = extern
64 :
65 : [smtpd "localhost"]
66 : listen-port = ipv6-localhost:submission # ::1:587
67 : logger = system-wide-logfile
68 : routing-table = local-routes
69 : local-rcpt-to = yes
70 :
71 : [route]
72 : postmaster joe
73 : postmaster@acme.example.net postmaster
74 : postmaster@acme.example.org postmaster
75 :
76 : file "/etc/postmaster.rt"
77 :
78 : [route "extern"]
79 : @example.com @example.org
80 : @example.org mx.example.net
81 :
82 : [route "local-routes"]
83 : # simulate sendmail for processes that can connect to localhost
84 : root@ postmaster
85 : bin@ postmaster
86 : cron@ postmaster
87 : games@ postmaster
8288
83Syntax:
84=======
89*** Syntax
8590
86 cf_file = ( '[' atom [quoted_string] ']' ([assignment] ['\r'] '\n')* )*
87 assignment = atom ['='] word+
88 word = atom | quoted_string
89 quoted_string = '"' ( quoted_pair | "[^\\\"\r\n]+" )* '"'
90 comment = "#[^\r\n]*"
91 quoted_pair = '\\' <anychar>
92 atom = "[^\x00-\x1F \\\"#=[]\x7F]+"
91 cf_file = ( '[' atom [quoted_string] ']' ([assignment] ['\r'] '\n')* )*
92 assignment = atom ['='] word+
93 word = atom | quoted_string
94 quoted_string = '"' ( quoted_pair | "[^\\\"\r\n]+" )* '"'
95 comment = "#[^\r\n]*"
96 quoted_pair = '\\' <anychar>
97 atom = "[^\x00-\x1F \\\"#=[]\x7F]+"
9398
94 Note that the '=' in an assignment is optional, so the [route]
95 section does, technically, not use special syntax. The fact
96 that routes are written without an '=' is a convention.
99 Note that the '=' in an assignment is optional, so the [route] section
100 does, technically, not use special syntax. The fact that routes are written
101 without an '=' is a convention.
97102
98 Config files can be represented as scoped variable assignments,
99 i.e.:
103 Config files can be represented as scoped variable assignments, i.e.:
100104
101 smtpd."mx.example.net".name = mx.example.net
102 smtpd."mx.example.net".listen-port = 25
103 smtpd."mx.example.net".routing-table = extern
104 route."".postmaster = joe
105 route."".postmaster@acme.example.net = postmaster
106 route."".postmaster@acme.example.org = postmaster
107 route."".file = "/etc/postmaster.rt"
108 route."extern".@example.com = @example.org
109 route."extern".@example.org = mx.example.net
105 : smtpd."mx.example.net".name = mx.example.net
106 : smtpd."mx.example.net".listen-port = 25
107 : smtpd."mx.example.net".routing-table = extern
108 : route."".postmaster = joe
109 : route."".postmaster@acme.example.net = postmaster
110 : route."".postmaster@acme.example.org = postmaster
111 : route."".file = "/etc/postmaster.rt"
112 : route."extern".@example.com = @example.org
113 : route."extern".@example.org = mx.example.net
110114
111 This fact allows for a simple mapping to command line flags. A
112 section, say [smtpd "foo"], can be declared by specifying
113 --smtpd="foo". Afterwards, parameterized flags like
114 --smtpd-"foo"-listen-port become available.
115 This fact allows for a simple mapping to command line flags. A section, say
116 [smtpd "foo"], can be declared by specifying --smtpd="foo". Afterwards,
117 parameterized flags like --smtpd-"foo"-listen-port become available.
115118
116 Arguably, the [route] section's representation is quite odd.
119 Arguably, the [route] section's representation is quite odd.
117120
118Routing:
119========
121*** Routing
120122
121 The routing table maps RCPT TO addresses to local targets. The
122 simplest form of local targets are system user names --
123 addresses without an @ --, which go to the default local
124 mailer. In theory, all the configuration postmaster needs is
125 something like this:
123 The routing table maps RCPT TO addresses to local targets. The simplest
124 form of local targets are system user names -- addresses without an @ --,
125 which go to the default local mailer. In theory, all the configuration
126 postmaster needs is something like this:
126127
127 joe@example.org joe
128 joe.doe@example.org joe
129 jane@example.org jane
130 jane.dow@example.org jane
128 : joe@example.org joe
129 : joe.doe@example.org joe
130 : jane@example.org jane
131 : jane.dow@example.org jane
131132
132 The postmaster.cf file begins with an implicit [route] just to
133 allow this kind of minimalist configuration.
133 The postmaster.cf file begins with an implicit [route] just to allow this
134 kind of minimalist configuration.
134135
135 Other local targets are defined via [relay] or [pipe].
136 Single-recipient pipes can be written as "|/path/bin ...".
136 Other local targets are defined via [relay] or [pipe]. Single-recipient
137 pipes can be written as "|/path/bin ...".
137138
138 *** TODO: Do we need a [reject] target?
139*** TODO Do we need a [reject] target?
139140
140 Some forms of relaying can be expressed by address rewriting:
141 Some forms of relaying can be expressed by address rewriting:
141142
142 foo@example.com foo@example.net
143 @example.org @example.net
143 : foo@example.com foo@example.net
144 : @example.org @example.net
144145
145 Routes are matched in the same order they are specified.
146 Similarly, the order in which an [smtpd] instance imports
147 routing tables is preserved. The global table, [route], is
148 implicitly imported last.
146 Routes are matched in the same order they are specified. Similarly, the
147 order in which an [smtpd] instance imports routing tables is preserved. The
148 global table, [route], is implicitly imported last.
149149
150 Local names -- names without an @ -- can be used on the left
151 hand-side, but an SMTP dialogue cannot generate them (except
152 'postmaster'). This fact allows for convenience aliases:
150 Local names -- names without an @ -- can be used on the left hand-side, but
151 an SMTP dialogue cannot generate them (except 'postmaster'). This fact
152 allows for convenience aliases:
153153
154 postmaster joe # can receive mail directly
155 hostmaster joe # cannot
154 : postmaster joe # can receive mail directly
155 : hostmaster joe # cannot
156156
157 The right hand-side may contain lists of targets:
157 The right hand-side may contain lists of targets:
158158
159 acme@list.example.org joe, jane, acme-archive@, @mirror.example.net
159 : acme@list.example.org joe, jane, acme-archive@, @mirror.example.net
160160
161 These kind of expansions always involve the mail spool; the
162 transaction fails only if all targets fail. Individual failures
163 generate bounces to <postmaster>, the sender, or both,
164 depending on some yet-to-be-determined configuration.
161 These kind of expansions always involve the mail spool; the transaction
162 fails only if all targets fail. Individual failures generate bounces to
163 <postmaster>, the sender, or both, depending on some yet-to-be-determined
164 configuration.
165165
166 Multi-recipient transactions are treated the same way in ESMTP.
167 In LMTP, every RCPT TO receives its own response code, so
168 individual recipients can fail, but multi-target expansions of
169 a single RCPT TO still require a mail spool.
166 Multi-recipient transactions are treated the same way in ESMTP. In LMTP,
167 every RCPT TO receives its own response code, so individual recipients can
168 fail, but multi-target expansions of a single RCPT TO still require a mail
169 spool.
170170
171Full Pipelining:
172================
171* RFC
173172
174 Upon receiving MAIL FROM and RCPT TO, Postmaster determines the
175 responsible target for this (part of the) transaction. If that
176 target is an ESMTP relay or an LMTP local mailer, Postmaster
177 opens a connection, says HELO, MAIL FROM and RCPT TO, and from
178 then on just acts as a proxy between the client and the target.
173*** Conformance
179174
180 Full pipelining always involves the mail spool, because
181 Postmaster may have to take that session over if the outgoing
182 connection fails for non-protocol reasons, i.e. network
183 failure.
175***** 1428: Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
184176
185Anti-Spam Mechanisms:
186=====================
177 Mail servers are supposed to upgrade 8-bit messages without MIME
178 information to an "unknown-8bit"-encoded MIME message.
187179
188 * SPF support via <http://www.libspf2.org/>.
180***** 1652: SMTP Service Extension for 8bit-MIMEtransport
189181
190RFC Conformance:
191================
182 The ESMTP 8BITMIME extension adds the parameter "BODY={7BIT,8BITMIME}" to
183 the MAIL FROM command. Conforming implementaions must (a) handle 8-bit
184 MIME payload and (b) downgrade the payload to base64 or quoted-printable
185 before relaying it to an MX without 8BITMIME support.
192186
193 1428: Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
187 Does this mean that a relay can upgrade payload to 8-bit too?
194188
195 Mail servers are supposed to upgrade 8-bit messages without
196 MIME information to an "unknown-8bit"-encoded MIME message.
189 Required for [[*3030%20SMTP%20Service%20Extensions%20for%20Transmission%20of%20Large%20and%20Binary%20MIME%20Messages][ESMTP CHUNKING]].
197190
198 1652: SMTP Service Extension for 8bit-MIMEtransport
191***** 1846: SMTP 521 Reply Code
199192
200 The ESMTP 8BITMIME extension adds the parameter
201 "BODY={7BIT,8BITMIME}" to the MAIL FROM command. Conforming
202 implementaions must (a) handle 8-bit MIME payload and (b)
203 downgrade the payload to base64 or quoted-printable before
204 relaying it to an MX without 8BITMIME support.
193 A mail relay may respond "521 <domain> does not accept mail" to a given
194 RCPT TO if the host in question does not accept mail. Hosts may also use
195 521 as the initial greeting to signify that they don't accept mail.
205196
206 Does this mean that a relay can upgrade payload to 8-bit too?
197***** 1870: SMTP Service Extension for Message Size Declaration
207198
208 Required for ESMTP CHUNKING.
199 The ESMTP SIZE extension add the parameter "SIZE=n" to MAIL FROM, which
200 allows the server to reject the message if it is too large. The declared
201 size isn't necessarily accurate, though; the RFC describes that number as
202 "the client's estimate". The actual size of the payload is known only
203 after <CRLF><DOT><CRLF>.
209204
210 1846: SMTP 521 Reply Code
205***** 1893: Enhanced Mail System Status Codes
211206
212 A mail relay may respond "521 <domain> does not accept mail" to
213 a given RCPT TO if the host in question does not accept mail.
214 Hosts may also use 521 as the initial greeting to signify that
215 they don't accept mail.
207 See [[*2034 SMTP Service Extension for Returning Enhanced Error Codes][EMTP ENHANCEDSTATUSCODES]].
216208
217 1870: SMTP Service Extension for Message Size Declaration
209***** 2033: Local Mail Transfer Protocol
218210
219 The ESMTP SIZE extension add the parameter "SIZE=n" to MAIL
220 FROM, which allows the server to reject the message if it is
221 too large. The declared size isn't necessarily accurate,
222 though; the RFC describes that number as "the client's
223 estimate". The actual size of the payload is known only after
224 <CRLF><DOT><CRLF>.
211 LMTP is a variation of ESMTP that starts with LHLO instead EHLO. It's
212 almost identical to ESMTP, but the server response to DATA has one line
213 per successful RCPT TO -- every recipient gets a separate response code.
214 This addition allows the server to operate without a mail spool. LMTP
215 must not be accepted on port 25 and the server must support ESMTP
216 PIPELINING and ESMTP ENHANCEDSTATUSCODES.
225217
226 1893: Enhanced Mail System Status Codes
227 2034: SMTP Service Extension for Returning Enhanced Error Codes
218 Contrary to what the RFC says, Postmaster totally speaks LMTP on port 25
219 and advertises that with the ESMTP X-LMTP extension.
228220
229 The ESMTP ENHANCEDSTATUSCODES extension allows MTAs to add
230 lots of unnecessary baggage to the SMTP dialogue.
221***** 2034: SMTP Service Extension for Returning Enhanced Error Codes
231222
232 Required for LMTP.
223 The ESMTP ENHANCEDSTATUSCODES extension allows MTAs to add lots of
224 unnecessary baggage to the SMTP dialogue.
233225
234 2033: Local Mail Transfer Protocol
226 Required for [[*2033 Local Mail Transfer Protocol][LMTP]].
235227
236 LMTP is a variation of ESMTP that starts with LHLO instead
237 EHLO. It's almost identical to ESMTP, but the server response
238 to DATA has one line per successful RCPT TO -- every
239 recipient gets a separate response code. This addition allows
240 the server to operate without a mail spool. LMTP must not be
241 accepted on port 25 and the server must support ESMTP
242 PIPELINING and ESMTP ENHANCEDSTATUSCODES.
228***** 2505: Anti-Spam Recommendations for SMTP MTAs
243229
244 Contrary to what the RFC says, Postmaster totally speaks LMTP
245 on port 25 and advertises that with the ESMTP X-LMTP
246 extension.
230 MTAs are supposed to verify MAIL FROM addresses using DNS and other means
231 (sections 2.9 and 2.10).
247232
248 2505: Anti-Spam Recommendations for SMTP MTAs
233***** 2554: SMTP Service Extension for Authentication
249234
250 MTAs are supposed to verify MAIL FROM addresses using DNS and
251 other means (sections 2.9 and 2.10).
235 The ESMTP AUTH extension specifies a challenge/response dialogue that's
236 supposed to authenticate the client to the server.
252237
253 2554: SMTP Service Extension for Authentication
238***** 2821: Simple Mail Transfer Protocol
254239
255 The ESMTP AUTH extension specifies a challenge/response
256 dialogue that's supposed to authenticate the client to the
257 server.
240 Fully supported. The optional commands HELP, TURN, SEND, SOML, SAML,
241 EXPN. and VRFY are not implemented.
258242
259 2821: Simple Mail Transfer Protocol
243***** 2920: SMTP Service Extension for Command Pipelining
260244
261 Fully supported. The optional commands HELP, TURN, SEND,
262 SOML, SAML, EXPN. and VRFY are not implemented.
245 The ESMTP PIPELINING extension allows MTAs to advertise that sending more
246 than one command at a time will not break their buffering.
263247
264 2920: SMTP Service Extension for Command Pipelining
248***** 3030: SMTP Service Extensions for Transmission of Large and Binary MIME Messages
265249
266 The ESMTP PIPELINING extension allows MTAs to advertise that
267 sending more than one command at a time will not break their
268 buffering.
250 The ESMTP CHUNKING extension allows 8-bit MIME payload payload without
251 transfer encoding. It adds BDAT as an alternative to DATA. The BDAT
252 command has one parameter: the size of the payload chunk that follows it.
253 Additionally, the parameter LAST signifies that this chunk concludes the
254 transaction. The last chunk may have size 0. Multiple BDAT chunks may be
255 pipelined, because server must confirm intermediate chunks with 250,
256 nothing else.
269257
270 3030: SMTP Service Extensions for Transmission of Large and
271 Binary MIME Messages
258 ESMTP BINARYMIME combines the CHUNKING and 8BITMIME extensions by adding
259 BODY=BINARYMIME to MAIL FROM. When specified, the transaction must occur
260 with BDATA, not DATA.
272261
273 The ESMTP CHUNKING extension allows 8-bit MIME payload
274 payload without transfer encoding. It adds BDAT as an
275 alternative to DATA. The BDAT command has one parameter: the
276 size of the payload chunk that follows it. Additionally, the
277 parameter LAST signifies that this chunk concludes the
278 transaction. The last chunk may have size 0. Multiple BDAT
279 chunks may be pipelined, because server must confirm
280 intermediate chunks with 250, nothing else.
262***** 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security
281263
282 ESMTP BINARYMIME combines the CHUNKING and 8BITMIME extensions
283 by adding BODY=BINARYMIME to MAIL FROM. When specified, the
284 transaction must occur with BDATA, not DATA.
264 The ESMTP STARTTLS extension defines the STARTTLS command, which triggers
265 a TLS handshake. The SMTP session starts over with EHLO afterwards.
285266
286 3207: SMTP Service Extension for Secure SMTP over Transport
287 Layer Security
288267
289 The ESMTP STARTTLS extension defines the STARTTLS command,
290 which triggers a TLS handshake. The SMTP session starts over
291 with EHLO afterwards.
268*** Ignorance
292269
293RFC Ignorance:
294==============
270***** 1845: SMTP Service Extension for Checkpoint/Restart
295271
296 1845: SMTP Service Extension for Checkpoint/Restart
272 The ESMTP CHECKPOINT extension allows the client to specify a transaction
273 identifier at MAIL FROM. If the connection aborts before DATA is
274 finished, an attempt to deliver a message with that very same id will
275 cause the server to respond with the number of bytes he has received (and
276 stored) earlier. Thus, the client doesn't have to re-transmit them.
297277
298 The ESMTP CHECKPOINT extension allows the client to specify a
299 transaction identifier at MAIL FROM. If the connection aborts
300 before DATA is finished, an attempt to deliver a message with
301 that very same id will cause the server to respond with the
302 number of bytes he has received (and stored) earlier. Thus, the
303 client doesn't have to re-transmit them.
278***** 1985: SMTP Service Extension for Remote Message Queue Starting
304279
305 1985: SMTP Service Extension for Remote Message Queue Starting
280 Defines the ETRN command to trigger queue processing on the remote
281 server.
306282
307 Defines the ETRN command to trigger queue processing on the
308 remote server.
283***** 2442: The Batch SMTP Media Type
309284
310 2442: The Batch SMTP Media Type
285 Defines a MIME type for representing batched SMTP transactions in e-mail.
311286
312 Defines a MIME type for representing batched SMTP
313 transactions in e-mail.
287***** 2645: On-Demand Mail Relay (ODMR) SMTP with Dynamic IP Addresses
314288
315 2645: On-Demand Mail Relay (ODMR) SMTP with Dynamic IP Addresses
289 Defines the ATRN command, which does the same thing as TURN only it
290 requires AUTH authentication to be performed before it can be issued.
316291
317 Defines the ATRN command, which does the same thing as TURN
318 only it requires AUTH authentication to be performed before it
319 can be issued.
292***** 2852: Deliver By SMTP Service Extension
320293
321 2852: Deliver By SMTP Service Extension
294 The ESMTP DELIVERBY extension allows clients to specify that the payload
295 should be delivered within a certain time period and what should be done
296 if that isn't possible.
322297
323 The ESMTP DELIVERBY extension allows clients to specify that
324 the payload should be delivered within a certain time period
325 and what should be done if that isn't possible.
298***** 3461: SMTP Service Extension for Delivery Status Notifications (DSNs)
326299
327 3461: SMTP Service Extension for Delivery Status Notifications (DSNs)
300 The ESMTP DSN extension provides means for the client to specify
301 reporting and tracing behavior for a message's relays and final server.
302 RCPT TO has an additional NOTIFY and ORCPT parameters, MAIL FROM gets
303 additional RET and ENVID parameters. There are lots of other insane
304 additions.
328305
329 The ESMTP DSN extension provides means for the client to
330 specify reporting and tracing behavior for a message's relays
331 and final server. RCPT TO has an additional NOTIFY and ORCPT
332 parameters, MAIL FROM gets additional RET and ENVID
333 parameters. There are lots of other insane additions.
306***** 3865: A No Soliciting SMTP Service Extension
334307
335 3865: A No Soliciting SMTP Service Extension
308 The ESMTP NO-SOLICITING extension allows payload to be classified before
309 transfer. The client adds "SOLICIT=type1:type2:...:typen" to MAIL FROM to
310 allow the server to reject the message based on that classification.
311 "spam" is an obvious category, but the RFC doesn't define anything,
312 instead the RFC2822 extension header "Solicitation:" can be used to
313 signal these categories during injection.
336314
337 The ESMTP NO-SOLICITING extension allows payload to be
338 classified before transfer. The client adds
339 "SOLICIT=type1:type2:...:typen" to MAIL FROM to allow the
340 server to reject the message based on that classification.
341 "spam" is an obvious category, but the RFC doesn't define
342 anything, instead the RFC2822 extension header
343 "Solicitation:" can be used to signal these categories during
344 injection.
315***** 3885: SMTP Service Extension for Message Tracking
345316
346 3885: SMTP Service Extension for Message Tracking
317 The ESMTP MTRK extension adds support for message tracking (apparently
318 using hash MAC algorithms). It requires that most of ESMTP DSN and
319 DELIVERBY is implemented, so it's probably not useful.
347320
348 The ESMTP MTRK extension adds support for message tracking
349 (apparently using hash MAC algorithms). It requires that most
350 of ESMTP DSN and DELIVERBY is implemented, so it's probably
351 not useful.
321***** 4141: SMTP and MIME Extensions for Content Conversion
352322
353 4141: SMTP and MIME Extensions for Content Conversion
323 E-mail relays can use the ESMTP CONNEG extension to ask the recipient MX
324 whether it's okay to re-encode the payload before relaying. A mail server
325 could, for instance, re-encode an attached WAV audio file to MP3 before
326 delivering the e-mail. If the recipient MX is okay with that, that is.
327 This extension is supposed to conserve bandwidth.
354328
355 E-mail relays can use the ESMTP CONNEG extension to ask the
356 recipient MX whether it's okay to re-encode the payload
357 before relaying. A mail server could, for instance, re-encode
358 an attached WAV audio file to MP3 before delivering the
359 e-mail. If the recipient MX is okay with that, that is. This
360 extension is supposed to conserve bandwidth.
329***** 4405: SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message
361330
362 4405: SMTP Service Extension for Indicating the Responsible
363 Submitter of an E-Mail Message
364
365 The SMTP SUBMITTER extensions lifts the "purported
366 responsible address" from the RFC2822 payload into the SMTP
367 dialogue. Thus, a mail server can reject the transaction
368 based on this information prior to accepting DATA.
331 The SMTP SUBMITTER extensions lifts the "purported responsible address"
332 from the RFC2822 payload into the SMTP dialogue. Thus, a mail server can
333 reject the transaction based on this information prior to accepting DATA.