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 [EMAIL PROTECTED] 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] [former: [EMAIL PROTECTED]
