On Wed, 5 Nov 2003, Andrzej Filip wrote: > Igor Brezac wrote: > > On Wed, 5 Nov 2003, Andrzej Filip wrote: > > > > > >>Igor Brezac wrote: > >> > >>>On Tue, 4 Nov 2003, Andrzej Filip wrote: > >>>[...] > >>> > >>>>I also thought that "virtusertable like" solutions [periodic dump of cyrus > >>>>mailbox data into existing sendmail databases] are the best but most people > >>>>had wanted "real time" synchronization. > >>> > >>>True, this would be a long way of doing things. Shell/perl/web/etc > >>>scripts can automate the process of managing cyrus mboxlist and sendmail > >>>maps simultaneously thus keeping the two databases in sync "real time". > >> > >>IMHO making cyrus daemon servicing also simple tcp based "map protocol" (to be > >>introduced in sendmail 8.13) is a better way. I bet it :) > > > > In my opinion it is better if it does more than just the mbox > > verification. I'd like to see the quota check as well. > > The current protocol specification allows only passing one parameter (key) > queries e.g. mailbox name. I am going to try make it capable to pass multiple > parameters queries e.g. mailbox name, "SIZE=" parameter. > > It would be nice to allow interaction with sieve rules at "RCPT TO:" stage. > [it seems to be possible from sendmail's perspective] > > > I am not sure if > > the "map protocol" allows for multiple return codes rather than just > > yes/no type answer. Then there is the performance consideration, I would > > hope that the "map protocol" allows for a "persistent" tcp connection. > > * return codes > <quote> > The status indicator is one of the following upper case words: > OK the key was found, result contains the looked up value > NOTFOUND the key was not found, the result is empty > TEMP a temporary failure occured > TIMEOUT a timeout occured on the server side > PERM a permanent failure occured > </quote> > * current "map protocol" uses TCP connections > (one tcp connection per one sendmail process) > I hope UDP (connectionless) transport will be supported too. >
PERM/TEMP can be used for 'over quota' situations and it should be parameter driven (similar to the way lmtpd deals with over quota). -- Igor