On 6 Sep 2013, at 17:35, Max Bowsher <[email protected]> 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 [email protected]". The > behaviour I have described results in Exim clearly showing the address > rewrite as follows: > > [email protected] > <-- [email protected] > 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 [email protected] Address rewritten as: [email protected] <username redacted>@lunet.lboro.ac.uk <-- [email protected] 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 - [email protected] is rewritten (in all header lines, including envelope) to [email protected] 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 [email protected] [email protected] <-- [email protected] <-- [email protected] <-- [email protected] router = local_maildir_user, transport = local_maildir_delivery In your case, something in the DNS means that to deliver email to the [email protected], 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 [email protected] gets internally rewritten in the envelope to deliver to [email protected]. 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
