On Tue, Apr 28, 2020 at 11:38:04AM +0100, Jeremy Harris via Exim-users wrote: > On 28/04/2020 11:17, Andrew C Aitchison via Exim-users wrote: > > > > On 27/04/2020 20:52, Russell King via Exim-users wrote: > >> 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf <= [email protected] > > U=patchd P=local S=1535 > >> 2020-04-27 20:36:15 1jT9Y7-0003B4-Mf H=pandora.armlinux.org.uk > > [xxxx:xxxx:xxxx:xxxx:214:fdff:fe10:1be6] Permission denied > >> 2020-04-27 20:36:17 1jT9Y7-0003B4-Mf => [email protected] R=smart_route > > T=remote_smtp H=pandora.armlinux.org.uk > > [xxxx:xxxx:xxxx:xxxx:214:fdff:fe10:1be6] > > X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes A=fixed_cram C="250 OK > > id=1jT9Y8-0004ff-Qf" > >> > >> My guess is that there is some file that exim can't access while > >> attempting to send to pandora, but I think working out what is > >> going to be very hard (I guess debug isn't allowed from non-root > >> users?) > > > > ... and followed up with: > >> and grepping the strace output for errors: > >> > >> 19841 openat(AT_FDCWD, "/var/spool/exim4//input//1jTM7j-0005A1-Na-D", > >> O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0640) = -1 EACCES (Permission denied) > > On today's non-Unix "selinux" systems, you need to also worry > about the mostly-invisible marks placed on files... Turning selinux > to "permissive" may be a useful and quick test.
True, but not applicable in my situation; the host is not using selinux. In any case, I've fixed the firewall, and now that address no longer gives EACCES. Thanks for the pointer. -- Russell King -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
