sendmail-8.12.6+cyrus-imapd-2.0.17: check presence of the cyrus mailbox during establishing SMTP connection
jimm at simutronics.com
Wed Nov 5 17:46:01 EST 2003
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.
From: owner-info-cyrus at lists.andrew.cmu.edu
[mailto:owner-info-cyrus at lists.andrew.cmu.edu]On Behalf Of Ken Murchison
Sent: Wednesday, November 05, 2003 3:23 PM
To: info-cyrus at lists.andrew.cmu.edu
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
>>>>>>mailbox data into existing sendmail databases] are the best but most
>>>>>>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
>>>>>maps simultaneously thus keeping the two databases in sync "real time".
>>>>IMHO making cyrus daemon servicing also simple tcp based "map protocol"
>>>>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
>>parameters queries e.g. mailbox name, "SIZE=" parameter.
>>It would be nice to allow interaction with sieve rules at "RCPT TO:"
>>[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
>>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
>>* 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
More information about the Info-cyrus