sendmail-8.12.6+cyrus-imapd-2.0.17: check presence of the cyrus mailbox during establishing SMTP connection

[Igor Brezac]

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