Subject: Managesieve Reauthentification. Replication

From: Дилян Палаузов<[email-masked]>
Date: Sun, 27 Jul 2008 20:18:18 +0200

Hello,

Are there any reasons to include "Reauthentication is not supported by 
ManageSieve protocol's profile of SASL.  I.e. after a successfully 
completed AUTHENTICATE command, no more AUTHENTICATE commands may be 
issued in the same session." in draft-martin-managesieve-10/2.1 
AUTHENTICATE Command ?

If for some reason a lot of sieve scripts are generated and need to be 
uploaded, then the uploading application has to make several connections 
to the managesieve server (using the same master authname that can edit 
all scripts and different usernames). E.g. when the scripts for a 
mailing list N2 are generated, the users owner-N2@, N2@, 
N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need to be 
uploaded in different connections to the managesieve server. This is 
less efficient than using the same managesieve connection and 
reauthenticating from time to time. Now imagine that one wants to 
regenrate the scripts for all lists on her server ... a lot of 
connections need to be established. (A mailing list needs sieve script 
that does SMTP rejects and hence saves one bounce at later time).

Moreover, if a domain has several MX DNS records, all scripts among the 
mail servers shall be consistent to some extend. It would be useful if 
the managesieve servers can use managesieve as protocol for replication 
among each other. This could be achieved if the LISTSCRIPT command (or a 
new command) can provide a timestamp when the script was uploaded. And 
one more command shall allow the master user (the one that can 
authenticate with different usernames) to list all users who have 
uploaded scripts and the timestamp when the user last changed his 
script. Going a step furhter, during the replication one server shall be 
able to request the list of the users who changed their scripts only 
after a given timestamp.

	Със здраве,
		Дилян

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 27 Jul 2008 23:29:21 +0200

> issued in the same session." in draft-martin-managesieve-10/2.1 

That makes it possible to drop privileges on authentication.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 27 Jul 2008 23:33:50 +0200

Another response, independent.

Дилян Палаузов writes:
> uploaded, then the uploading application has to make several 
> connections to the managesieve server (using the same master authname 
> that can edit all scripts and different usernames). E.g. when the 
> scripts for a mailing list N2 are generated, the users owner-N2@, 
> N2@, N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need 
> to be uploaded in different connections to the managesieve server.

Why are these independent? Why would you wat to have lots of different 
user names and passwords for owner-N2, N2, N2-unsub... etc?

It seems to me that what you really want is an extended setactive 
command or cross-user includes.

Arnt

---

From: Дилян Палаузов<[email-masked]>
Date: Mon, 28 Jul 2008 12:28:18 +0200

Hello Arnt,

 > Why are these independent? Why would you want to have lots of
 > different user names and passwords for owner-N2, N2,
 > N2-unsub... etc?
 >

owner-N2 and N2-request are not users, but addresses. To upload scripts 
over managesieve it is not possible to give an address, one has first to 
authenticate and then username=address. The "username" does not have to 
belong to some user, as far as one authenticates with the "master user" 
who can install global and private scripts for other users. There is no 
password for the non-existent users N2-request, owner-N2. The latter are 
addresses.

N2 is a mailing list and in consequence the addresses owner-N2, 
N2-unsub... etc do exist. The scripts for that addresses do not have to 
be independent, it can be the same script, however this are different 
addresses, uncoupled from IMAP. Under this circumstances, the sieve 
interpretation has either to find out that owner-N2 and N2-request are 
supposed to have the same script (transited to imap terms, the addresses 
end in the same mailbox), or to install scripts for each user 
independently. In the latter case the sieve interpretation can consider 
the owner-N2, N2-request etc as normal recipients and obtain their 
scripts in the usual way. If the interpretation has to find out that 
owner-N2 and N2-request are related, then it is first more difficult (to 
integrate this information when uploading the script), and second the 
scripts for owner-N2, N2-request etc are supposed to coincide. This is 
not necessary.

 > That makes it possible to drop privileges on authentication.
Could you explain this with a little bit more words?

	Със здраве,
		Дилян

Arnt Gulbrandsen schrieb:
>> scripts for a mailing list N2 are generated, the users owner-N2@, N2@, 
>> uploaded in different connections to the managesieve server.
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 28 Jul 2008 12:50:43 +0200

> Could you explain this with a little bit more words?

Dropping privileges means that the process voluntarily gives up the 
rights to do something. In the case of managesieve, the server process 
voluntarily gives up the ability to access or modify files belonging to 
any user other than a specified one, and it cannot recover that ability 
later.

This is often used to limit the effects of bugs, particularly security bugs.

Arnt

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Jul 2008 13:24:21 +0100

Arnt Gulbrandsen <[email-masked]> wrote:
>[email-masked] wrote:
>> Are there any reasons to include "Reauthentication is not supported by=20
>> ManageSieve protocol's profile of SASL.  I.e. after a successfully=20
>> completed AUTHENTICATE command, no more AUTHENTICATE commands may be=20
>> issued in the same session." in draft-martin-managesieve-10/2.1=20
>> AUTHENTICATE Command ?
>

We have a distributed mail store, where each back-end Cyrus server hosts
a subset of the users, and front-end proxy servers direct connections
depending on the user that logs in. The proxy only needs to implement
enough POP/IMAP/managesieve to allow the user to log in, then it knows
the username and can find out which back-end server to connect to. After
a successful login the proxy just shovels bytes back and forth.

Reauthentication would require a much more complicated proxy.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE: EASTERLY 3 OR 4, INCREASING 5 OR 6 IN FORTIES AND
CROMARTY. SLIGHT OR MODERATE. THUNDERY SHOWERS, FOG BANKS. MODERATE,
OCCASIONALLY VERY POOR.