/usr/share/doc/cyrus-doc-2.4/html/sieve-protocol.html is in cyrus-doc-2.4 2.4.17+caldav~beta9-3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 | <!-- $Id: sieve-protocol.html,v 1.5 2010/01/06 17:01:29 murch Exp $ -->
<HTML><HEAD>
<TITLE>Protocol for Sieve script exchange</TITLE>
</HEAD><BODY>
<H1>Protocol for Sieve script exchange</H1>
<i>Please note that this document is not authoritative and may well be out
of date; you should look at <a href=specs.html>specs.html</a> for the
current authoritative document for the MANAGESIEVE protocol.</i>
Note: This is <b>not</b> a standards track protocol. If you decide to base
a program upon it you have been warned.
This is a simple text-based protocol for getting user sieve scripts
onto the (presumably sealed) IMAP server. The requirements for this
process are:
<ul>
<li> the user must authenticate to gain access, preferably via a
secure SASL mechanism.
<li> only valid sieve scripts may be accepted
</ul>
Additional features provided:
<ul>
<li> the ability to manage multiple scripts on the server with zero or one
of them being the "active" sieve script
</ul>
<h3>Types</h3>
This is a line-oriented protocol much like [IMAP] or [ACAP]. There
are two types: ATOMS and strings, all space ('SP') separated. Strings
may be quoted or literal. See [ACAP] for detailed descriptions.
<br>
<i>sievename</i> is a string where only certain characters are
allowed and it must be at least 1 character long.
<h3>Commands</h3>
<dl>
<DT><tt>AUTHENTICATE SP <i>string</i> [SP <i>string</i>] EOL</tt>
<DD>
SASL authentication; the parameters are the mechanism and optionally
the initial data. Initial data is base64 encoded. The server
replies with an OK or NO response, or a base64 string followed
by an EOL. Client then replies with a base64 string followed
by an EOL, and the procedure is repeated.
<DT><tt>NOOP EOL</tt>
<DD>
No side effects. Valid replies: OK or NO.
<DT><tt>LOGOUT EOL</tt>
<DD>
Logout: terminates connection. Valid replies: OK or NO.
<DT><tt>GETSCRIPT SP <i>sievename</i> EOL</tt>
<DD>
The parameter is the name of the requested script.
Returns: <tt>string EOL</tt> containing the script data.
Get the script with name <i>sievename</i> from the server. Valid
replies: OK or NO.
<DT><tt>PUTSCRIPT SP <i>sievename</i> SP <i>string</i> </tt> EOL
<DD>
Puts <i>sievename</i> with data <i>data</i> onto the server if
possible. Valid replies: OK or NO.
<DT><tt> SETACTIVE SP <i>sievename</i> </tt>EOL
<DD>
Set the script with the name <i>sievename</i> as the active
script. Any other script that was active is no longer. Valid replies: OK or NO.
<DT><TT>DELETESCRIPT SP <i>sievename</i> </tt>EOL
<DD>
Delete the script with <i>sievename</i>. Valid replies: OK or NO.
<DT><TT>LISTSCRIPTS EOL</TT>
<DD>
Returns zero or more: <i>sievename</i> EOL.
Where the active script has a '*' at the end of its name.
Valid replies: OK or NO.
</dl>
|