[Dovecot] MANAGESIEVE patch v3 for dovecot 1.0.rc28

[Stephan Bosch]

Stephan Bosch schreef:
> Andrey Panin schreef:
>> On 085, 03 26, 2007 at 06:34:21PM +0200, Stephan Bosch wrote:
>>> Hello dovecot users,
>>
>> I don't see how anonymous logins are handled. You must handle anonymous
>> logins according to managesieve draft (see below) or don't advertise
>> ANONYMOUS SASL mechanism at all.
>>
>>     Implementations MAY advertise the ANONYMOUS SASL mechanism [SASL-
>>     ANON]. This indicates that the server supports ANONYMOUS sieve
>>     script syntax verification. Only the CAPABILITY, PUTSCRIPT and
>>     LOGOUT commands are available to the anonymous user. All other
>>     commands MUST give NO responses. Furthermore the PUTSCRIPT command
>>     SHOULD NOT store any data. In this mode a positive response to the
>>     PUTSCRIPT command indicates that the given script does not have any
>>     syntax errors.
>>  
> The managesieve daemon extracts the available authentication mechanisms 
> from the dovecot authentication implementation. It does not display the 
> ANONYMOUS mechanism by default. So, obviously you must have configured 
> ANONYMOUS somewhere. I haven't tested the daemon's behavior with 
> ANONYMOUS thusfar.
> 
> This is what my server currently reports:
> 
> "IMPLEMENTATION" "dovecot"
> "SASL" "PLAIN"
> "SIEVE" "FILEINTO REJECT ENVELOPE VACATION IMAPFLAGS NOTIFY SUBADDRESS 
> RELATIONAL COMPARATOR-I;ASCII-NUMERIC"
> "STARTTLS"
> OK "Dovecot ready."
Ah ok, after reading the SASL-ANONYMOUS RFC and playing around with 
anonymous authentication, I understand what you mean (found a bug in 
authenticate as well: continued responses don't work anymore at the 
moment until next patch version).

I'm currently looking for a means to detect whether the current user is 
logged-in anonymously, to fully support the draft spec.

Note: like the current IMAP implementation, the managesieve anonymous 
login gives full access to the anonymous client within the privileges of 
the user specified in the config file with 'auth_anonymous_username'. 
Given the draft spec and common sense this is NOT WHAT YOU WANT! Thanks 
Andrey for pointing this out.

Regards,

Stephan.