Jaap Winius wrote:
Quoting W B Hacker <[email protected]>:
But you said..
After adding the new domain name...
Sorry for the confusion. I had configured the DNS properly several weeks
*snip*
All I did was add the 'new' domain to the mail server's configuration,
so that it would consider itself the final destination for that domain,
as well as make it the new 'system mail name' (to 'qualify' mail
addresses without a domain name).
Ah - Ok . Clear now - and that would also imply a restart of the Exim
listener daemon to have effected the reload.
Also rules out stray child process, IMNSHO.
From extensive log observations , any given child process often
accomplishes its mission and exits in sub-one-second to 2 seconds,
rarely lives longer than a few minutes, so I'd rule those out.
Were arp tables flushed?
Not necessary, since the IP addresses and DNS records (incl. the MX)
have been stable for weeks.
For http/https 'service' on IP:80 IP:443 for that IP, yes.
For port 25 et al? Still newish information, but ACK, 'should' not have
mattere so long as no *conflicting* player had been registered.
End of the day, *unless* you made a subsequent set of changes that did
soemthing overlooked, I'm still not seeing any causal factor as likely
as that of DNS propagation *combined with* delay for remote MTA flushing
of local cache. If any. Exim has such, but not all other MTA do.
Regardless - solved for now?
Out of curiosity, am also sending you a direct copy to see if the way MY
server handles callouts is compatible. Taken as a given that you may
have different config on the server you are using yourself than on the
one under discussion...
Regards,
Bill
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
