From: Mike M (mikeopennix.com)
Date: Thu Dec 02 2004 - 15:22:05 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi everyone,

Our email servers originally ran only qmail, and vpopmail to handle the
virtual domains. To solve most of the problems associated with running
qmail in the current email climate, I have set up Postfix to handle all
incoming traffic. Messages that make it past the myriad of checks are
sent to amavisd-new, which then sends the messages on to the original
qmail instance. We will continue to use the Postfix -> amavisd-new ->
qmail setup on the existing servers, until we bring up replacements that
will (likely) take qmail out of the equation. The whole setup works quite
well, but I am always looking at ways to improve upon it.

For instance, I have written a Perl script that enumerates all valid
recipients, forwards, and aliases on the systems and creates a hash file
to be used by Postfix via relay_recipient_maps. The script runs from a
cron job so that Postfix can be made aware of changes automatically. The
problem is the delay between the time the changes are made and the running
of the cron job, which runs every two hours. This isn't a big deal, but
I'd like to eliminate the delay if possible. My thought was to compile
vpopmail with MySQL support and have Postfix use the resulting tables for
the relay_recipient_maps check, thus changes would be seen as the happen.

When I tested this out on a dev box, I found that vpopmail stores the
local part and domain part of accounts in separate fields. As I
understand it the value of $lookup when querying relay_recipient_maps is
userdomain.tld. Therefore, this will not work with the structure set up
by vpopmail.

Solutions I have considered for this new roadblock are:
1) Write a policy daemon to take the place of reject_unlisted_recipient,
so that I could use more complex queries.
2) Patch the vpopmail code so that the tables contain a field with the
full email address.

Before I embark on either one, though, I wanted to be sure my
interpretation of the value of $lookup, and how it is used, was correct.
Because if I could use more complex queries for relay_recipient_maps
lookups, I'd much rather do that. Reading the documentation didn't lead
me to believe I would be able to do this, even with additional_conditions.
 I would need Postfix to split $lookup into something like $user and
$domain.

If I were to write a policy daemon in Perl and place a
check_policy_service entry in smtpd_recipient_restrictions, would I be
shooting myself in the foot performance-wise? With relay_recipient_maps
I'd be able to use proxymap to reduce the number of MySQL connections.
I'd also be using a method native to Postfix, which I assume would be more
efficient than a policy daemon written by me. :)

As far as patching the vpopmail source, ehh, I'd rather avoid that.
However, if I could get it to work then I'd be in good shape. If that
seems like my best option then I'll take this discussion to the vchkpw
mailing list.

Thanks in advance for any input/suggestions. Sorry for the long post.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]