Re: [Exim] address_file transport acting quite odd...

On 2000-08-26 at 03:16 -0700, Trevor Sky Garside gifted us with:
> set_process_info: 26170 3.16 delivering 13ScoX-0006o4-00 to
> /var/mail/spool/trevor using address_file
> appendfile transport entered
> appendfile: mode=600 notify_comsat=0 quota=0
> file=/var/mail/spool/trevor format=unix
> prefix=From ${if def:return_path{$return_path}{MAILER-DAEMON}}
> ${tod_bsdinbox}\n
> suffix=\n
> locking by lockfile fcntl
> address_file transport: /var/mail/spool
> address_file transport returned DEFER
> added retry item for T:/var/mail/spool/trevor@???: errno=13 0
> flags=0
> post-process /var/mail/spool/trevor (2)
> LOG: 0 MAIN
> == /var/mail/spool/trevor <trevor@???> T=address_file defer
> (13): Permission denied: failed to create directories for /var/mail/spool:
> Permission denied

> Again, I apologize for sending all of this debug info, but I think I
> stripped out most of the extra stuff. Please, can someone explain to me why
> it's trying to create a directory, and what directory that might be?

Does "/var/mail/spool/" exist? Usually, it's "/var/spool/mail/" or
"/var/mail/", or even "/usr/spool/mail/" on old systems.

If "/var/mail/spool/" really does exist, what are the permissions on it?
Does "trevor" already exist in that directory?

> address_file:
> uid=505 gid=12 home=NULL current=/

Does that uid/gid have permission to create new files in the system mail
directory? Ie, if you manually create 'trevor' with the correct
permissions, does it all work, but not until then?

The 'correct' permissions for the system mail directory and the mails
themselves is somewhat of a religious issue, and to an extent depends
upon what software needs to access the files and if there are normal
user logons on the box in question.
--
"We've got a patent on the conquering of a country through the use of force.
We believe in world peace through extortionate license fees." -Bluemeat