On Mon, 2004-08-23 at 15:18, Bruno Negrão wrote:
> Hi Rick,
> 
> > > Rick,  are you currently using this?
> >
> > For a whole domain.  Not per user.
> I can't get you, what you mean "for a whole domain, not per user"? \

:)  I use the 2nd qmail install for forwarding a whole domain, not an
individual user account.

> I want
> to split a whole domain... (??) You told you have to create a .qmail file
> on the 1st server for every account that is configured on the 2nd server.
That's the easiest way to do it.  But like you said, that would not be
very scalable.. But it all depends on your needs.  

> Isn't it "per user configuration" too?

That would be easiest initially.

> 
> > > It seems you omitted that I would have to make the same thing in the
> second
> > > server, creating .qmail files forwarding messages to the users
> configured
> > > in the 1st server.
> >
> > No, if you create a .qmail-default for each user that needs to be
> > forwarded, you only need to create THOSE users on the 2nd server.
> But what happens when a user of the second server send an email to a user
> of the first server?  The seconds server would bounce an error message "this
> account doesn't exist" if it is not configured to forward the e-mails for
> unexistent accounts for the fisrt server.

I was assuming you already have a relay setup, which isn't your POP/IMAP
server.  Again though, to keep it 'simple', you could run a 2nd instance
of qmail on that server, listening on it's own IP.  It would follow the
MX records for all domains (so yes, sending internally would not be
efficient, because it would goto the 1st server, and back to the 2nd). 
There's your outgoing address.

> > > I think this configuration isn't scalable. What would happen if I'd
> like to
> > > split the domain through 3 or more machines? Or if I'd like to split
> other
> > > domains through other servers? It would became an administration
> > > nightmare... don't you think?
> >
> > Then I'd set a flag, or create a field in MySQL - and look at using
> > maildrop for the redirection, after a perl script checks for the routing
> > information.
> This was too interesting. Can you write this with more detail? I never used
> vpopmail integrated with MySQL, and I don't master databases or SQL. What
> program would check the mysql database to discover where the maildir is
> installed?

Well.. most vpopmail 'toasters' I've seen lately use MySQL as the user
store.  So (again to make it simple) were you to add an extra field to
the vpopmail table (server_number), and have a perl script check that
field, for the # :

#!/usr/local/bin/perl -w
use strict;
use DBI;
my ($hash_ref);
my $driver = DBI->install_driver('mysql');
my $dbh = DBI->connect('DBI:mysql:vpopmail','vpopmail','vpoppass');
die "Unable to Connect $DBI::errstr\n" unless (defined $dbh);

my $table_data = $dbh->prepare(q{SELECT * FROM vpopmail WHERE (pw_domain
= ? AND pw_name=?)});
$table_data->execute($ARGV[1],$ARGV[0]);
if ($hash_ref = $table_data->fetchrow_hashref){
        echo "Server Number: " $hash_ref->{server_number} ."\n";
        exit $hash_ref->{pw_svclvl};
}
#print "Not Found!!\n";
else { exit (1); }

Then in your .qmail-default (for the domain):

| maildrop mailfilter

In your mailfilter file:

SHELL="/bin/sh"
VPOP="| /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox"
VFWD2="| /var/qmail2/bin/forward [EMAIL PROTECTED]"
VHOME=`/home/vpopmail/bin/vuserinfo -d [EMAIL PROTECTED]
MAILDIR=$VHOME/Maildir
#Run your Perl script from here
`/home/vpopmail/domains/host.com/getserver_number.pl $EXT $HOST`
if ( $RETURNCODE == 0 )
{
        #deliver locally
        to "$VHOME"
}
if ( $RETURNCODE == 1 )
{
        # Send to Server2
        to "$VFWD2"     
}


Ok, I just did that off the top of my head, so I can't guarantee it will
work, or is efficient :P

> 
> If qmail-ldap already addresses this problem, do you believe it is worth to
> reimplement this using an mysql database? Wouldn't it be "reinventing the
> wheel"?

If you don't know SQL or ldap, I suppose it wouldn't matter either way. 
But it seems to me you're going to have better luck finding help if you
don't got the ldap way - just because fewer people are using qmail-ldap.

Anyways, Above I combined two things that I do in production.  The first
is check the user's "Service Level" field in MySQL, then filter Spam
based on that.  The other is the second qmail install for forwarding all
users to another server.. Yes, It would be easier to do SMTP routes, but
that customer wanted their own specific SpamAssassin config, so I have
to run it through their own SpamAssain config before I can reforward it.

Rick

> Regards,
> bruno.

Reply via email to