Hi.

[Alexey Naidyonov <Growler@tula.net>]

        Hi, I'm newbie, but I like zmailer's ideas and I'm going use it on
    my ISP boxes. I have some questions, but first, I beg your pardon for
    my poor English. 

        1)  Why does smptserver check HELO/EHLO argument but not real peer
    hostname for HELO/EHLO patterns? Windows clients uses it's "Computer
    name" for HELO/EHLO identification, so it's unefficient. I think, it
    will be much better to check real hostname:

smtpcmds.c.diff

        2) Please explain me, who are zmailer devlopers? What should I do, if
    I want some fixes/additions/expansions to be included into
    distribution and  I'm able to write it myself?

        3) I've got an idea for your money-box :) Well, lets call it "File
    System Domain Database". In a couple of words, virtual domains are
    mapped into filesystem. Lets we have a lot of virtual domains and a lot 
    of users (my case :). Lets some of them must be handled this way:

user1@domain1.tula.net is cyrus mailbox1
user0@domain1.tula.net is user0@tula.net
user2@domain1.tula.net is cyrus mailbox2
user3@domain2.tula.net is cyrus mailbox3
user4@domain3.tula.net is cyrus mailbox4
user5@domain4.tula.net is cyrus mailbox4 too :)
*@domain5.tula.net is cyrus mailbox5 and
*@domain6.tula.net is smtp mx.domain6.tula.net, except
idontlikehime@domain6.tula.net, which must be unresolvable and
postmaster@domain6.tula.net, which must be resolved as postmaster@localhost

        So, using File System Domain Database, you have to create six
    directories (net/tula/domain1 ... net/tula/domain6) and put into it
    this files:

net/tula/domain1/user
 user1:          cyrus!mailbox1
 user0:          user0@tula.net
 user2:          cyrus!mailbox2

net/tula/domain2/user
 user3:          cyrus!mailbox3

net/tula/domain3/user
 user4:          cyrus!mailbox4

net/tula/domain4/user
 user5:          cyrus!mailbox4

net/tula/domain5/forward
 cyrus!mailbox5

net/tula/domain6/user
 idontlikehim:  error!unresolvable
 postmaster:    postmaster

net/tula/domain6/forward
 smtp!mx.domain6.tula.net

        For address user@domain.dom, my module checks path dom/domain/. If
    path exists, path dom/domain/.db/ will be checked. If it doesn't exist, 
    it will be created. Then files dom/domain/user and dom/domain/.db/user.db 
    will be checked and compared. It source file newest then the real DB
    file, DB file will be re-created. If key "user" doesn't exists, file
    user.auto will be checked in a similar way. If "user" still not found,
    file dom/domain/forward checked. If it exists, it's first string
    interpreted as channel!destination pair. If it doesn't exists, address
    will be resolved as error!unresolvable, except for postmaster@domain.dom
    (in that case, it will be resolved as "postmaster"). Files user and
    user.auto (in my case, user.auto generated automatically from Oracle
    database, used for cyrus authorization) looks like aliases file, except 
    they may contain channel!destination pair as a key value.
        Module source follows:

grdb.cf

        Turn it on by adding following line just after fqnd_neighbour call:

        tmp=$(grdb_neighbour "$origaddr" "$address" $A) &&
                return $tmp

-- 
 Alexey V. Naidyonov    
 O.J.S.C. Tulatelecom, ISP Dept.