Exim stopped delivering mail to external DA host

[Maikel]

Hello all,

Recently exim has stopped delivering email to a different DA host which I use for email. The situation came to notice when contact form mail didn't arrive at the mail accounts for a website which is hosted on the server in question, and has corresponding mail accounts (same domain) on the other server. It apparently happened for a while already, so I can't precisely
say what could have caused it. I suspect it might have to do with a "custombuild build all".

The exim config file looked normal, but to be sure, I rebuilt the config and added a few lines that allow the "envelope from" to be the sending domain. Nothing different from what I was used to and how it has worked for years. It didn't help unfortunately. Here are a few lines from the mainlog:

2014-09-18 21:00:21 cwd=/home/test5/domains/exampledomain.com/public_html 5 args: /usr/sbin/sendmail -t -i -f [email protected]
2014-09-18 21:00:21 1XUgwH-0003fV-Kw <= [email protected] U=test5 P=local S=451 T="Testmail" from <[email protected]> for [email protected]
2014-09-18 21:00:21 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1XUgwH-0003fV-Kw
2014-09-18 21:00:21 1XUgwH-0003fV-Kw lowest numbered MX record points to local host: exampledomain.com
2014-09-18 21:00:21 1XUgwH-0003fV-Kw == [email protected] R=lookuphost defer (-1): lowest numbered MX record points to local host
2014-09-18 21:00:21 1XUgwH-0003fV-Kw Frozen

It happened to me before, when I first started using DA (my first system administration in general) and I fixed it by switching off the "use local mailserver" in the MX settings. Later on I applied this fix: http://help.directadmin.com/item.php?id=238, but without the last lines about the mx template, must have overlooked those, but it worked.

/etc/virtual/domains is looking normal, only the DA host name in there. Also all other mail with domains hosted on this server is delivered properly, with the difference that the accounts are not hosted on the remote DA mail host. Besides mail from this server, the mail accounts are also working properly; no problems with sending and receiving in general.

All of the DNS is served by the domain registrants, so local DNS service within DA is unused. To be sure, I added mx records (even with priority 0) on the server for the domains in question, that point to the remote mail host. Still no luck. Below is the output of "exim -bt -d+resolver [email protected]", in which the server is server4.maindomain.com, the remote mail host vds.extradomain.com and exampledomain.com is a domain hosted on this server.

Ip addresses xxxx:xxxx:2000:55::3 and xxx.xxx.182.18 are the ip's of vds.extradomain.com, so it looks like exim found the right place to deliver mail, but then without any further explanation, it falls back to localhost.

Exim version 4.83 uid=0 gid=0 pid=12957 D=fbf95cfd
Berkeley DB: Berkeley DB 4.7.25: (September 12, 2013)
Support for: crypteq IPv6 Perl OpenSSL move_frozen_messages Content_Scanning DKIM Old_Demime PRDR OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Compiler: GCC [4.4.7 20120313 (Red Hat 4.4.7-4)]
Library version: OpenSSL: Compile: OpenSSL 1.0.1e-fips 11 Feb 2013
                          Runtime: OpenSSL 1.0.1e-fips 11 Feb 2013
                                 : built on: Thu Jun  5 12:55:18 UTC 2014
Library version: Cyrus SASL: Compile: 2.1.23
                             Runtime: 2.1.23 [Cyrus SASL]
Library version: PCRE: Compile: 8.20
                       Runtime: 8.20 2011-10-21
Total 8 lookups
WHITELIST_D_MACROS unset
TRUSTED_CONFIG_LIST unset
changed uid/gid: forcing real = effective
  uid=0 gid=0 pid=12957
  auxiliary group list: <none>
seeking password data for user "root": cache not available
getpwnam() succeeded uid=0 gid=0
seeking password data for user "mail": cache not available
getpwnam() succeeded uid=8 gid=12
seeking password data for user "majordomo": cache not available
getpwnam() succeeded uid=495 gid=2
seeking password data for user "apache": cache not available
getpwnam() succeeded uid=498 gid=500
seeking password data for user "diradmin": cache not available
getpwnam() succeeded uid=497 gid=497
changed uid/gid: calling tls_validate_require_cipher
  uid=8 gid=12 pid=12958
  auxiliary group list: <none>
tls_require_ciphers expands to "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP"
tls_validate_require_cipher child 12958 ended: status=0x0
configuration file is /etc/exim.conf
log selectors = 000024ac 002b980b
trusted user
admin user
seeking password data for user "majordomo": cache not available
getpwnam() succeeded uid=495 gid=2
seeking password data for user "majordomo": using cached result
getpwnam() succeeded uid=495 gid=2
seeking password data for user "mail": cache not available
getpwnam() succeeded uid=8 gid=12
seeking password data for user "majordomo": cache not available
getpwnam() succeeded uid=495 gid=2
seeking password data for user "mail": cache not available
getpwnam() succeeded uid=8 gid=12
seeking password data for user "mail": using cached result
getpwnam() succeeded uid=8 gid=12
originator: uid=0 gid=0 login=root name=root
sender address = [email protected]
Address testing: uid=0 gid=12 euid=0 egid=12
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Testing [email protected]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Considering [email protected]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
routing [email protected]
--------> lookuphost router <--------
local_part=test domain=exampledomain.com
checking domains
search_open: lsearch "/etc/virtual/domains"
search_find: file="/etc/virtual/domains"
  key="exampledomain.com" partial=-1 affix=NULL starflags=0
LRU list:
  5/etc/virtual/domains
  End
internal_search_find: file="/etc/virtual/domains"
  type=lsearch key="exampledomain.com"
file lookup required for exampledomain.com
  in /etc/virtual/domains
lookup failed
exampledomain.com in "lsearch;/etc/virtual/domains"? no (end of list)
exampledomain.com in "! +local_domains"? yes (end of list)
checking "condition"
Starting Perl interpreter
calling lookuphost router
lookuphost router called for [email protected]
  domain = exampledomain.com
DNS lookup of exampledomain.com (MX) succeeded
DNS lookup of vds.extradomain.com (AAAA) succeeded
xxxx:xxxx:2000:55::3 in "127.0.0.0/8"? no (end of list)
DNS lookup of vds.extradomain.com (A) succeeded
xxx.xxx.182.18 in "127.0.0.0/8"? no (end of list)
local host has lowest MX
fully qualified name = exampledomain.com
host_find_bydns yield = HOST_FOUND_LOCAL (3); returned hosts:
  vds.extradomain.com xxxx:xxxx:2000:55::3 MX=1 
  vds.extradomain.com xxx.xxx.182.18 MX=1 
LOG: MAIN
  lowest numbered MX record points to local host: exampledomain.com (while routing <[email protected]>)
lookuphost router: defer for [email protected]
  message: lowest numbered MX record points to local host
search_tidyup called
>>>>>>>>>>>>>>>> Exim pid=12957 terminating with rc=1 >>>>>>>>>>>>>>>>
[email protected] cannot be resolved at this time: lowest numbered MX record points to local host

Unfortunately, I haven't figured out how I can debug this any further. One theory that comes to mind is that the mail server has blocked incoming mail from this server, but it doesn't show in the log/output and I don't know yet what debugging command I could use on exim to confirm/exclude this. A faster way might be to look on the mail server if indeed something is blocked, but I don't know where to look either.

So any help is welcome. Directions for further debugging, or tips on something obvious I have missed.

Thanks

 

[nobaloney]

Because you don't give real DNS information and domain names it's impossible to give you further information than this:

Did you see this error in your logs:

lowest numbered MX record points to local host: exampledomain.com

This means that (a) the recipient domain name is NOT in /etc/virtual/domains. This is correct, as it should not be.

And it also means:

That the lowest value MX record in the zone file for the domain is pointing to the origination server, which tells exim that the domain should be listed in /etc/virtual/domains, and that this server should be accepting the email.

So there's no place for the email to go.

For further troubleshooting help, post the correct domain name and the main IP#s of both servers. If you feel uncomfortable doing this, then read this first:

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dont-obscure-your-dns-data.html

If you're still not comfortable posting non-obscured information, then do the rest of the troubleshooting yourself .

Jeff

 

[Maikel]

Thanks for your response Jeff!

I realized that obscured data is harder to work with, but was hoping for some tips or debugging commands based on the info given.

Before I would consider posting the non-obscured data, I tried to "refresh" some things, do updates, walk through settings and rebuild exim. Luckily that did the trick, so no further help is needed.

Further: while I'm a strong believer of "security through obscurity is no security", I would like to point out why I don't totally agree with the article you posted. Take the Heartbleed bug for example. If this threat was started before the public announcement (who knows how many hackers were aware of it even before the announcement?), people could have just found my vulnerable (based on build date) server with a Google search. So obscuring is not completely useless.

 

[nobaloney]

Obscuring it isn't completely useless, but what it does is prevents us from testing posted declarations. Searching through these forums you'll see that many times inexperienced users make and post wrong suppositions, which are quickly resolved with a bit of external testing.

This is a self help forum, and many of us who help have many other projects, jobs, etc., and would rather laser in on a fix than makes guesses and suppositions and write about alternate possibilities.

I'm glad you got it fixed.

Jeff