Peter Palmreuther wrote:
YMMD, but 'fopen()', a fast, hash-driven, seek (the way 'cdb' works)
and a quick 'read' for a few bytes should be less overhead than a
complete SQL query, including parsing the result. Even if your MySQL
would run locally and accessed through UNIX-socket I'd expect it to be
not only more overhead, but also taking more time than this quick
local, read-only, precise access in a small file.
But it's your system, whatever makes you happy and serves your needs
can be your solution.
N.B.: Number of authentication should not play a role in accessing
your cdb-file, if you're configured vpopmail to only use MySQL the cdb
will be as static as your kernel: unless *you* change it, it won't
change.
(I'm going by memory, so this is a paraphrase.)
If you aren't familiar with the Matt Simerson mysql patch, it was born
because there can be major lookup problems with the cdb file, especially
using POP before SMTP. Imagine the POP server populating the text file
(and re-compiling the CDB) 10 times per second. Now, imagine 20 queries
per second on the CDB file, that in some cases is in the middle of a
file alteration. The disk, in cases like this, hardly ever gets to
writing the file from a kernel buffer, so what you are seeing is memory
accesses on this file most of the time. There will simply be cases
where the CDB file gets hammered too hard and corrupted. It will need
attention by the admin during peak hours.
Mysql has no problem with the above scenario, as it is designed for
heavy accesses and changes to its tables.
By the way, a way to solve the original problem sound to me the JOB FOR
a FIREWALL and ROUTER! I am not sure if the server in question has one
or two Ethernet interfaces, but if it doesn't, they often cost about $10
to $30 (unless they both need global IP's).
If you route inbound mail from your upstream MXs to one interface (say,
fxp0) and that is the only source of port 25 traffic from the global
internet, you could have qmail listen to that interface. Firewall setup
is simple -- only allow the MX servers to talk to that port 25.
Meanwhile, the internal port 25 traffic (which as another topic should
be port 587) can come into the other interface, say fxp1. The firewall
would need no restriction for this interface.
As my other clue, your customer and others should get used to using port
587 as their SMTP relay port, rather than port 25. That way, some of
your customer's users could be on the global Internet, and still send
mail to their firewalled-port-25-is-illegal mail server all day on the
submission port 587. It would work internally, too.
So here is a summary:
fxp0 - global internet -- inbound port 25 only allowed from 3 IP
addresses. port 587 is allowed for SMTP AUTH.
fxp1 - internal net like 10.0.0.21 -- inbound port 25 and port 587 is
allowed for SMTP or SMTP AUTH.
Billy
