Ken that would be great. What about aliases? If an alias doesn't exist (not the pointer -- but the alias) then reject and drop the connection.
Jim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ken Murchison Sent: Wednesday, November 05, 2003 3:23 PM To: [EMAIL PROTECTED] Subject: Re: sendmail-8.12.6+cyrus-imapd-2.0.17: check presence of the cyrus mailbox during establishing SMTP connection 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