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 usingtelnet 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
|
show 5 more comments
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 usingtelnet 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
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
|
show 5 more comments
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 usingtelnet 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
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 usingtelnet 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
ubuntu exim
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
|
show 5 more comments
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
|
show 5 more comments
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.
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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