7Network Working Group A. Stone, Ed.
8Request for Comments: 5429 Serendipity
9Obsoletes: 3028 March 2009
11Category: Standards Track
14 Sieve Email Filtering: Reject and Extended Reject Extensions
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (c) 2009 IETF Trust and the persons identified as the
27 document authors. All rights reserved.
29 This document is subject to BCP 78 and the IETF Trust's Legal
30 Provisions Relating to IETF Documents in effect on the date of
31 publication of this document (http://trustee.ietf.org/license-info).
32 Please review these documents carefully, as they describe your rights
33 and restrictions with respect to this document.
35 This document may contain material from IETF Documents or IETF
36 Contributions published or made publicly available before November
37 10, 2008. The person(s) controlling the copyright in some of this
38 material may not have granted the IETF Trust the right to allow
39 modifications of such material outside the IETF Standards Process.
40 Without obtaining an adequate license from the person(s) controlling
41 the copyright in such materials, this document may not be modified
42 outside the IETF Standards Process, and derivative works of it may
43 not be created outside the IETF Standards Process, except to format
44 it for publication as an RFC or to translate it into languages other
49 This memo updates the definition of the Sieve mail filtering language
50 "reject" extension, originally defined in RFC 3028.
52 A "Joe-job" is a spam run forged to appear as though it came from an
53 innocent party, who is then generally flooded by automated bounces,
54 Message Disposition Notifications (MDNs), and personal messages with
58Stone Standards Track [Page 1]
60RFC 5429 Sieve Extension: Reject March 2009
63 complaints. The original Sieve "reject" action defined in RFC 3028
64 required use of MDNs for rejecting messages, thus contributing to the
65 flood of Joe-job spam to victims of Joe-jobs.
67 This memo updates the definition of the "reject" action to allow
68 messages to be refused during the SMTP transaction, and defines the
69 "ereject" action to require messages to be refused during the SMTP
70 transaction, if possible.
72 The "ereject" action is intended to replace the "reject" action
73 wherever possible. The "ereject" action is similar to "reject", but
74 will always favor protocol-level message rejection.
78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
79 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
80 2. Sieve "reject" and "ereject" Extensions . . . . . . . . . . . 4
81 2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 4
82 2.1.1. Rejecting a Message at the SMTP/LMTP Protocol Level . 5
83 2.1.2. Rejecting a Message by Sending a DSN . . . . . . . . . 5
84 2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6
85 2.2.1. Rejecting a Message by Sending an MDN . . . . . . . . 7
86 2.3. Silent Upgrade from "reject" to "ereject" . . . . . . . . 8
87 2.4. Compatibility with Other Actions . . . . . . . . . . . . . 9
88 2.5. Details of Protocol-Level Refusal . . . . . . . . . . . . 9
89 3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11
90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
92 5.1. "reject" Extension Registration . . . . . . . . . . . . . 11
93 5.2. "ereject" Extension Registration . . . . . . . . . . . . . 12
94 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
95 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
96 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
97 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
98 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 14
114Stone Standards Track [Page 2]
116RFC 5429 Sieve Extension: Reject March 2009
121 The Sieve mail filtering language, as originally defined in RFC 3028
122 [RFC3028], specified that the "reject" action shall discard a message
123 and send a Message Disposition Notification [MDN] to the envelope
124 sender along with an explanatory message. The Sieve mail filtering
125 language, as updated in RFC 5228 [SIEVE], does not define any
126 "reject" action, hence that is the purpose of this document.
128 This document updates the definition of the "reject" action to permit
129 refusal of the message during the SMTP transaction, if possible, and
130 defines a new "ereject" action to require refusal of the message
131 during the SMTP transaction, if possible.
133 An important goal of this document is to reduce the risk of Sieve
134 scripts being used to perpetrate "Joe-job" spam runs, where the MDN
135 is sent notifying the sender of a message of its non-delivery is in
136 fact sent to an innocent third-party. The original Sieve "reject"
137 action defined in RFC 3028 required use of MDNs for rejecting
138 messages, thus contributing to the flood of Joe-job spam to victims
139 of Joe-jobs. By rejecting the message at the protocol level, it is
140 less likely that an MDN will be needed, and thus less likely that an
141 MDN will be misdirected at an innocent third-party.
143 Implementations are further encouraged to use spam-detection systems
144 to determine the level of risk associated with sending an MDN, and
145 this document allows implementations to silently drop the MDN if the
146 rejected message is deemed likely to be spam.
148 This document also describes how to use "reject"/"ereject" at varying
149 points in the email stack: Mail Transfer Agent (MTA), Mail Delivery
150 Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a
151 comprehensive discussion of these environments.
153 In general, an MDN is generated by an MUA, and can be used to
154 indicate the status of a message with respect to its recipient, while
155 a Delivery Status Notification (DSN) [DSN] is generated by an MTA,
156 and can be used to indicate whether or not a message was received and
157 delivered by the mail system.
159 Further discussion highlighting the risks of generating MDNs and the
160 benefits of protocol-level refusal can be found in [Joe-DoS].
1621.1. Conventions Used in This Document
164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
166 document are to be interpreted as described in [KEYWORDS].
170Stone Standards Track [Page 3]
172RFC 5429 Sieve Extension: Reject March 2009
175 Conventions for notations are as in Section 1.1 of RFC 5228 [SIEVE].
177 This document does not attempt to define spam or how it should be
178 identified, nor does it attempt to define an email virus or how it
179 should be detected. Implementors are advised to follow best
180 practices and keep abreast of current research in these fields.
1822. Sieve "reject" and "ereject" Extensions
186 Usage: ereject <reason: string>
188 Sieve implementations that implement the "ereject" action must use
189 the "ereject" capability string.
191 The "ereject" action cancels the implicit keep and refuses delivery
192 of a message. The "reason" string is a UTF-8 [UTF-8] string
193 specifying the reason for refusal. How a message is refused depends
194 on the capabilities of the mail component (MDA or MTA) executing the
195 Sieve script. The Sieve interpreter MUST carry out one of the
196 following actions (listed in order from most to least preferred),
197 MUST carry out the most preferable action possible, and MUST fall
198 back to lesser actions if a preferred action fails.
200 1. Refuse message delivery by sending a 5XX response code over SMTP
201 [SMTP] or Local Mail Transfer Protocol (LMTP) [LMTP]. See
202 Section 2.1.1 for more details.
204 2. Send a non-delivery report to the envelope sender ([REPORT]
205 [DSN]), unless the envelope sender address is determined to be a
206 forged or otherwise invalid address.
208 Note that the determination of whether or not an envelope sender is a
209 forgery may be performed by site-specific and implementation-specific
210 heuristic techniques, such as "return-path verification", details of
211 which are outside the scope of this document. Implementations SHOULD
212 log instances when a non-delivery report is not sent and the reason
213 for not sending the report (e.g., content was spam, return-path
216 The "ereject" action MUST NOT be available in environments that do
217 not support protocol-level rejection, e.g., an MUA, and MUST be
218 available in all other environments that support the "reject" action.
226Stone Standards Track [Page 4]
228RFC 5429 Sieve Extension: Reject March 2009
234 if address "from" "someone@example.com" {
235 ereject "I no longer accept mail from this address";
2382.1.1. Rejecting a Message at the SMTP/LMTP Protocol Level
240 Sieve implementations that are able to reject messages at the SMTP/
241 LMTP level MUST do so and SHOULD use the 550 response code. Note
242 that if a message is arriving over SMTP and has multiple recipients,
243 some of whom have accepted the message, Section 2.1.2 defines how to
244 reject such a message.
246 The risk that these actions will generate blowback spam are minimized
247 but cannot be eliminated completely even in the case of "ereject", so
248 caution is advised when using these actions to deal with messages
249 determined to be spam.
251 Note that SMTP [SMTP] does not allow non-US-ACSII characters in the
252 SMTP response text. If non-US-ACSII characters appear in the
253 "reason" string, they can be sent at the protocol level if and only
254 if the client and the server use an SMTP extension that allows for
255 transmission of non-US-ACSII reply text. (One example of such an
256 SMTP extension is described in [UTF8-RESP].) In the absence of such
257 an SMTP extension, the Sieve engine MUST replace any "reason" string
258 being sent at the protocol level and containing non-US-ACSII
259 characters with an implementation-defined US-ACSII-only string.
261 Users who don't like this behavior should consider using the "reject"
262 action described in Section 2.2, if available.
264 See Section 2.5 for the detailed instructions about performing
265 protocol-level rejection.
2672.1.2. Rejecting a Message by Sending a DSN
269 An implementation may receive a message via SMTP that has more than
270 one RCPT TO that has been accepted by the server, and at least one
271 but not all of them are refusing delivery (whether the refusal is
272 caused by a Sieve "ereject" action or for some other reason). In
273 this case, the server MUST accept the message and generate DSNs for
274 all recipients that are refusing it. Note that this exception does
275 not apply to LMTP, as LMTP is able to reject messages on a per-
276 recipient basis. (However, the LMTP client may then have no choice
277 but to generate a DSN to report the error, which may result in
282Stone Standards Track [Page 5]
284RFC 5429 Sieve Extension: Reject March 2009
287 Note that according to [DSN], Delivery Status Notifications MUST NOT
288 be generated if the MAIL FROM (or Return-Path) is empty.
290 The DSN message MUST follow the requirements of [DSN] and [REPORT].
291 The action-value field defined in [DSN], Section 2.3.3, MUST contain
292 the value "failed". The human-readable portion of the non-delivery
293 report MUST contain the "reason" string from the "ereject" action and
294 SHOULD contain additional text alerting the apparent original sender
295 that the message was refused by an email filter. This part of the
296 report might appear as follows:
298 ------------------------------------------------------------
299 Your message was refused by the recipient's mail filtering program.
300 The reason given is as follows:
302 I am not taking mail from you, and I don't want your birdseed,
304 ------------------------------------------------------------
308 This section updates the definition of the "reject" action in Section
309 4.1 of RFC 3028 [RFC3028] and is an optional extension to [SIEVE].
311 Usage: reject <reason: string>
313 Sieve implementations that implement the "reject" action must use the
314 "reject" capability string.
316 The "reject" action cancels the implicit keep and refuses delivery of
317 a message. The "reason" string is a UTF-8 [UTF-8] string specifying
318 the reason for refusal. Unlike the "ereject" action described above,
319 this action would always favor preserving the exact text of the
320 refusal reason. Typically, the "reject" action refuses delivery of a
321 message by sending back an MDN to the sender (see Section 2.2.1).
322 However, implementations MAY refuse delivery over SMTP/LMTP protocol
323 (as detailed in Section 2.5), if and only if all of the following
326 1. The "reason" string consists of only US-ASCII characters
328 The "reason" string contains non-US-ASCII and both the client and
329 server support and negotiate use of an SMTP/LMTP extension for
330 sending UTF-8 responses.
338Stone Standards Track [Page 6]
340RFC 5429 Sieve Extension: Reject March 2009
343 2. LMTP protocol is used
345 SMTP protocol is used and the message has a single recipient
347 SMTP protocol is used, the message has multiple recipients, and
348 all of them refused message delivery (whether or not Sieve is
357 Your message is too big. If you want to send me a big attachment,
358 put it on a public web site and send me a URL.
363 (Pretend that the "reason" string above contains some non-US-ACSII
366 Implementations may use techniques as described in Section 2.1 to
367 determine if a non-delivery report should not be sent to a forged
368 sender. Implementations SHOULD log instances when a non-delivery
369 report is not sent and the reason for not sending the report.
3712.2.1. Rejecting a Message by Sending an MDN
373 The "reject" action resends the received message to the envelope
374 sender specified by the MAIL FROM (or Return-Path) address, wrapping
375 it in a "reject" form, explaining that it was rejected by the
378 Note that according to [MDN], Message Disposition Notifications MUST
379 NOT be generated if the MAIL FROM (or Return-Path) is empty.
381 A reject message MUST take the form of a failure MDN as specified by
382 [MDN]. The human-readable portion of the message, the first
383 component of the MDN, contains the human-readable message describing
384 the error, and it SHOULD contain additional text alerting the
385 apparent original sender that mail was refused by an email filter.
387 The MDN disposition-field as defined in the MDN specification MUST be
388 "deleted" and MUST have the "MDN-sent-automatically" and "automatic-
389 action" modes set (see Section 3.2.6 of [MDN]).
394Stone Standards Track [Page 7]
396RFC 5429 Sieve Extension: Reject March 2009
399 In the following script, a message is rejected and returned to the
405 if header :contains "from" "coyote@desert.example.org" {
407 I am not taking mail from you, and I don't
408 want your birdseed, either!
413 For this script, the first part of the MDN might appear as follows:
415 ------------------------------------------------------------
416 The message was refused by the recipient's mail filtering program.
417 The reason given was as follows:
419 I am not taking mail from you, and I don't want your birdseed,
421 ------------------------------------------------------------
4232.3. Silent Upgrade from "reject" to "ereject"
425 Implementations MUST NOT silently upgrade "reject" actions to
426 "ereject" actions in a Sieve script because this might lead to
427 unpleasant changes of behavior not expected by the script owner.
429 User interfaces that present a generic rejection option, and generate
430 Sieve script output, MAY switch from generating "reject" to "ereject"
431 actions, so long as doing so does not create a confusing change for
434 Script generators SHOULD ensure that a rejection action being
435 executed as a result of an anti-spam/anti-virus positive test be done
436 using the "ereject" action, as it is more suitable for such
439 Script generators MAY automatically upgrade scripts that previously
440 used the "reject" action for anti-spam/anti-virus related rejections.
441 Note that such generators MUST make sure that the target environment
442 can support the "ereject" action.
450Stone Standards Track [Page 8]
452RFC 5429 Sieve Extension: Reject March 2009
4552.4. Compatibility with Other Actions
457 This section applies equally to "reject" and "ereject" actions. All
458 references to the "reject" action in this section can be replaced
459 with the "ereject" action.
461 A "reject" action cancels the implicit keep.
463 Implementations MUST prohibit the execution of more than one "reject"
466 "reject" MUST be incompatible with the "vacation" [VACATION] action.
467 It is NOT RECOMMENDED that implementations permit the use of "reject"
468 with actions that cause mail delivery, such as "keep", "fileinto",
471 Making "reject" compatible with actions that cause mail delivery
472 violates the RFC 5321 [SMTP] principle that a message is either
473 delivered or bounced back to the sender. So bouncing a message back
474 (rejecting) and delivering it will make the sender believe that the
475 message was not delivered.
477 However, there are existing laws requiring certain organizations to
478 archive all received messages, even the rejected ones. Also, it can
479 be quite useful to save copies of rejected messages for later
482 Any action that would modify the message body will not have an effect
483 on the body of any message refused by "reject" using an SMTP response
484 code and MUST NOT have any effect on the content of generated DSN/
4872.5. Details of Protocol-Level Refusal
489 If the "reason" string consists of multiple CRLF separated lines,
490 then the reason text MUST be returned as a multiline SMTP/LMTP
491 response, per Section 4.2.1 of [SMTP]. Any line MUST NOT exceed the
492 SMTP limit on the maximal line length. To make the "reason" string
493 conform to any such limits, the server MAY insert CRLFs and turn the
494 response into a multiline response.
496 In the following script (which assumes support for the "spamtest"
497 [SPAMTEST] and "fileinto" extensions), messages that test highly
498 positive for spam are refused.
506Stone Standards Track [Page 9]
508RFC 5429 Sieve Extension: Reject March 2009
512 require ["ereject", "spamtest", "fileinto",
513 "comparator-i;ascii-numeric"];
515 if spamtest :value "ge"
516 :comparator "i;ascii-numeric" "6" {
518 AntiSpam engine thinks your message is spam.
519 It is therefore being refused.
520 Please call 1-900-PAY-US if you want to reach us.
523 } elsif spamtest :value "ge"
524 :comparator "i;ascii-numeric" "4" {
528 The following excerpt from an SMTP session shows it in action.
532 S: 354 Send message, ending in CRLF.CRLF.
535 S: 550-AntiSpam engine thinks your message is spam.
536 S: 550-It is therefore being refused.
537 S: 550 Please call 1-900-PAY-US if you want to reach us.
539 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES], it MUST
540 prepend an appropriate Enhanced Error Code to the "reason" text.
541 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED.
542 With an Enhanced Error Code, the response to a DATA command in the
543 SMTP example below will look like:
545 S: 550-5.7.1 AntiSpam engine thinks your message is spam.
546 S: 550-5.7.1 It is therefore being refused.
547 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us.
549 if the server selected "5.7.1" as appropriate.
551 If a Sieve implementation that supports "ereject" does not wish to
552 immediately disclose the reason for rejection (for example, that it
553 detected spam), it may delay immediately sending of the 550 error
554 code by sending a 4XX error code on the first attempt to receive the
562Stone Standards Track [Page 10]
564RFC 5429 Sieve Extension: Reject March 2009
5673. Changes from RFC 3028
569 Clarified that the "reject" action cancels the implicit keep.
570 Extended the list of allowable actions on "reject" to include
571 protocol-level message rejection.
573 Added the "ereject" action that is similar to "reject", but will
574 always favor protocol-level message rejection.
5764. Security Considerations
578 The introduction to this document discusses why rejecting messages
579 before delivery is better than accepting and bouncing them.
581 While the details of techniques that can be used to determine when to
582 silently drop a non-delivery report are outside the scope of this
583 document, the explicit permission this document gives to take such
584 action may enable denial-of-service situations. Techniques such as
585 spam-checking, return-path verification, and others, can and do have
586 false-positives. Care should be exercised to prevent the loss of
587 legitimate messages by failing to notify the sender of non-delivery.
589 Security issues associated with email auto-responders are fully
590 discussed in the Security Considerations section of [RFC3834]. This
591 document is not believed to introduce any additional security
592 considerations in this general area.
594 The "ereject" extension does not raise any other security
595 considerations that are not already present in the base [SIEVE]
596 specification, and these issues are discussed in [SIEVE].
5985. IANA Considerations
600 The following section provides the IANA registrations for the Sieve
601 extensions specified in this document.
6035.1. "reject" Extension Registration
605 IANA is requested to update the registration for the Sieve "reject"
606 extension as detailed below:
608 Capability name: reject
609 Description: adds the "reject" action for refusing delivery
610 of a message. The exact reason for refusal is
611 conveyed back to the client.
613 Contact address: the Sieve discussion list <ietf-mta-filters@imc.org>
618Stone Standards Track [Page 11]
620RFC 5429 Sieve Extension: Reject March 2009
6235.2. "ereject" Extension Registration
625 IANA is requested to replace the preliminary registration of the
626 Sieve refuse extension with the following registration:
628 Capability name: ereject
629 Description: adds the "ereject" action for refusing delivery
630 of a message. The refusal should happen as early
631 as possible (e.g., at the protocol level) and might
632 not preserve the exact reason for refusal if it
633 contains non-US-ASCII text.
635 Contact address: the Sieve discussion list <ietf-mta-filters@imc.org>
6396.1. Normative References
641 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message
642 Format for Delivery Status Notifications",
643 RFC 3464, January 2003.
645 [ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning
646 Enhanced Error Codes", RFC 2034, October 1996.
648 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
649 Requirement Levels", BCP 14, RFC 2119, March 1997.
651 [LMTP] Myers, J., "Local Mail Transfer Protocol",
652 RFC 2033, October 1996.
654 [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition
655 Notification", RFC 3798, May 2004.
657 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type
658 for the Reporting of Mail System Administrative
659 Messages", RFC 3462, January 2003.
661 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email
662 Filtering Language", RFC 5228, January 2008.
664 [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
665 RFC 5321, October 2008.
667 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
668 10646", STD 63, RFC 3629, November 2003.
674Stone Standards Track [Page 12]
676RFC 5429 Sieve Extension: Reject March 2009
679 [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering:
680 Vacation Extension", RFC 5230, January 2008.
6826.2. Informative References
684 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work
685 in Progress, October 2008.
687 [Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-
688 Delivery Notice Attacks", April 2004, <http://
689 www.techzoom.net/papers/
690 mail_non_delivery_notice_attacks_2004.pdf>.
692 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language",
693 RFC 3028, January 2001.
695 [RFC3834] Moore, K., "Recommendations for Automatic Responses
696 to Electronic Mail", RFC 3834, August 2004.
698 [SPAMTEST] Daboo, C., "Sieve Email Filtering: Spamtest and
699 Virustest Extensions", RFC 5235, January 2008.
701 [UTF8-RESP] Melnikov, A., "SMTP Language Extension", Work
702 in Progress, June 2007.
730Stone Standards Track [Page 13]
732RFC 5429 Sieve Extension: Reject March 2009
735Appendix A. Acknowledgements
737 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner,
738 Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens
739 for comments and corrections.
741 The authors gratefully acknowledge the extensive work of Tim
742 Showalter as the author of the RFC 3028, which originally defined the
745Appendix B. Contributors
748 The Elvey Partnership, LLC
749 1819 Polk Street, Suite 133
750 San Francisco, CA 94109
753 EMail: matthew@elvey.com
758 5 Castle Business Village
760 Hampton, Middlesex TW12 2BX
763 EMail: Alexey.Melnikov@isode.com
773 EMail: aaron@serendipity.palo-alto.ca.us
786Stone Standards Track [Page 14]