Igor Brezac wrote:

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).


I could probably write this service in a couple hours given its simplicity, but I have a few of questions:

- What would the map name be? cyrus? Would it ever change? Can people envision different types of maps that this daemon would have to support?

- Is the key always the RCPT TO address, including +detail info, or does Sendmail strip this before doing the map lookup?

- How do we handle lookups of public mailboxes? Always return OK?

- I assume that the "mapping" would be a noop, we just spit out the input if the user exists and is under quota.

--
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Reply via email to