Exim does not use /etc/hosts











up vote
1
down vote

favorite












I have installed exim4, and my /etc/hosts file looks like this:



127.0.0.1     localhost
127.0.1.1 mycomputer
192.168.100.5 rpi.mydomain.com


When I run exim -bt john@rpi.mydomain.com to test deliverability, it says:



R: dnslookup for john@rpi.mydomain.com
john@rpi.mydomain.com is undeliverable


Why doesn't it use the /etc/hosts file?



Additional information:




  • System: Ubuntu.

  • The address in the /etc/hosts file is valid. I verified this using telnet rpi.mydomain.com 25.


/etc/nsswitch.conf:



passwd:         compat systemd
group: compat systemd
shadow: compat
gshadow: files

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis









share|improve this question
























  • What distro are you on?
    – Michael Prokopec
    Nov 26 at 5:09












  • @MichaelProkopec Ubuntu.
    – Flux
    Nov 26 at 5:17










  • What does your /etc/nsswitch.conf look like?
    – Michael Prokopec
    Nov 26 at 5:18










  • @MichaelProkopec Added contents of /etc/nsswitch.conf to the question.
    – Flux
    Nov 26 at 5:29












  • Do you have a firewall between you and the host, or on your client computer?
    – Michael Prokopec
    Nov 26 at 5:35















up vote
1
down vote

favorite












I have installed exim4, and my /etc/hosts file looks like this:



127.0.0.1     localhost
127.0.1.1 mycomputer
192.168.100.5 rpi.mydomain.com


When I run exim -bt john@rpi.mydomain.com to test deliverability, it says:



R: dnslookup for john@rpi.mydomain.com
john@rpi.mydomain.com is undeliverable


Why doesn't it use the /etc/hosts file?



Additional information:




  • System: Ubuntu.

  • The address in the /etc/hosts file is valid. I verified this using telnet rpi.mydomain.com 25.


/etc/nsswitch.conf:



passwd:         compat systemd
group: compat systemd
shadow: compat
gshadow: files

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis









share|improve this question
























  • What distro are you on?
    – Michael Prokopec
    Nov 26 at 5:09












  • @MichaelProkopec Ubuntu.
    – Flux
    Nov 26 at 5:17










  • What does your /etc/nsswitch.conf look like?
    – Michael Prokopec
    Nov 26 at 5:18










  • @MichaelProkopec Added contents of /etc/nsswitch.conf to the question.
    – Flux
    Nov 26 at 5:29












  • Do you have a firewall between you and the host, or on your client computer?
    – Michael Prokopec
    Nov 26 at 5:35













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I have installed exim4, and my /etc/hosts file looks like this:



127.0.0.1     localhost
127.0.1.1 mycomputer
192.168.100.5 rpi.mydomain.com


When I run exim -bt john@rpi.mydomain.com to test deliverability, it says:



R: dnslookup for john@rpi.mydomain.com
john@rpi.mydomain.com is undeliverable


Why doesn't it use the /etc/hosts file?



Additional information:




  • System: Ubuntu.

  • The address in the /etc/hosts file is valid. I verified this using telnet rpi.mydomain.com 25.


/etc/nsswitch.conf:



passwd:         compat systemd
group: compat systemd
shadow: compat
gshadow: files

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis









share|improve this question















I have installed exim4, and my /etc/hosts file looks like this:



127.0.0.1     localhost
127.0.1.1 mycomputer
192.168.100.5 rpi.mydomain.com


When I run exim -bt john@rpi.mydomain.com to test deliverability, it says:



R: dnslookup for john@rpi.mydomain.com
john@rpi.mydomain.com is undeliverable


Why doesn't it use the /etc/hosts file?



Additional information:




  • System: Ubuntu.

  • The address in the /etc/hosts file is valid. I verified this using telnet rpi.mydomain.com 25.


/etc/nsswitch.conf:



passwd:         compat systemd
group: compat systemd
shadow: compat
gshadow: files

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis






ubuntu exim






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 26 at 7:51









Rui F Ribeiro

38.3k1475127




38.3k1475127










asked Nov 26 at 4:42









Flux

221110




221110












  • What distro are you on?
    – Michael Prokopec
    Nov 26 at 5:09












  • @MichaelProkopec Ubuntu.
    – Flux
    Nov 26 at 5:17










  • What does your /etc/nsswitch.conf look like?
    – Michael Prokopec
    Nov 26 at 5:18










  • @MichaelProkopec Added contents of /etc/nsswitch.conf to the question.
    – Flux
    Nov 26 at 5:29












  • Do you have a firewall between you and the host, or on your client computer?
    – Michael Prokopec
    Nov 26 at 5:35


















  • What distro are you on?
    – Michael Prokopec
    Nov 26 at 5:09












  • @MichaelProkopec Ubuntu.
    – Flux
    Nov 26 at 5:17










  • What does your /etc/nsswitch.conf look like?
    – Michael Prokopec
    Nov 26 at 5:18










  • @MichaelProkopec Added contents of /etc/nsswitch.conf to the question.
    – Flux
    Nov 26 at 5:29












  • Do you have a firewall between you and the host, or on your client computer?
    – Michael Prokopec
    Nov 26 at 5:35
















What distro are you on?
– Michael Prokopec
Nov 26 at 5:09






What distro are you on?
– Michael Prokopec
Nov 26 at 5:09














@MichaelProkopec Ubuntu.
– Flux
Nov 26 at 5:17




@MichaelProkopec Ubuntu.
– Flux
Nov 26 at 5:17












What does your /etc/nsswitch.conf look like?
– Michael Prokopec
Nov 26 at 5:18




What does your /etc/nsswitch.conf look like?
– Michael Prokopec
Nov 26 at 5:18












@MichaelProkopec Added contents of /etc/nsswitch.conf to the question.
– Flux
Nov 26 at 5:29






@MichaelProkopec Added contents of /etc/nsswitch.conf to the question.
– Flux
Nov 26 at 5:29














Do you have a firewall between you and the host, or on your client computer?
– Michael Prokopec
Nov 26 at 5:35




Do you have a firewall between you and the host, or on your client computer?
– Michael Prokopec
Nov 26 at 5:35










1 Answer
1






active

oldest

votes

















up vote
1
down vote













Please see this part of Exim documentation.



In short, email delivery relies pretty heavily on MX records of the DNS system, and there is no equivalent for them in /etc/hosts.



Apparently Exim's test feature first takes into account whether Exim is configured to use a smarthost or not; if it has, it would report the address(es) of the smarthost it knows about. (Smarthost configuration = old sendmail-based email terminology meaning "don't attempt to deliver directly to destination address - instead, send all outgoing email to one specific server for further processing.")



If no smarthost configuration is in use, the test checks for the presence of a DNS MX record for rpi.mydomain.com. If the MX record is of the following form, it is interpreted to mean explicitly "no email service for this domain" and the search ends:



rpi.mydomain.com. IN MX 0 .


If there is no MX record in DNS and rpi.mydomain.com is listed in Exim configuration item mx_domains, the search will also end with a "mail is undeliverable" error.



If the above did not already terminate the search, Exim will check for A or AAAA records in the DNS.



In your own network, if you wish to use rpi.mydomain.com as your mail server, you should configure your local Exim to use it as a smarthost. Here's the relevant bit of Exim documentation. In short, replace the default dnslookup mail router configuration block with this Exim configuration block:



send_to_smart_host:
driver = manualroute
route_list = !+local_domains rpi.mydomain.com
transport = remote_smtp


This should cause all mail whose destination is not the local inbox /var/mail/<username> to be sent to rpi.mydomain.com for further processing.



Well-behaving mail servers have long been expected to have a valid DNS registration, and also a valid reverse DNS registration that is in agreement with the forward DNS record.



Generally, when a mail server receives an incoming connection that is not authenticated and does not come from a known-trusted network, the mail server will typically first make a reverse DNS lookup to find out the name of the system trying to connect. Then it makes a forward DNS lookup using that name, and compares the resulting IP address(es) to the actual source IP of the connection. If there is no match, or there is no reverse DNS record, the connection is assumed to come from a possible spammer and can be subjected to stricter checks or outright disconnected. This is one of the oldest anti-spam checks.






share|improve this answer





















  • The answer is quite good, I think you could mention the possibility of adding some DNS dual view setup to complete it. +1
    – Rui F Ribeiro
    Nov 26 at 11:03








  • 1




    @RuiFRibeiro: feel free to edit it in. I tried to restrict myself to a description of SMTP's dependency on DNS and practical advice for the asker, and already deleted one chapter's worth of getting sidetracked before posting.
    – telcoM
    Nov 26 at 11:09










  • It is you answer, so I trust your judgement.
    – Rui F Ribeiro
    Nov 26 at 11:10











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484129%2fexim-does-not-use-etc-hosts%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













Please see this part of Exim documentation.



In short, email delivery relies pretty heavily on MX records of the DNS system, and there is no equivalent for them in /etc/hosts.



Apparently Exim's test feature first takes into account whether Exim is configured to use a smarthost or not; if it has, it would report the address(es) of the smarthost it knows about. (Smarthost configuration = old sendmail-based email terminology meaning "don't attempt to deliver directly to destination address - instead, send all outgoing email to one specific server for further processing.")



If no smarthost configuration is in use, the test checks for the presence of a DNS MX record for rpi.mydomain.com. If the MX record is of the following form, it is interpreted to mean explicitly "no email service for this domain" and the search ends:



rpi.mydomain.com. IN MX 0 .


If there is no MX record in DNS and rpi.mydomain.com is listed in Exim configuration item mx_domains, the search will also end with a "mail is undeliverable" error.



If the above did not already terminate the search, Exim will check for A or AAAA records in the DNS.



In your own network, if you wish to use rpi.mydomain.com as your mail server, you should configure your local Exim to use it as a smarthost. Here's the relevant bit of Exim documentation. In short, replace the default dnslookup mail router configuration block with this Exim configuration block:



send_to_smart_host:
driver = manualroute
route_list = !+local_domains rpi.mydomain.com
transport = remote_smtp


This should cause all mail whose destination is not the local inbox /var/mail/<username> to be sent to rpi.mydomain.com for further processing.



Well-behaving mail servers have long been expected to have a valid DNS registration, and also a valid reverse DNS registration that is in agreement with the forward DNS record.



Generally, when a mail server receives an incoming connection that is not authenticated and does not come from a known-trusted network, the mail server will typically first make a reverse DNS lookup to find out the name of the system trying to connect. Then it makes a forward DNS lookup using that name, and compares the resulting IP address(es) to the actual source IP of the connection. If there is no match, or there is no reverse DNS record, the connection is assumed to come from a possible spammer and can be subjected to stricter checks or outright disconnected. This is one of the oldest anti-spam checks.






share|improve this answer





















  • The answer is quite good, I think you could mention the possibility of adding some DNS dual view setup to complete it. +1
    – Rui F Ribeiro
    Nov 26 at 11:03








  • 1




    @RuiFRibeiro: feel free to edit it in. I tried to restrict myself to a description of SMTP's dependency on DNS and practical advice for the asker, and already deleted one chapter's worth of getting sidetracked before posting.
    – telcoM
    Nov 26 at 11:09










  • It is you answer, so I trust your judgement.
    – Rui F Ribeiro
    Nov 26 at 11:10















up vote
1
down vote













Please see this part of Exim documentation.



In short, email delivery relies pretty heavily on MX records of the DNS system, and there is no equivalent for them in /etc/hosts.



Apparently Exim's test feature first takes into account whether Exim is configured to use a smarthost or not; if it has, it would report the address(es) of the smarthost it knows about. (Smarthost configuration = old sendmail-based email terminology meaning "don't attempt to deliver directly to destination address - instead, send all outgoing email to one specific server for further processing.")



If no smarthost configuration is in use, the test checks for the presence of a DNS MX record for rpi.mydomain.com. If the MX record is of the following form, it is interpreted to mean explicitly "no email service for this domain" and the search ends:



rpi.mydomain.com. IN MX 0 .


If there is no MX record in DNS and rpi.mydomain.com is listed in Exim configuration item mx_domains, the search will also end with a "mail is undeliverable" error.



If the above did not already terminate the search, Exim will check for A or AAAA records in the DNS.



In your own network, if you wish to use rpi.mydomain.com as your mail server, you should configure your local Exim to use it as a smarthost. Here's the relevant bit of Exim documentation. In short, replace the default dnslookup mail router configuration block with this Exim configuration block:



send_to_smart_host:
driver = manualroute
route_list = !+local_domains rpi.mydomain.com
transport = remote_smtp


This should cause all mail whose destination is not the local inbox /var/mail/<username> to be sent to rpi.mydomain.com for further processing.



Well-behaving mail servers have long been expected to have a valid DNS registration, and also a valid reverse DNS registration that is in agreement with the forward DNS record.



Generally, when a mail server receives an incoming connection that is not authenticated and does not come from a known-trusted network, the mail server will typically first make a reverse DNS lookup to find out the name of the system trying to connect. Then it makes a forward DNS lookup using that name, and compares the resulting IP address(es) to the actual source IP of the connection. If there is no match, or there is no reverse DNS record, the connection is assumed to come from a possible spammer and can be subjected to stricter checks or outright disconnected. This is one of the oldest anti-spam checks.






share|improve this answer





















  • The answer is quite good, I think you could mention the possibility of adding some DNS dual view setup to complete it. +1
    – Rui F Ribeiro
    Nov 26 at 11:03








  • 1




    @RuiFRibeiro: feel free to edit it in. I tried to restrict myself to a description of SMTP's dependency on DNS and practical advice for the asker, and already deleted one chapter's worth of getting sidetracked before posting.
    – telcoM
    Nov 26 at 11:09










  • It is you answer, so I trust your judgement.
    – Rui F Ribeiro
    Nov 26 at 11:10













up vote
1
down vote










up vote
1
down vote









Please see this part of Exim documentation.



In short, email delivery relies pretty heavily on MX records of the DNS system, and there is no equivalent for them in /etc/hosts.



Apparently Exim's test feature first takes into account whether Exim is configured to use a smarthost or not; if it has, it would report the address(es) of the smarthost it knows about. (Smarthost configuration = old sendmail-based email terminology meaning "don't attempt to deliver directly to destination address - instead, send all outgoing email to one specific server for further processing.")



If no smarthost configuration is in use, the test checks for the presence of a DNS MX record for rpi.mydomain.com. If the MX record is of the following form, it is interpreted to mean explicitly "no email service for this domain" and the search ends:



rpi.mydomain.com. IN MX 0 .


If there is no MX record in DNS and rpi.mydomain.com is listed in Exim configuration item mx_domains, the search will also end with a "mail is undeliverable" error.



If the above did not already terminate the search, Exim will check for A or AAAA records in the DNS.



In your own network, if you wish to use rpi.mydomain.com as your mail server, you should configure your local Exim to use it as a smarthost. Here's the relevant bit of Exim documentation. In short, replace the default dnslookup mail router configuration block with this Exim configuration block:



send_to_smart_host:
driver = manualroute
route_list = !+local_domains rpi.mydomain.com
transport = remote_smtp


This should cause all mail whose destination is not the local inbox /var/mail/<username> to be sent to rpi.mydomain.com for further processing.



Well-behaving mail servers have long been expected to have a valid DNS registration, and also a valid reverse DNS registration that is in agreement with the forward DNS record.



Generally, when a mail server receives an incoming connection that is not authenticated and does not come from a known-trusted network, the mail server will typically first make a reverse DNS lookup to find out the name of the system trying to connect. Then it makes a forward DNS lookup using that name, and compares the resulting IP address(es) to the actual source IP of the connection. If there is no match, or there is no reverse DNS record, the connection is assumed to come from a possible spammer and can be subjected to stricter checks or outright disconnected. This is one of the oldest anti-spam checks.






share|improve this answer












Please see this part of Exim documentation.



In short, email delivery relies pretty heavily on MX records of the DNS system, and there is no equivalent for them in /etc/hosts.



Apparently Exim's test feature first takes into account whether Exim is configured to use a smarthost or not; if it has, it would report the address(es) of the smarthost it knows about. (Smarthost configuration = old sendmail-based email terminology meaning "don't attempt to deliver directly to destination address - instead, send all outgoing email to one specific server for further processing.")



If no smarthost configuration is in use, the test checks for the presence of a DNS MX record for rpi.mydomain.com. If the MX record is of the following form, it is interpreted to mean explicitly "no email service for this domain" and the search ends:



rpi.mydomain.com. IN MX 0 .


If there is no MX record in DNS and rpi.mydomain.com is listed in Exim configuration item mx_domains, the search will also end with a "mail is undeliverable" error.



If the above did not already terminate the search, Exim will check for A or AAAA records in the DNS.



In your own network, if you wish to use rpi.mydomain.com as your mail server, you should configure your local Exim to use it as a smarthost. Here's the relevant bit of Exim documentation. In short, replace the default dnslookup mail router configuration block with this Exim configuration block:



send_to_smart_host:
driver = manualroute
route_list = !+local_domains rpi.mydomain.com
transport = remote_smtp


This should cause all mail whose destination is not the local inbox /var/mail/<username> to be sent to rpi.mydomain.com for further processing.



Well-behaving mail servers have long been expected to have a valid DNS registration, and also a valid reverse DNS registration that is in agreement with the forward DNS record.



Generally, when a mail server receives an incoming connection that is not authenticated and does not come from a known-trusted network, the mail server will typically first make a reverse DNS lookup to find out the name of the system trying to connect. Then it makes a forward DNS lookup using that name, and compares the resulting IP address(es) to the actual source IP of the connection. If there is no match, or there is no reverse DNS record, the connection is assumed to come from a possible spammer and can be subjected to stricter checks or outright disconnected. This is one of the oldest anti-spam checks.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 26 at 10:12









telcoM

14.6k11842




14.6k11842












  • The answer is quite good, I think you could mention the possibility of adding some DNS dual view setup to complete it. +1
    – Rui F Ribeiro
    Nov 26 at 11:03








  • 1




    @RuiFRibeiro: feel free to edit it in. I tried to restrict myself to a description of SMTP's dependency on DNS and practical advice for the asker, and already deleted one chapter's worth of getting sidetracked before posting.
    – telcoM
    Nov 26 at 11:09










  • It is you answer, so I trust your judgement.
    – Rui F Ribeiro
    Nov 26 at 11:10


















  • The answer is quite good, I think you could mention the possibility of adding some DNS dual view setup to complete it. +1
    – Rui F Ribeiro
    Nov 26 at 11:03








  • 1




    @RuiFRibeiro: feel free to edit it in. I tried to restrict myself to a description of SMTP's dependency on DNS and practical advice for the asker, and already deleted one chapter's worth of getting sidetracked before posting.
    – telcoM
    Nov 26 at 11:09










  • It is you answer, so I trust your judgement.
    – Rui F Ribeiro
    Nov 26 at 11:10
















The answer is quite good, I think you could mention the possibility of adding some DNS dual view setup to complete it. +1
– Rui F Ribeiro
Nov 26 at 11:03






The answer is quite good, I think you could mention the possibility of adding some DNS dual view setup to complete it. +1
– Rui F Ribeiro
Nov 26 at 11:03






1




1




@RuiFRibeiro: feel free to edit it in. I tried to restrict myself to a description of SMTP's dependency on DNS and practical advice for the asker, and already deleted one chapter's worth of getting sidetracked before posting.
– telcoM
Nov 26 at 11:09




@RuiFRibeiro: feel free to edit it in. I tried to restrict myself to a description of SMTP's dependency on DNS and practical advice for the asker, and already deleted one chapter's worth of getting sidetracked before posting.
– telcoM
Nov 26 at 11:09












It is you answer, so I trust your judgement.
– Rui F Ribeiro
Nov 26 at 11:10




It is you answer, so I trust your judgement.
– Rui F Ribeiro
Nov 26 at 11:10


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484129%2fexim-does-not-use-etc-hosts%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Accessing regular linux commands in Huawei's Dopra Linux

Can't connect RFCOMM socket: Host is down

Kernel panic - not syncing: Fatal Exception in Interrupt