Bug#697612: exim4-daemon-light: "MAIN_LOCAL_DOMAINS=@:localhost" seems not to respect "@"

Diego Guella diego.guella at deviltechnologies.com
Mon Apr 28 08:15:45 UTC 2014


Hi Marc,

This is getting even more strange.
In short: the wrong behaviour disappeared, and it seems I'm not able to 
reproduce the bug anymore.
I left the office after my last email, and come back this morning.
Follows detailed explanation.

From: "Marc Haber"
>I am kind of out of ideas now. Can you dump the output of echo foo |
> /usr/sbin/exim -d root at devil... here after looking for private data in
> the debug output?

I am still running with Osamu Aoki's workaround 
(dc_other_hostnames='devilserver.deviltechnologies.com' in 
update-exim4.conf.conf).
[WORKAROUND ON]

I executed the command, dumped the output and received the email message.
The details are in "tests_with-workaround.tbz", attached.


So I removed the workaround, executed update-exim4.conf, restarted exim, and 
executed echo bar | /usr/sbin/exim -d root at devil....

The details are in "tests_without-workaround.tbz", attached.
To my surprise, now all is working as expected! The message does not get 
sent to the smarthost.

root at devilserver:/etc/exim4# exim -v -bt 
root at devilserver.deviltechnologies.com
-----
R: system_aliases for root at devilserver.deviltechnologies.com
R: system_aliases for dguella at devilserver.deviltechnologies.com
R: userforward for dguella at devilserver.deviltechnologies.com
R: procmail for dguella at devilserver.deviltechnologies.com
dguella at devilserver.deviltechnologies.com
    <-- root at devilserver.deviltechnologies.com
  router = procmail, transport = procmail_pipe
-----

So, I looked around and found that the router rebooted itself during the 
weekend.
I started thinking of a DNS issue, so I tried to reproduce by generating a 
DNS problem in the network:

-----
root at devilserver:/etc/bind# service bind9 stop
Stopping domain name service...: bind9 waiting for pid 1437 to die.
root at devilserver:/etc/bind# dig devilserver.deviltechnologies.com

; <<>> DiG 9.7.3 <<>> devilserver.deviltechnologies.com
;; global options: +cmd
;; connection timed out; no servers could be reached
root at devilserver:/etc/bind# exim -v -bt 
root at devilserver.deviltechnologies.com
R: system_aliases for root at devilserver.deviltechnologies.com
R: system_aliases for dguella at devilserver.deviltechnologies.com
R: userforward for dguella at devilserver.deviltechnologies.com
R: procmail for dguella at devilserver.deviltechnologies.com
dguella at devilserver.deviltechnologies.com
    <-- root at devilserver.deviltechnologies.com
  router = procmail, transport = procmail_pipe
root at devilserver:/etc/bind# service exim4 stop
Stopping MTA: exim4_listener.
root at devilserver:/etc/bind# service exim4 start
Starting MTA: exim4.
root at devilserver:/etc/bind# exim -v -bt 
root at devilserver.deviltechnologies.com
R: system_aliases for root at devilserver.deviltechnologies.com
R: system_aliases for dguella at devilserver.deviltechnologies.com
R: userforward for dguella at devilserver.deviltechnologies.com
R: procmail for dguella at devilserver.deviltechnologies.com
dguella at devilserver.deviltechnologies.com
    <-- root at devilserver.deviltechnologies.com
  router = procmail, transport = procmail_pipe
root at devilserver:/etc/bind#

-----

??? It seems exim does not try to forward the mail to the smarthost, even 
without a DNS reply!!

Now, I purposefully misconfigured the local DNS server (bind).
It is in forward-only configuration; all the requests are forwarded to the 
router.
I entered a wrong IP address in /etc/bind/named.conf.options, then started 
bind:

-----
root at devilserver:/etc/bind# service bind9 start
Starting domain name service...: bind9.
root at devilserver:/etc/bind# dig devilserver.deviltechnologies.com

; <<>> DiG 9.7.3 <<>> devilserver.deviltechnologies.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39461
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;devilserver.deviltechnologies.com. IN  A

;; ANSWER SECTION:
devilserver.deviltechnologies.com. 86400 IN A   192.168.200.249

;; AUTHORITY SECTION:
devilserver.deviltechnologies.com. 86400 IN NS 
devilserver.deviltechnologies.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 28 09:37:53 2014
;; MSG SIZE  rcvd: 81

root at devilserver:/etc/bind# exim -v -bt 
root at devilserver.deviltechnologies.com
R: system_aliases for root at devilserver.deviltechnologies.com
R: system_aliases for dguella at devilserver.deviltechnologies.com
R: userforward for dguella at devilserver.deviltechnologies.com
R: procmail for dguella at devilserver.deviltechnologies.com
dguella at devilserver.deviltechnologies.com
    <-- root at devilserver.deviltechnologies.com
  router = procmail, transport = procmail_pipe
root at devilserver:/etc/bind#

-----

Still, working as expected.

I am now running with a correct DNS server configuration, and with a correct 
exim configuration (the same that worked since some years).
Now I'm out of ideas, too.


>
> Greetings
> Marc
>

Thanks,
Diego
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tests_without-workaround.tbz
Type: application/octet-stream
Size: 3855 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-exim4-maintainers/attachments/20140428/0dee5889/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tests_with-workaround.tbz
Type: application/octet-stream
Size: 3846 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-exim4-maintainers/attachments/20140428/0dee5889/attachment-0001.obj>


More information about the Pkg-exim4-maintainers mailing list