On 6 Sep 2013, at 17:35, Max Bowsher <_@maxb.eu> wrote:
> I called it that because that's the word the Exim source code uses to
> describe what it is doing. If you look in src/routers/dnslookup.c in the
> block which calls rf_change_domain(...), both comments and result
> constants use the word "rerouted".
We need to be *absolutely certain* that we're not confusing things here.
Re-routing as a result of a DNS lookup is not the same as rewriting headers in a message that's in flight. The former is expected; the latter is done when Exim is told to by a rewrite rule. What we have here is a re-routing, not rewriting, issue.
> I understand that config is key to many problems, but in this case, the
> only relevant point is having a dnslookup router configured in the
> approximate manner than any internet-connected host does.
Good, so now we have something to work with - although the "approximate" bit there could be problematic. We'll see. Now we know what you're doing, we can diagnose or further analyse the problem.
> The problem can be reproduced just using the "exim -bt" address testing
> mode. Please run "exim -bt nonesuch@???". The
> behaviour I have described results in Exim clearly showing the address
> rewrite as follows:
>
> nonesuch@www.bcidahofoundation.com
> <-- nonesuch@???
> router = dnslookup, transport = remote_smtp
> host mail2.bcidaho.com [207.170.246.155] MX=10
> host mail1.bcidaho.com [207.170.246.146] MX=10
>
> You can see that the domain has incorrectly been changed to
> @www.bcidahofoundation.com - the correct behaviour would not include any
> "<--" address change lines.
The domain *has not* been incorrectly changed. This is expected behaviour - and it's all down to the DNS for that domain. The output there is showing you where it needs to deliver to. To demonstrate, at work all of our email maps several domains down onto one, which subsequently gets delivered to an internal Exchange server.
[root@mta-1 ~]# exim -bt g.e.fowler@???
Address rewritten as: g.e.fowler@???
<username redacted>@lunet.lboro.ac.uk
<-- g.e.fowler@???
router = bypass_mx_record, transport = remote_smtp
host email.lunet.lboro.ac.uk [158.125.167.4]
The "Address rewritten" line there is an actual *rewrite*. The difference between the target address and the delivery address simply shows where the email is destined for - g.e.fowler@??? is rewritten (in all header lines, including envelope) to g.e.fowler@??? as that's my canonical email address; it's then delivered to my Exchange mailbox in our internal domain.
To use another example, here's my postmaster address using a hostname rather than domain:
[graeme@boom ~]$ /usr/sbin/exim -bt postmaster@???
graeme@???
<-- graeme@???
<-- root@???
<-- postmaster@???
router = local_maildir_user, transport = local_maildir_delivery
In your case, something in the DNS means that to deliver email to the nonesuch@???, it needs to go to
www.bcifoundation.com.
Let's have a look:
graeme@boom ~]$ dig bcidahofoundation.org any
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> bcidahofoundation.org any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18664
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;bcidahofoundation.org. IN ANY
;; ANSWER SECTION:
bcidahofoundation.org. 900 IN CNAME www.bcidahofoundation.com.
bcidahofoundation.org. 85677 IN NS ns1.hover.com.
bcidahofoundation.org. 85677 IN NS ns2.hover.com.
;; AUTHORITY SECTION:
bcidahofoundation.org. 85677 IN NS ns2.hover.com.
bcidahofoundation.org. 85677 IN NS ns1.hover.com.
***Interesting bit here*** bcidahofoundation.org has no MX records, having only a CNAME at the zone apex which goes to... ta-da! The explicit hostname of
www.bcidahofoundation.com.
So nonesuch@??? gets internally rewritten in the envelope to deliver to
nonesuch@www.bcidahofoundation.com.
If you had MX records in the .org zone then you wouldn't see this - although you can't have a CNAME and other data such as MX records at the zone apex, so you'd need to fiddle with your zone a bit to correct that.
An alternative approach is to make it a CNAME to bcidahofoundation.com, which has an explicit A record and MX records.
No bug. Perfectly normal behaviour.
Graeme
