Sieve Email Filtering: Reject and Extended Reject Extensions
obsoletes
- rfc-3028 — Sieve: A Mail Filtering Language
updates
- rfc-5228 — Sieve: An Email Filtering Language
Extracted elements (27)
A Sieve implementation may delay sending the 550 error code by first sending a 4XX temporary error, allowing deferral of immediate disclosure of the rejection reason (e.g., to avoid revealing spam-detection details).
The 'ereject' and 'reject' actions intentionally differ in their handling of non-ASCII reason strings: 'ereject' will silently replace non-ASCII with ASCII at the protocol level to maximize protocol-level rejection, while 'reject' preserves exact reason text by falling back to an MDN. Users who want exact text preservation should use 'reject'.
The original RFC 3028 'reject' action required sending an MDN to the envelope sender, which contributed to 'Joe-job' blowback: forged spam caused floods of MDNs to innocent third-parties. RFC 5429 updates 'reject' to permit SMTP-level refusal and introduces 'ereject' to require it, reducing the risk of misdirected MDNs.
LMTP differs from SMTP in that it supports per-recipient rejection, so the multi-recipient exception requiring message acceptance and DSN generation (Section 2.1.2) does not apply to LMTP. However, LMTP clients may still be forced to generate blowback DSNs.
SMTP does not allow non-US-ASCII characters in response text. Non-ASCII 'reason' strings can only be sent at the protocol level if both client and server negotiate a UTF-8 SMTP extension (e.g., as described in [UTF8-RESP]); otherwise the reason must be replaced with ASCII.
A reject MDN MUST take the form of a failure MDN per [MDN]. MDNs MUST NOT be generated if MAIL FROM (or Return-Path) is empty. The MDN disposition-field MUST be 'deleted' with 'MDN-sent-automatically' and 'automatic-action' modes set.
Any action that modifies the message body MUST NOT have any effect on the content of generated DSN/MDNs when a message is refused via an SMTP response code.
DSNs MUST NOT be generated if the MAIL FROM (or Return-Path) is empty, per [DSN]. The DSN action-value field MUST contain 'failed', and the human-readable portion MUST contain the 'reason' string from the 'ereject' action.
If the 'reason' string contains multiple CRLF-separated lines, it MUST be returned as a multiline SMTP/LMTP response per Section 4.2.1 of [SMTP]. No line MUST exceed the SMTP maximum line length limit.
If the 'reason' string contains non-US-ASCII characters and no SMTP extension for UTF-8 reply text has been negotiated, the Sieve engine MUST replace the reason string with an implementation-defined US-ASCII-only string at the protocol level.
If the SMTP/LMTP server supports RFC 2034 Enhanced Error Codes, it MUST prepend an appropriate Enhanced Error Code to the reason text. Enhanced Error codes 5.7.1 or 5.7.0 are RECOMMENDED.
Implementations MUST NOT silently upgrade 'reject' actions to 'ereject' actions in a Sieve script, as this could cause unexpected behavior changes not anticipated by the script owner.
Implementations MUST prohibit execution of more than one 'reject' (or 'ereject') action in a single Sieve script.
Implementations SHOULD log instances when a non-delivery report is not sent and the reason for not sending it (e.g., content was spam, return-path invalid).
'reject' MUST be incompatible with the 'vacation' action. It is NOT RECOMMENDED that implementations permit 'reject' together with mail-delivery actions such as 'keep', 'fileinto', or 'redirect', as this violates the SMTP principle that a message is either delivered or bounced.
Script generators SHOULD ensure that rejection actions resulting from anti-spam or anti-virus positive tests use 'ereject' rather than 'reject', as it is more suitable for such rejections.
Sieve implementations able to reject at the SMTP/LMTP level MUST do so and SHOULD use the 550 response code when executing 'ereject'.
The 'ereject' action MUST NOT be available in environments that do not support protocol-level rejection (e.g., an MUA), and MUST be available in all other environments that support the 'reject' action.
The 'reject' action MAY refuse delivery over SMTP/LMTP (instead of MDN) only if: (1) the reason string is US-ASCII or both parties support a UTF-8 SMTP extension, AND (2) LMTP is used, or SMTP with a single recipient, or SMTP where all recipients refused delivery.
The Sieve interpreter implementing 'ereject' MUST carry out the most preferable refusal action possible (SMTP/LMTP 5XX first, DSN second) and MUST fall back to lesser actions if a preferred action fails.
When a message arrives over SMTP with multiple recipients and only some are refusing delivery, the server MUST accept the message and generate DSNs for all recipients refusing it; this exception does not apply to LMTP, which supports per-recipient rejection.
The 'ereject' action cancels the implicit keep and refuses message delivery, with a UTF-8 reason string. It always favors protocol-level (SMTP/LMTP 5XX) rejection over sending a DSN, falling back to a DSN only if protocol-level rejection is unavailable.
The 'reject' action cancels the implicit keep and refuses delivery, typically via an MDN sent back to the envelope sender. Unlike 'ereject', it prioritizes preserving the exact refusal reason text; protocol-level SMTP/LMTP refusal is only permitted under specific conditions (ASCII-only reason, single recipient, or LMTP).
IANA registration for the Sieve 'ereject' extension (replaces preliminary registration): capability name 'ereject', adds the 'ereject' action for refusing delivery as early as possible (preferably at the protocol level); may not preserve exact reason text if it contains non-US-ASCII. Registered under RFC 5429.
IANA registration for the Sieve 'reject' extension (updated from RFC 3028): capability name 'reject', adds the 'reject' action for refusing delivery of a message while conveying the exact reason back to the client. Registered under RFC 5429.
Protocol-level rejection (SMTP 5XX) is preferable to accepting and bouncing messages because it eliminates the risk of misdirected MDNs/DSNs contributing to Joe-job blowback spam floods targeting innocent third-parties whose addresses were forged in spam runs.
Silently dropping non-delivery reports (permitted by this document) may create denial-of-service situations because spam-detection and return-path verification can produce false positives, causing legitimate messages to be refused without notifying the sender.