Incoming Mail Problems: Difference between revisions

No edit summary
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Troubleshooting incoming mail ==
{{BC|Certified}}
__FORCETOC__
<div class="col-md-12 ibox-content">
=Troubleshooting incoming mail problems=
{{KB|{{ZC}}|{{ZCS 8.8}}|{{ZCS 8.7}}|{{ZCS 8.6}}|}}


==Problem==
If you're having trouble receiving mail from outside, you need to find out where the message is failing.
If you're having trouble receiving mail from outside, you need to find out where the message is failing.


Line 9: Line 14:


If you see ''nothing'' logged (no connection, nothing) then the problem likely either [[DNS]] or your firewall.
If you see ''nothing'' logged (no connection, nothing) then the problem likely either [[DNS]] or your firewall.
 
==Resolution==
== Firewall ==
=== Firewall ===
 
To troubleshoot your firewall, it helps to have an account on a system outside of your network.
To troubleshoot your firewall, it helps to have an account on a system outside of your network.


For mail to flow inbound, servers on the internet need to connect to your [[MTA]] on port 25.
For mail to flow inbound, servers on the internet need to connect to your [[MTA]] on port 25.


== [[DNS]] issues ==
=== [[DNS]] issues ===
 
The mail domain that your user accounts are created under must have an MX record.  To test this:
The mail domain that your user accounts are created under must have an MX record.  To test this:
   host -t mx ''domain''
   host -t mx ''domain''
Line 23: Line 26:
The IP address returned should be the IP (public or private) of your MTA.  If it's the public address, make sure that the Firewall is forwarding port 25 to the [[MTA]].
The IP address returned should be the IP (public or private) of your MTA.  If it's the public address, make sure that the Firewall is forwarding port 25 to the [[MTA]].


== Mail is delivered to the [[MTA]], but not to the mailbox ==
=== Mail is delivered to the [[MTA]], but not to the mailbox ===
 
If there is a line in the /var/log/zimbra.log like:
If there is a line in the /var/log/zimbra.log like:
   postfix/lmtp ... deferred ... connection refused
   postfix/lmtp ... deferred ... connection refused
Line 32: Line 34:
This is nearly always caused by a host that is configured on private IP Space (or using NAT) and that does not have an interface for the public IP address the server resides on.  This can be easily fixed by simply using native IP address lookups for lmtp rather than DNS.  Alternatively, you could have your internal network's domain name configured to lookup differently internally than it does externally.  Using that method is beyond the scope of this document.
This is nearly always caused by a host that is configured on private IP Space (or using NAT) and that does not have an interface for the public IP address the server resides on.  This can be easily fixed by simply using native IP address lookups for lmtp rather than DNS.  Alternatively, you could have your internal network's domain name configured to lookup differently internally than it does externally.  Using that method is beyond the scope of this document.


To lookup lmtp addresses natively instead of by DNS, simply modify the following localconfig values on all mta's:
==== Zimbra Collaboration 8.5 or above ====
ZCS 8.5 or above onwards this attribute is now in ldap - zimbraMtaLmtpHostLookup
  zmprov ms mtaserver.com zimbraMtaLmtpHostLookup native
  zmprov ms `zmhostname` zimbraMtaLmtpHostLookup native


zmlocalconfig -e postfix_lmtp_host_lookup=native
In case that you are using Single Server, be aware always of the Global Config as well:
  zmprov mcf zimbraMtaLmtpHostLookup native


Once this is done, you'll need to restart the mta:
Once this is done, you'll need to restart the mta:
  zmmtactl restart


zmmtactl restart
==== Zimbra Collaboration 8.0 or previous ====
To lookup lmtp addresses natively instead of by DNS, simply modify the following localconfig values on all mta's:
  zmlocalconfig -e postfix_lmtp_host_lookup=native


Once this is done, you'll need to restart the mta:
  zmmtactl restart
=== Expected behavior ===
Postfix will now lookup IP's for lmtp natively rather than in DNS, so you'll just need to ensure the host is properly configured in /etc/hosts and things will work correctly.
Postfix will now lookup IP's for lmtp natively rather than in DNS, so you'll just need to ensure the host is properly configured in /etc/hosts and things will work correctly.


{{Article Footer|unknown|1/13/2012}}
{{Article Footer|ZCS 8.7, 8.6, 8.0|1/13/2012}}
 
{{NeedSME|Jorge|SME2|Copyeditor}}
[[Category:Troubleshooting MTA]]
[[Category:Troubleshooting MTA]]

Latest revision as of 07:44, 20 April 2022

Troubleshooting incoming mail problems

   KB 1336        Last updated on 2022-04-20  




0.00
(0 votes)

Problem

If you're having trouble receiving mail from outside, you need to find out where the message is failing.

When sending your test message, check the Log Files, especially /var/log/zimbra.log, on your MTA server.

It's often helpful to tail the logfile as you send the message:

 tail -f /var/log/zimbra.log

If you see nothing logged (no connection, nothing) then the problem likely either DNS or your firewall.

Resolution

Firewall

To troubleshoot your firewall, it helps to have an account on a system outside of your network.

For mail to flow inbound, servers on the internet need to connect to your MTA on port 25.

DNS issues

The mail domain that your user accounts are created under must have an MX record. To test this:

 host -t mx domain

The IP address returned should be the IP (public or private) of your MTA. If it's the public address, make sure that the Firewall is forwarding port 25 to the MTA.

Mail is delivered to the MTA, but not to the mailbox

If there is a line in the /var/log/zimbra.log like:

 postfix/lmtp ... deferred ... connection refused

There is no connection to port 7025 to perform Local Mail Transfer Protocol (LMTP) delivery.

This is nearly always caused by a host that is configured on private IP Space (or using NAT) and that does not have an interface for the public IP address the server resides on. This can be easily fixed by simply using native IP address lookups for lmtp rather than DNS. Alternatively, you could have your internal network's domain name configured to lookup differently internally than it does externally. Using that method is beyond the scope of this document.

Zimbra Collaboration 8.5 or above

ZCS 8.5 or above onwards this attribute is now in ldap - zimbraMtaLmtpHostLookup

 zmprov ms mtaserver.com zimbraMtaLmtpHostLookup native
 zmprov ms `zmhostname` zimbraMtaLmtpHostLookup native

In case that you are using Single Server, be aware always of the Global Config as well:

 zmprov mcf zimbraMtaLmtpHostLookup native

Once this is done, you'll need to restart the mta:

 zmmtactl restart

Zimbra Collaboration 8.0 or previous

To lookup lmtp addresses natively instead of by DNS, simply modify the following localconfig values on all mta's:

 zmlocalconfig -e postfix_lmtp_host_lookup=native

Once this is done, you'll need to restart the mta:

 zmmtactl restart

Expected behavior

Postfix will now lookup IP's for lmtp natively rather than in DNS, so you'll just need to ensure the host is properly configured in /etc/hosts and things will work correctly.

Verified Against: ZCS 8.7, 8.6, 8.0 Date Created: 1/13/2012
Article ID: https://wiki.zimbra.com/index.php?title=Incoming_Mail_Problems Date Modified: 2022-04-20



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »


Wiki/KB reviewed by Jorge SME2 Copyeditor Last edit by Barry de Graaff
Jump to: navigation, search