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:
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: email@example.com is cyrus mailbox1 firstname.lastname@example.org is email@example.com firstname.lastname@example.org is cyrus mailbox2 email@example.com is cyrus mailbox3 firstname.lastname@example.org is cyrus mailbox4 email@example.com is cyrus mailbox4 too :) *@domain5.tula.net is cyrus mailbox5 and *@domain6.tula.net is smtp mx.domain6.tula.net, except firstname.lastname@example.org, which must be unresolvable and email@example.com, 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: firstname.lastname@example.org 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 email@example.com, 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 firstname.lastname@example.org (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:
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.