On Mon, 2006-12-18 at 09:19 +0100, Michael Monnerie wrote: > > Perhaps a solution is to have a 'dbmail-checkaddr' that returns 0 or > > 1 depending on whether or not the given address can be delivered at > > all? Bad news is that this would have horrible scalability issues > > unless it were a daemon. > > Why scalability? I'm not so fit in databases, but what is the difference > if the MTA makes the queries or they are done by dbmail?
Each time a dbmail-<foo> binary is executed, a new connection to the database is created. This is more expensive than holding a connection option and sharing it over a long period of time, and can get extremely expensive with certain databases that take a long time to connect. Basically it would be cute but not useful. > > At that point, I wonder if some MTA's might > > support using a VRFY query against the LMTP daemon before beginning > > the delivery process, thus removing the need for a separate daemon or > > database interface. > > I think this is not useful: If you configure postfix to verfiy > recipients, it starts storing them in it's own verify.db. I'm not sure > this scales too good (it's a berkeley db), when I hear some people > having 3M customers (probably with extra aliases). Apparently very recent postfixes already have a daemon in mind. We'd have to follow their protocol, here: http://www.postfix.org/tcp_table.5.html Why they didn't just use VRFY I do not know -- then it could have hit the same LMTP server it would next hit to do the actual delivery, saving us the trouble of having to do anything but change the config file. Anyhow, there it is. We'd just have to implement a daemon for it. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
