Courier: .../draft-varshavchik-exdata-smtpext.txt

"Fossies" - the Fresh Open Source Software Archive

Member "courier-1.2.2/courier/doc/draft-varshavchik-exdata-smtpext.txt" (25 Aug 2013, 15924 Bytes) of package /linux/misc/courier-1.2.2.tar.bz2:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

1 2 3 4 5 6 7 1. Abstract 8 9 This document describes an extension to the SMTP service [RFC1425], 10 called Extended DATA Reply. This is an extended format of the SMTP 11 response to the DATA verb which provides recipient-specific status 12 information. This allows mail recipients to use individual mail 13 filters as part of the Simple Mail Transfer Protocol. This is a very 14 desirable feature because of escalating amounts of unwanted junk E- 15 mail sent over the Internet. 16 17 2. Introduction 18 19 The reply to the SMTP [RFC821] DATA verb is a status code indicating 20 if the message was accepted or rejected. The status code also 21 indicates if the rejection is temporary or permanent. Additional 22 delivery attempts will be made for messages that are temporarily 23 rejected. 24 25 SMTP allows a message to have multiple recipients, but the reply to 26 the DATA verb cannot indicate if the message was successfully 27 accepted for some recipients only and rejected for the remaining 28 recipients (permanently or temporarily). It can only indicate if the 29 message was accepted or rejected for every one of the listed 30 recipients. 31 32 The only way to handle this condition within the current protocol is 33 to send a status code indicating that the message was accepted, then 34 immediately generate a non-delivery report for undeliverable 35 recipients. This imposes additional resources and overhead to 36 generate and transmit the non-delivery report. 37 38 The ability to have recipient-specific status in the reply to the 39 DATA verb is desirable for the following reasons: 40 41 A) The receiving SMTP server does not have to generate and send 42 a non-delivery report. 43 44 B) Recipients can install individual mail filters that 45 selectively block unwanted E-mail, and the mail filters will 46 be able to examine the entire contents of the message before 47 deciding to reject the message. Currently, recipient- 48 specific filtering is only possible in response to the "RCPT 49 TO:" verb. But the only available information at that point 50 is the network address of the sending SMTP agent and return 51 address of the message. Filtering unwanted junk mail based 52 only on the network address and the return address is of very 53 limited benefit. 54 55 56 57 58 Expires XXX XX, XXXX [Page 1] 59 60 EXDATA SMTP Extension S. Varshavchik XXX XX, XXXX 61 62 63 There are several other mail enhancements that involve recipient- 64 specific processing. [RFC2033] defines a related, but a completely 65 different, mail delivery protocol which features recipient-specific 66 processing. There was also another draft memo published, draft-ietf- 67 fax-smtp-session, which defined an extension for recipient-specific 68 mail processing, however its scope is different from the scope of 69 this memo. 70 71 3. Framework for the EXDATA SMTP transport extension 72 73 This SMTP transport extension [RFC1425] is laid out as follows. 74 75 (1) The name of the SMTP transport extension defined here is 76 Extended Data Reply (EXDATA). 77 78 (2) The EHLO keyword associated with this extension is EXDATA. 79 80 (3) The EXDATA EHLO keyword takes no parameters. 81 82 (4) One optional ESMTP keyword EXDATA is associated with the MAIL 83 FROM command. This parameter takes no values. 84 85 (5) No additional ESMTP verbs are defined by this extension. 86 87 (6) The next sections specify how support for this extension 88 affects the behavior of a server and client SMTP server. 89 90 4. The EXDATA SMTP extension 91 92 The receiving SMTP server indicates that it is capable of supporting 93 the Extended Data Reply SMTP extension by including the EXDATA 94 keyword in the EHLO list. 95 96 The sending SMTP agent indicates that it supports this extension by 97 including the EXDATA keyword in the MAIL FROM command. 98 99 If the sending SMTP agent includes the EXDATA keyword in the first 100 MAIL FROM command, it MUST include the keyword in every MAIL FROM 101 command used in the same SMTP session. If the sending SMTP agent 102 does not include the EXDATA keyword in the first MAIL FROM command, 103 it MUST NOT include the keyword in any MAIL FROM command used in the 104 same SMTP session. 105 106 The receiving SMTP server SHOULD NOT send extended replies to the 107 DATA verb if the EXDATA keyword is not included in the MAIL FROM 108 command. 109 110 An extended DATA verb reply MAY be sent instead of the second status 111 112 113 114 Expires XXX XX, XXXX [Page 2] 115 116 EXDATA SMTP Extension S. Varshavchik XXX XX, XXXX 117 118 119 code reply to the DATA verb. It MUST NOT be sent as the first reply 120 to the DATA verb (before the message is transmitted). Using the 121 extended format in the second reply to the DATA verb is optional, and 122 not required. The receiving SMTP server is always permitted to send 123 regular status replies. 124 125 5. Format of an extended SMTP DATA reply 126 127 The extended SMTP DATA reply uses the 558 numeric status code which 128 is explicitly reserved for this purpose. When a 558 numeric status 129 code is the second reply to the DATA verb, the reply MUST be 130 formatted as follows, where <SP>, <CR> and <LF> represent the ASCII 131 space, carriage return, and line feed characters: 132 133 ex-reply-code: ex-reply-recipient-list 134 135 ex-reply-recipient-list: non-final-recipient ex-reply-recipient-list 136 | final-recipient 137 138 non-final-recipient: non-term-line non-final-recipient 139 | non-final-recipient-term-line 140 141 non-term-line: "558-" result-code "-" result-text 142 143 non-final-recipient-term-line: "558-" result-code <SP> result-text 144 145 final-recipient: non-term-line final-recipient 146 | final-recipient-term-line 147 148 final-recipient-term-line: "558" <SP> result-code <SP> result-text 149 150 result-code: digit digit digit 151 152 result-text: 0 or more characters, except <CR> and <LF>, terminated 153 by the <CR> <LF> sequence 154 155 digit: Characters "0" through "9" 156 157 158 The extended DATA reply is formatted like a standard multiline SMTP 159 reply with a 558 numeric status code. The extended information is 160 contained within the text portion of the 558 multiline reply. The 161 extended information consists of one or more individual replies, 162 where each reply itself is formatted like an SMTP reply. There will 163 be exactly one reply for each recipient. Each individual reply may 164 be a multiline reply itself. 165 166 6. Restrictions on the extended SMTP DATA reply 167 168 169 170 Expires XXX XX, XXXX [Page 3] 171 172 EXDATA SMTP Extension S. Varshavchik XXX XX, XXXX 173 174 175 Extended replies MUST contain exactly one individual reply for each 176 recipient whose RCPT TO command was acknowledged with a 2xx result 177 code. Extended replies MUST NOT have any replies for recipients 178 whose RCPT TO commands were previously rejected with a 4xx or 5xx 179 result code. 180 181 For example, if a message had three recipients, and the second RCPT 182 TO command was rejected, the extended reply MUST contain two 183 individual replies: the first one is for the first recipient, the 184 second one for the last recipient. 185 186 Technically, an extended SMTP DATA reply with a 2xx numeric code in 187 every individual reply is technically equivalent to a regular 2xx 188 reply to the DATA transaction. The "be conservative with what you 189 send, and be liberal with what you receive" principle would dictate 190 that the sending SMTP agent MUST be prepared to properly handle 191 either reply, and the receiving SMTP agent SHOULD use a regular 2xx 192 response in this situation. 193 194 7. Examples 195 196 In this example the first recipient of a two-recipient message is 197 accepted. The second recipient is rejected: 198 199 558-250 Message accepted 200 558-550-Access denied: 201 558 550 Insufficient permission 202 203 In this example the first recipient is rejected. The second recipient 204 is accepted: 205 206 558-550-Access denied 207 558-550 Insufficient permission 208 558-250-Message accepted 209 558 250 Queue ID is 120 210 211 212 7.1 Parsing extended replies 213 214 Extended replies can be parsed rather easily by noting that extended 215 replies are wrapped inside a standard SMTP multiline reply with a 558 216 status code. If the numeric code of the second status reply to the 217 DATA verb is 558, and if the receiving server listed EXDATA in the 218 EHLO keyword list, the "558-" and "558<SP>" characters are removed 219 from the start of every line in the multiline response. The remaining 220 text is now interpreted as a series of individual SMTP replies, one 221 reply per recipient. Each individual reply may be a multiline reply 222 itself. 223 224 225 226 Expires XXX XX, XXXX [Page 4] 227 228 EXDATA SMTP Extension S. Varshavchik XXX XX, XXXX 229 230 231 7.2 Parsing incomplete replies 232 233 If the client receives an incomplete 558 reply, the client should 234 process normally any of this reply’s subreplies which were received 235 in their entirety, and should process any incomplete or unreceived 236 subreplies as if they had been 451 subreplies. 237 238 While receiving a 558 reply, the client must implement a timeout of 239 at least 10 minutes per subreply. It MUST use per- subreply timeouts 240 rather than trying to time the entire 558 reply. This means that the 241 overall timeout is approximately proportional to the number of 242 recipients. 243 244 Rationale: The 10 minute limit is chosen because that’s the suggested 245 minimum timeout for processing a message body, in the middle of 246 section 4.5.3.2 of RFC 2821. The second and third sentences above 247 are adapted from the first paragraph of that same section of the RFC. 248 249 While sending a 558 reply, the server should take no more than about 250 5 minutes to send each subreply. If individual users administer 251 their own filtering software, it would be advisable to use a timeout 252 mechanism to force a decision after 5 minutes. 253 254 Rationale: if a user’s filter always takes too long, and triggers the 255 client’s 10 minute timeout, other users might not ever be able to 256 receive the message. 257 258 8. Security Concerns 259 260 8.1 Transitional behavior 261 262 The stated benefit of this extension is to allow recipients to use 263 individual mail filters to reject mail during an SMTP transaction. 264 However this extension must be widely implemented for this to happen. 265 Furthermore, the sending SMTP agent can always omit the EXDATA 266 keyword from the MAIL FROM: verb. 267 268 It follows that recipient-specific mail filtering is still a very 269 desireable feature if the sending SMTP agent does not state its 270 support for the EXDATA extension. One approach is to reply to the 271 DATA verb with an accepted status, then apply individual filters and 272 generate a non-delivery report for recipients whose filters rejected 273 the message. But this would be exactly how individual mail filtering 274 is currently implemented, and it carries with it the same 275 disadvantages and setbacks. 276 277 Another possible approach is to go ahead and issue an extended reply, 278 which will be interpreted as a permanent failure by the sending SMTP 279 280 281 282 Expires XXX XX, XXXX [Page 5] 283 284 EXDATA SMTP Extension S. Varshavchik XXX XX, XXXX 285 286 287 agent. This approach is usually unacceptable because the sending 288 SMTP agent will correctly conclude that every recipient was 289 undeliverable. If a message comes from a mailing list, the mailing 290 list software can end up removing all recipients from the mailing 291 list only because of a malfunctioning mail filter used by one 292 recipient only. 293 294 Here’s an approach that attempts to achieve a compromise between 295 having recipient-specific mail filtering, and avoiding unwanted 296 disruptions of this kind. 297 298 A) Recipients must explicitly enable the ability to set 299 filtering rules for their mailboxes 300 301 B) Allow each recipient to specify "whitelisted" senders and/or 302 network addresses. The mail server will not do any filtering 303 on white-listed mail, and will never send EXDATA-formatted 304 replies to those sources. 305 306 C) When the first valid RCPT TO: verb is received (after zero or 307 more RCPT TO: verbs that were deemed to be unacceptable for 308 any other reason), determine if the first recipient has this 309 sender whitelisted. 310 311 D) If the message is whitelisted by the first accepted 312 recipient, any additional recipients MUST also have the 313 message similarly whitelisted. If not, reject the 314 corresponding RCPT TO: verb with a temporary 421 status code. 315 The sending SMTP agent is expected to retransmit the message 316 for all non whitelisted recipients after a small delay. 317 318 E) If the message is not whitelisted by the first recipient, any 319 additional recipients MUST NOT have this message whitelisted 320 If they do, reject the corresponding RCPT TO: verb with a 321 temporary 421 status code. The sending SMTP agent is 322 expected to retransmit the message for all whitelisted 323 recipients after a small delay. 324 325 E) This logic results in separate delivery attempts for 326 whitelisted and non whitelisted recipients (with a small 327 delay in between). Individual recipients can decide whether 328 to whitelist specific sources of mail (such as mailing 329 lists). By whitelisting known mail sources, the recipients 330 can make sure that anyone else’s mail filter will not affect 331 their mail delivery. 332 333 8.2 Response time to SMTP DATA 334 335 336 337 338 Expires XXX XX, XXXX [Page 6] 339 340 EXDATA SMTP Extension S. Varshavchik XXX XX, XXXX 341 342 343 Implementations should try to avoid any lengthy delays due to mail 344 filters being used, before returning a reply to the SMTP DATA. Many 345 SMTP clients wait for a response for only a short period of time, 346 before giving up. This can lead to a message duplication problem, 347 described in [RFC1047]. 348 349 9. Comments 350 351 An experimental patch was made available in September 1997 (with 352 various revisions that followed) to a relatively popular mail server. 353 The patch used an XEXDATA EHLO keyword. The experimental patch was 354 mainly used to implement recipient-specific mail filtering: 355 permitting individual recipients of a message to selectively reject 356 incoming E-mail traffic based on the contents of the message. The 357 patch implemented the XEXDATA extension only for the receiving side, 358 not for the sending side. 359 360 No issues have been reported concerning the theoretical design of the 361 extended result code. 362 363 10. References 364 365 [RFC1425] Klensin, J., Freed, N., Rose, M., Stefferud, E., 366 Crocker, D. "SMTP Service Extensions", RFC 1425, United 367 Nations University, Innosoft International, Inc., Dover Beach 368 Consulting, Inc., Network Management Associates, Inc., The 369 Branch Office, February 1993 370 371 [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 372 821, USC/Information Sciences Institute, August 1982. 373 374 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 375 Carnegie Mellon, October 1996. 376 377 [RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP", RFC 1047, 378 CIC at BBN Labs, February 1988. 379 380 11. Author’s address 381 382 Sam Varshavchik 383 Double Precision, Inc. 384 402 Main Street Suite 100-241 385 Metuchen, NJ 08840 386 <mrsam@courier-mta.com> 387 388 389 390 391 392 393 394 Expires XXX XX, XXXX [Page 7]