Hi Jeremy,
I notice you set a Reply-to: header on your messages, were you
expecting me to reply to that address, or to the list? I've
chosen the list.
On Tue, Apr 28, 2020 at 10:23:56AM +0100, Jeremy Harris via Exim-users wrote:
> On 28/04/2020 08:12, Russell King via Exim-users wrote:
> > On Mon, Apr 27, 2020 at 09:11:18PM +0100, Jeremy Harris via Exim-users wrote:
> >> On 27/04/2020 20:52, Russell King via Exim-users wrote:
> >>> I'm running debian stable on my machines, and I've noticed that when
> >>> one of my scripts sends email,
> >>
> >> I'm hoping that means you can trigger it on demsnd?
> >
> > I believe so - exim is being called from a perl script running as the
> > user stated in the log line thusly:
> >
> > /usr/sbin/sendmail -oi -t
>
> Ah. I was assuming the message came to the daemon using SMTP.
>
> So, to handle a commandline message with debug
> add near the top of your nonsmtp-data acl
>
> warn control = debug/opts=+all
Thanks, I put it in the acl_not_smtp_start ACL instead, which seems to
have worked as far as getting a debug log. However, I have some bad
news.
I've spent quite some time trying to track it down - what I can say
is that it isn't a file permission problem, but a network-induced
issue. (I now have a mailbox full of a hundred or so test messages
to delete!)
As I mentioned, there are several IPv6 addresses for pandora - and it
seems I haven't permitted them all in the firewall rules facing the
DMZ. When exim chooses to use one of the addresses that results in
the 'REJECT' rule being hit on the firewall, the machine running exim
gives a "Permission denied" errno. I can trigger this via:
# telnet xxxx:xxxx:xxxx:xxxx:214:fdff:fe10:1be6 25
...
telnet: Unable to connect to remote host: Permission denied
Note: the firewall and the machine running exim are two entirely
separate machines; they are not on the same machine. So, this
error can be induced remotely.
It would be obvious if it was something like:
H=foobar.example.org [10.0.0.1] Connection refused
but when it's:
H=foobar.example.org [10.0.0.1] Permission denied
it's rather confusing exactly what is going on and where that error
is coming from.
Besides the problems of getting any debug out of it (I think the way
you suggested above is the only way to do it), there's another issue
as well - the retry database stops exim using those addresses, which
means that the more attempts are made, the more exim refrains from
triggering the error with larger and larger intervals.
So, this has been a particularly nasty and difficult problem to track
down. It's probably worth documenting the error message somewhere
that people will find it, and listing firewall issues as a potential
cause of it.
--
Russell King
