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

[Andrzej Filip]

Ken Murchison wrote:
> 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:

All the answers below are from sendmail perspective.

> - 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?

"cyrus" seems to be good default name.

Let us start with "mailbox presence" checking.
Next version may also:
* check if mailbox will accpet message of given size based on "SIZE=" 
parameter of "MAIL FROM:"
* take into account who successfully authenticated SMTP session
[it can make some folders accessible]
* apply some sieve reject rules based on envelope sender and sending host

I personally think that the best way will be to add a few new lines to 
sendmail.cf for handling the queries result.
Some comments about using socketmap in maps already supported in sendmail.cf:
* "virtusertable" map will ask to many needless queries
[IMHO first user+detail at dom.ain will be sufficient from cyrus perspective]
* "user" map will strip domain part from recipient address

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

It will be easy to make sendmail.cf deliver whatever you like in this matter

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

Return OK they are ready to accept anonymous append

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

accepted => OK key-as-it-was
        OR   OK %0
rejected => NOTFOUND

P.S.
I hope to make sendmail.org use slightly different protocol in the public 
release e.g.
* making the query packet contain multiple parameters
[ now it is map name and single parameter/key]
* making it accept connection less transport (UDP)


-- 
Andrzej [pl>en: Andrew] Adam Filip http://www.polbox.com/a/anfi/
anfi at priv.onet.pl anfi at xl.wp.pl [former: anfi at Box43.pl]