A Protocol for Remotely Managing Sieve Scripts
updated by
Extracted elements (30)
Response codes use a slash-separated hierarchy to allow future extension while preserving backward compatibility: a client that recognizes a parent code but not a more specific child (e.g., understands QUOTA but not QUOTA/MAXSCRIPTS) treats the child as the parent, so new detail can be added without breaking existing clients.
The VERSION capability was introduced to distinguish servers compliant with RFC 5804 from older pre-specification implementations. Lack of VERSION indicates the server predates this specification and does not support RENAMESCRIPT, CHECKSCRIPT, or NOOP commands. The version numbering scheme uses major.minor where incrementing major signals a backward-incompatible change.
Servers not supporting RENAMESCRIPT can be accommodated by clients emulating the operation via LISTSCRIPTS, GETSCRIPT, PUTSCRIPT, SETACTIVE, and DELETESCRIPT. The VERSION capability signals whether RENAMESCRIPT is natively supported.
A ManageSieve client MUST verify the server's TLS certificate identity against the reference identity (hostname or IP) to prevent man-in-the-middle attacks; if using SASL PLAIN over TLS and server identity cannot be verified, the client MUST NOT attempt PLAIN authentication.
A server implementation MUST return SIEVE, IMPLEMENTATION, and VERSION capabilities in response to every capabilities exchange. The SASL capability list MUST be non-empty after TLS is established.
A server MUST check submitted scripts for validity (grammar compliance and supported extensions) on PUTSCRIPT; any script that fails MUST NOT be stored, and the NO response MUST include a human-readable error message with the line number of the first error.
After a successful STARTTLS or AUTHENTICATE command that negotiates a SASL security layer, the server MUST re-issue its capability results followed by an OK response, to protect against man-in-the-middle attacks that alter the capability list.
Both client and server implementations MUST implement the SCRAM-SHA-1 SASL mechanism, as well as PLAIN over TLS, to ensure interoperability.
Both client and server MUST use the SASLprep profile of StringPrep to prepare authorization identities for transmission or comparison; if preparation fails or results in an empty string (unless transmitted as empty), the server MUST fail the authentication.
Client implementations MUST tolerate (ignore) response codes they do not recognize; clients supporting a parent code (e.g., QUOTA) MUST treat an unrecognized child (e.g., QUOTA/MAXSCRIPTS) as the parent.
If a server has an inactivity timeout resulting in client autologout, it MUST be no less than 30 minutes after successful authentication. The timeout MAY be less before authentication.
Prior to successful authentication, only AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP commands are valid; servers MUST reject all other commands with a NO response.
Reauthentication is not supported: after a successfully completed AUTHENTICATE command, the server MUST reject any further AUTHENTICATE commands with a NO reply in the same session.
Servers SHOULD impose quotas to prevent storage overflow; if a command would exceed quota, servers that impose quotas MUST reply with a NO response containing the QUOTA response code.
Sieve script names MUST comply with Net-Unicode Definition and prohibit specific control characters (0000-001F, 007F, 0080-009F, 2028, 2029). Servers MUST allow names up to 128 Unicode characters and MUST NOT truncate names that exceed the server's internal limit.
The ManageSieve client MUST resolve DNS using an SRV record for service 'sieve' and proto 'tcp' (e.g., _sieve._tcp.example.net) before connecting; if SRV lookup fails, the fallback SHOULD be a normal A/AAAA lookup to the default port 4190.
The server MUST NOT allow the client to delete an active script; a DELETESCRIPT request targeting the active script MUST be rejected with a NO response, SHOULD contain the ACTIVE response code.
When pipelining commands, a group sent together MUST NOT include an AUTHENTICATE, STARTTLS, or HAVESPACE command anywhere but as the last command in the list (with a narrow exception for single-round-trip SASL mechanisms that do not negotiate a security layer).
ManageSieve defines thirteen core commands: AUTHENTICATE, STARTTLS, LOGOUT, CAPABILITY, HAVESPACE, PUTSCRIPT, LISTSCRIPTS, SETACTIVE, GETSCRIPT, DELETESCRIPT, RENAMESCRIPT, CHECKSCRIPT, and NOOP. Commands valid in all states are CAPABILITY, LOGOUT, and NOOP; AUTHENTICATE and STARTTLS are only valid in non-authenticated state; all others are only valid in authenticated state.
Response codes provide machine-parsable detail within OK, NO, or BYE responses. The defined codes are: AUTH-TOO-WEAK, ENCRYPT-NEEDED, QUOTA (with sub-codes QUOTA/MAXSCRIPTS and QUOTA/MAXSIZE), REFERRAL, SASL, TRANSITION-NEEDED, TRYLATER, ACTIVE, NONEXISTENT, ALREADYEXISTS, TAG, and WARNINGS.
Server capabilities are sent automatically upon connection and after successful STARTTLS and AUTHENTICATE. Defined capabilities include IMPLEMENTATION, SASL, SIEVE, STARTTLS, MAXREDIRECTS, NOTIFY, LANGUAGE, OWNER, and VERSION. Capability names are case-insensitive and each may appear at most once.
The SETACTIVE command activates a named script or, when given an empty-string argument, disables any currently active script. At most one script may be active at a time; disabling when no script is active MUST result in OK.
IANA created a ManageSieve Capabilities registry. New capabilities MUST be specified in a Standards-Track or IESG-approved Experimental RFC. Initial entries are IMPLEMENTATION, SASL, SIEVE, STARTTLS, NOTIFY, MAXREDIRECTS, LANGUAGE, OWNER, and VERSION.
IANA created a ManageSieve Response Codes registry. New response codes MUST be specified in a Standards-Track or IESG-approved Experimental RFC. Initial entries are AUTH-TOO-WEAK, ENCRYPT-NEEDED, QUOTA, QUOTA/MAXSCRIPTS, QUOTA/MAXSIZE, REFERRAL, SASL, TRANSITION-NEEDED, TRYLATER, ACTIVE, NONEXISTENT, ALREADYEXISTS, TAG, and WARNINGS.
After a SASL security layer is established, the server MUST re-announce all SASL mechanisms it was capable of negotiating. Clients MAY compare the pre- and post-authentication mechanism lists to detect active down-negotiation attacks; user-oriented clients SHOULD notify the user or close the connection if a downgrade is detected.
ManageSieve transactions are susceptible to passive eavesdropping and man-in-the-middle attacks unless TLS (STARTTLS) and/or SASL integrity/confidentiality services are used. If an implementation supports eavesdropping-vulnerable mechanisms such as PLAIN, it MUST support at least one configuration where those mechanisms are not advertised or used without an external security layer.
The TRANSITION-NEEDED and ENCRYPT-NEEDED response codes on failed AUTHENTICATE may disclose whether a username is valid. Server implementations SHOULD provide the ability to disable per-user conditional application of these codes. A malicious server can use TRANSITION-NEEDED to force disclosure of a user's password; clients SHOULD be able to disable the password-transition feature.
A ManageSieve session has two states: non-authenticated (initial state and state after UNAUTHENTICATE) and authenticated. Transition to authenticated occurs on successful AUTHENTICATE. STARTTLS does not change state. UNAUTHENTICATE returns from authenticated to non-authenticated without affecting established TLS/SASL security layers.
Literal strings from client to server use the format `{N+}CRLF` followed by N octets (the '+' indicates non-synchronizing literal). Literals from server to client use `{N}CRLF` followed by N octets (no '+' character). Quoted strings are limited to 1024 octets between the double-quote characters.
The sieve URL scheme has the form `sieve://authority[/[owner/]scriptname]`. The scriptname and owner components are UTF-8 percent-encoded. An empty owner (`sieve://example.com//script`) is distinct from a missing owner (`sieve://example.com/script`) and is reserved for global scripts.