Perms are consistent (or are intended to be) all of the qmail perms are
ldap on another server.
That server (ldap) is O.K.
It looks to me like:
1) qmail-smtpd receives the mail and
2) invokes qmail-queue to put the reeived message in the queue.
3) qmail-send eventually get the message for delivery and
4) invokes qmail-lspawn for local or qmail-rspawn for remote and
5) if qmail-lspawn it then calls qmail-local or if qmail-rspawn calls
qmail-remote and
6) if qmail-local it then delivers it (this is what is not working). if
qmail-remote it is
up to the remote receiver to process it (I don't care not my
responsibilty...).
So, it appears to me that the possibilities are:
qmail-send runs as root,
qmail-lspawn runs as root, owner root.qmail, 0711
qmail-local runs as root, owner root.qmail, 0711
Anybody see anything out of whack here?????
Eric "Shubes" wrote:
I think you're on the right track with permissions (#1).
Don't forget to use the right mount options for nfs.
Also, various pieces of qmail run as various users. Are the user
*numbers* consistent across all machines?
Operations wrote:
My qmail is used on nfs, it shares control and a couple of other
directories all 3 of my machines
use the same version. I was working on re-arranging some of the nfs
stuff because we acquired
a RAID array, and I in-advertantly deleted the contents of it,
however, I had the same
install on the other servers, except no updated info, i.e.
assign,virtualdomains, rcpthosts,
so I copied them over after with the same permissions.
Currently, I switched smtp servers to see what qmail saw and did upon
receipt, I am getting the following
message:
delivery 139: deferral: Unable_to_chdir_to_maildir._(#4.2.1)/
It appears:
1) whatever program is trying to dispatch the mail to the appropriate
dir has no permissions
or
2) There is something different in one of the run scripts. This I
doubt, generally only things in
these is memory portion on smtp (I believe), have to look, I don't do
'custom' programming on
these as a matter of practice.
Eric "Shubes" wrote:
How'd you recreate /var/qmail? There's a lot of stuff under there.
Have you tried rebuilding the qmail-toaster*.i386.rpm, then rpm
--freshen it?
If worst comes to worst, I think you'll be removing and re-install
all the toaster packages. :( Keep in mind, that might be the
quickest road to recovery.
Operations wrote:
If anyone has any insight on this, any help woudl be greatly
appreciated.
It killing me, if my customers don't first....
Operations wrote:
Hi all -
I was browsing through the archives for somehting on this, maybe
someon knows off
of the top of their head... (fingers crossed). Here is the problem:
1) Qmail is receiving email, but not delivering.
Here is what caused the problem:
I in-advertantly deleted the /var/qmail directory, so all that was
working is not,
had to re-create.
This is what I have done so far:
1) recreated the 'assign' file.
2) recreated the 'locals' file.
3) recreated the 'rcpthost' file.
Pop is working, I can log into it just fine. It appears
qmail-send is not authenticating
properly. I get the following errors:
Hi. This is the qmail-send program at daffy.frontierbroadband.com.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>: <- this is a real email address,
couldn't resist a twist on it...
Sorry, no mailbox here by that name. (#5.1.1)
vuserinfo returns appropriate data.
This seems to be just related to the distribution only...
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
