> >   From looking at your aliases table, neither one of these are in
> > there.  So all the messages having problems are trying to be delivered
> > to addresses that aren't found ...  what version of dbmail are you
> > running?  All addresses you're going to send to need to be in the
> > aliases table; I just tried a bad address here, and dbmail created
> > a bounce saying the user was unknown.
> > 
> >   In your dbmail.conf you have:
> > 
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > 
> > But you don't have a [EMAIL PROTECTED] alias in dbmail's
> > aliases table.  There are a lot of other postmaster aliases (all of
> > which have "postmaster" as the deliver_to, which itsself doesn't have
> > an entry in aliases table either).
> 
> This email adress are not in alias table becouse they are in another 
> machine. I have two mail servers one is only for cnett.com.br domain and 
> the other (this one that is getting crazy) is for my domain like 
> marilon.com.br, radioeducadora1120.com.br and many others.

  Ah, I missed that.  Sorry.

 
> I have an alias like this:
> 
> All messages for domain @lojatrento.com.br must be redirected to email 
> address [EMAIL PROTECTED] (in other server), will it work?

  Yes, that will work.  dbmail will handle domain aliases from the
alias table, or you could do it in postfix also, if you wanted
(in the virtual table, I believe).


> >   It looks like there may be some confusion on postfix vs. dbmail
> > aliases (which isn't terribly uncommon - a good item to be covered
> > in the upcomming documentation).  Postfix has it's own aliases, 
> > in /etc/postfix/aliases for your case; these are completely seperate
> > from dbmail's aliases table.  Postfix uses them for forwarding/
> > duplicating/whatever mail before it ever hits dbmail.  When a
> > message is going for final delivery (from postfix's perspective)
> > and it is to a domain handled by the dbmail: transport, postfix
> > hands it off, telling dbmail what it's current recipient is (via
> > ${recipient} param in master.cf).  Dbmail then takes the message
> > and will try to lookup an entry in the aliases table for whatever
> > recipient it was given.  If that fails, it'll try to send a bounce,
> > using sendmail (which re-injects into postfix's arena).  If the
> > aliases table lookup does return something, it'll try to recursively
> > lookup that result back into the aliases table, until it finally
> > gets something that's not in the "alias" side of that table, and
> > it tries to deliver it.  If the result is numeric, it's treated as
> > a user_idnr from a user in the users table, and looks for an INBOX.
> > It could also be a command or an email address for off-site delivery.
> > Never will dbmail look at your postfix aliases table to expand
> > "postmaster" into anything else, so any of those should be failing.
> 
> So if I need to make all postmaster messagens from all domains 
> registered in dbmail tranport be sent to another postmaster account in 
> another linux box, how can I do the alias for this?

  The way you have it now everything points to "postmaster" as the
deliver_to - all you need to do is add another aliases entry with
"postmaster" as the alias and "[EMAIL PROTECTED]" (or  whatever)
as the deliver_to.


> >   I've never run across this exact problem before, and don't know
> > why the processes are hanging around so long.  Try cleaning up
> > all the aliases though, and see if that fixes things.  Typically you
> > just get a huge amount of mail in a loop trying to deliver/bounce
> > to bad addresses when things are messed up like this.  Is any mail
> > getting through at all, just certain ones failing?
> 
> Yes... The most emails are getting in correctly but some hangs. Some of 
> them hangs in SMTP (when some user from one of the domains try to send 
> an email) and others hangs in POP (when a client try to catch his messages).


  Strange.  Are the pop server processes hogging lots of cpu, or just
sitting there idle/dead?  There's a known problem in the signal
handling under linux that causes it to sometimes trigger and eat up
cpu time.  Try attaching to those processes with strace also, and see
if they're making any system calls (which is what strace prints out).
Ie.  strace -fp <pid to trace>

  Also, if you're updating to dbmail 1.1 ... any change?

> I will wait for you answer about my aliases and them I will delete every 
> alias and create all by hand.

  That may not be completely necessary, but at the same time might
be just as easy as trying to examine/fix everything that's there, too.


> Thanks a lot for you help.

  No problem.

Jesse

--
Jesse Norell
jesse (at) kci.net


Reply via email to