We're seeing a strange issue with some mailing-lists which are handled
internally by Exim. Sometimes, mails aren't having their envelope
sender changed by errors_to. In all cases, I think that it's when the
mail delivery is delayed.
The issue is observed with Exim 3.34, but now that I know what seems to
be happening, I can confirm that it's been going on for much longer.
Unfortunately, this data is sanitised; sorry. But that's the domain,
the recipient, the hostnames and IPs. The rest is as-is. Uhm, that
does leave a "the rest". :^)
The Director handling this list (and others) has this on it:
errors_to = ${local_part}-request@???
Now, with delivery to a machine in the UK, we're seeing that this isn't
always happening. Also, if my workstation has been rebooted and there
are mails queued up, they hit my normal inbox; I have procmail filtering
on "* ^From listname-request@nl\.example\.net", to divert them into
mailboxes. So, with hindsight, this has been happening for a couple of
years. (And here I've been mentally blaming procmail when under load).
UK machine, also running Exim, logged:
-----------------------------< cut here >-------------------------------
2002-03-27 05:47:39 16q6Ha-0007Pj-00
<= listname@???
H=mailhub.mail.nl.example.net [192.0.2.197]
P=esmtp S=993
id=E16q65x-000LEM-00@???
-----------------------------< cut here >-------------------------------
I received this same message, in my inbox locally, on time, with:
Return-path: <listname-request@???>
Envelope-to: pdp@???
The NL mailhub logs show that the UK machine received the mail later
than the others, but nothing else special; in particular, no deferred
entry ("fgrep 16q65y-00041C-00 /var/log/exim/mainlog"):
-----------------------------< cut here >-------------------------------
2002-03-27 06:35:38 16q65y-00041C-00
<= listname@???
H=originatinghost.foo.nl.example.net [192.0.2.211]
P=esmtp S=788
id=E16q65x-000LEM-00@???
from <listname@???>
for listname@???
2002-03-27 06:35:38 16q65y-00041C-00
=> someone@???
<listname@???>
R=example T=remote_smtp
H=originatinghost.foo.nl.example.net [192.0.2.211]
C="250 OK id=16q65y-000LEO-00"
[..... other recipients ....]
2002-03-27 06:35:38 16q65y-00041C-00
=> pdp@???
<listname@???>
R=lookuphost T=remote_smtp
H=workstation.noc.nl.example.net [192.0.2.214]
C="250 OK id=16q65y-0000r7-00"
[..... someone else .....]
2002-03-27 06:47:27 16q65y-00041C-00
=> listname-dist@???
<listname@???>
R=lookuphost T=remote_smtp
H=ukhost.bar.example.net [a.b.c.d]*
C="250 OK id=16q6Ha-0007Pj-00"
2002-03-27 06:47:27 16q65y-00041C-00 Completed
-----------------------------< cut here >-------------------------------
I can find no reference in spec.txt to this. I don't _think_ this
counts as "pathological input data", so it doesn't look like something
listed in ChangeLog as fixed in 3.35.
I also can't see a reference to what the '*' after the IP address means,
in that second-to-last log entry. The source shows that
continue_sequence was greater than 1. Whatever that means. Hopefully
not the bit of code commented "shouldn't currently happen" ...
The 12 minute delay is also slightly strange, given that the daemon runs
"-bd -q10m"; there shouldn't have been that much stuff filling the
queue, to push things out past (10 mins - first offset) delay.
Help? Bug? What's happening?
--
People do not like to think. If one thinks, one must reach conclusions.
Conclusions are not always pleasant. -- Helen Keller
