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

(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 -- inbound port 25 and port 587 is allowed for SMTP or SMTP AUTH.


Reply via email to