Benjamin A'Lee wrote:
On Mon, Sep 03, 2007 at 10:52:12AM -0400, Thomas H. George wrote:
Kumar Appaiah wrote:
On Mon, Sep 03, 2007 at 08:26:19AM -0400, Thomas H. George wrote:
In ./usr/sbin exim is a symlink to exim4. exim is owned by root:root
with 777 permissions. exim4 was owned by root:tom with 731 permissions.
I changed the permissions to 777 but this did not correct the problem. I
still got exim: permission denied when I executed mailq as user tom.
mailq works for root.
OK, I meant su;mailq or sudo mailq.
You should be able to run mailq as root. Otherwise, you have a
problem. For me, it's just a symbolic link to /usr/sbin/exim4.
Kumar
In man update-exim4.conf an example reads "You want to be able to check
exim's queue as a normal user: Generate a new file, e.g.
/etc/exim4/conf.d/main/40_local_mailq, containing only the line
queue_list_requires_admin = false.
I did this and still the command mailq as a normal user results in
exim:permission denied.
Tom
strace -e trace=open,write mailq run from user tom exits after
open ("/etc/passwd
write(2, "exim: permission denied
If I run /etc/init.d/exim4 restart I get a warning that the exim4 paniclog
is not empty. tail/var/exim4/paniclog ends with "failed to read delivery
status for [EMAIL PROTECTED] from the delivery subprocess.
I have tried editing exim4.conf.template and uncommenting the Login lines
in the Authentication section and entering my user name and password after
the colons in the server_promts line. This does not solve the problem.
Firstly, IIRC, Exim4 has its own ideas about who can run it as
/usr/sbin/sendmail or /usr/sbin/exim; you'd need to run it as root or
find the setting to permit other users to run the commands. This isn't a
problem for Fetchmail, though, as Fetchmail is trying to connect to a
mailserver running on the local machine, port 25. Fetchmail's problem is
that Exim isn't configured to run as a server, so it has no idea what to
do with the mail it's fetching. You need to either configure Exim to
listen on port 25, or configure Fetchmail to deliver to a program such
as procmail; the second option is probably better all round, unless
fetchmail is downloading mail for more than one local user.
Ben
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
