Hello,
> Actualy I dont know exactly what it is but sendmail.postfix is in
> /etc/dbmail.conf file. It always work with this configuration and never
> stoped.
It's probably fine, I'd guess - that's what your postfix config
is setup to use, also. Try "file /usr/sbin/sendmail.postfix" and
see if it is a readable script though, just for fun. What linux
distribution are you using, btw?
> : > dbmail 26335 0.0 0.5 3856 1200 ? S 06:48 0:00
> : > /usr/sbin/postdrop -r
> :
> : Here user dbmail is running postdrop, which is what saves a message
> : into the delivery queue - ie. probably the previous sendmail.postfix
> : command delivering a message. As this is running from dbmail, I'd
> : guess you are either bouncing a message or have alias forwards.
>
> Nops... Its not bouced its just stays there till the box crashes.
> : And the rest is pretty similar stuff. What are the aliases table
> : entries for '[EMAIL PROTECTED]' and
> : '[EMAIL PROTECTED]'? Can you attach to that postdrop
> : process and see if it's doing anything (as root run "strace -fp 26335).
>
> There is no entry in alias table for [EMAIL PROTECTED] the alias for
> [EMAIL PROTECTED] is the same as the email. I use login = email in
> my server.
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).
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.
> I could not run strace becouse it is not installed.
You might see if you can find the package for this program,
as it's very useful in tracking what a process is doing (about
as good as you can do without actually tracing it in a debugger).
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?
--
Jesse Norell
jesse (at) kci.net
