I have been fighting with my server for days. I am trying to get postfix configured. I have it currently so that it can send mail, but receiving mail is a different story.

This is my file:

# Please be sure to read the /usr/share/doc/postfix/README.MDK file
# to learn about differences from stock postfix to Mandriva package.
# This file contains only the parameters changed from a default install
# see /etc/postfix/main.cf.dist for a commented, fuller version of this file.

mynetworks = 127.0.0.0/8 192.168.1.0/24
mydomain = wattzup.com
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
myorigin = $mydomain
disable_vrfy_command = yes
#smtpd_sasl_auth_enable = yes
#broken_sasl_auth_clients = yes
#smtpd_tls_security_level = may


smtpd_sasl_auth_enable = yes
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.pem
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.pem
broken_sasl_auth_clients = yes
smtpd_tls_CAfile = /etc/postfix/ssl/smtpd.pem
smtpd_tls_security_level = encrypt
smtpd_banner = $myhostname : Hello, welcome to $myhostname
smtpd_delay_reject = no
smtpd_sasl_security_options = 
smtpd_recipient_restrictions =

What is my problem? My DNS is properly configured as far as I can tell, and I can login to port 25 with telnet, it just isn't receiving mail...

Dani AI

Generated

Three quick diagnostic steps (in order) that usually find "Postfix can send but not receive" problems: 1) confirm DNS/MX + reverse PTR, 2) confirm Internet -> port 25 reaches the Postfix host (router/NAT/firewall), 3) confirm Postfix will accept mail (config + logs). The commands below are the minimal, repeatable checks to run from a box outside the LAN (or use an online tester). (mxtoolbox.com)

# DNS / PTR
dig MX example.com +short
dig -x 203.0.113.45 +short

# from an external host, test SMTP reachability
telnet mail.example.com 25

# quick port-listen check on the mail server
ss -lnpt | grep :25

Postfix config mistakes are common culprits. If neither smtpd_relay_restrictions nor smtpd_recipient_restrictions contains a proper reject_unauth_destination/defer_unauth_destination rule, Postfix can refuse to receive mail. Use postconf -n to show active settings, postfix reload after changes, and tail the Postfix log while an external test is run. For deeper protocol troubleshooting enable verbose smtp logging (temporary change to the smtp line in master.cf). (postfix.org)

postconf -n | grep recipient_restrictions
postfix reload
# follow logs (or use journalctl on systemd systems)
tail -f /var/log/mail.log
# to enable verbose SMTP logging: add '-v' to the smtp service in /etc/postfix/master.cf then reload

About PTR and NAT: a public PTR must be set by the owner of the IP block (ISP or the RIR if the block is delegated). Adding a PTR in a local BIND/Webmin zone is only useful if the parent in-addr.arpa zone is delegated to that server; otherwise request the PTR from the provider (or use your cloud provider control panel if they offer PTR management). Also confirm router port-forwarding and the server firewall (ufw/iptables) allow inbound TCP/25, and note some providers block or restrict port 25 by policy (AWS, some VPS providers). (arin.net)

As suggested, verify an external telnet/nmap/MXToolbox check while watching the Postfix logs. If the connection never reaches the server, focus on NAT/firewall/host-provider policy; if it reaches the server but is rejected, the log lines will show why.

Recommended Answers

All 3 Replies

It's very difficult to tell without more information.

When I am troubleshooting email problems, I like to test each link of the process individually. That way I can eventually arrive - at least - where the problem is located. That way I can apply my attention to the proper component instead of having to consider the entire chain at once.

First of all, let's have a look at your domain name and how it stacks up at www.dnsstuff.com:
http://www.dnsstuff.com/tools/dnsreport?domain=wattzup.com&format=raw&loadresults=true&token=15211bcd8a853d343097ca1b2f18e016
(link valid for 7 days)

As you can see, there may be a problem with remote mail servers connecting to your email server.

Check your firewall settings to ensure that there is a rule allowing traffic (only) from the public IP of your firewall to the internal IP address of your mail server on port 25. (For additional security you can also configure your mail server to use an alternate port and shift the port from 25 on the public side of your router to the alternate port on your mail server's internal IP address.)

THEN - the really bad part is - if your sender's mail server is configured properly, they will never ever even attempt to connect to your email server because your public IP address does not have a reverse lookup entry at your IP address provider. (ISP)

This is normally used when accepting connections from your mail server . . . but a lot of mail servers are beginning to use reverse DNS lookups for connections to your mail server as well.

If I were you, I would concentrate on the connection on port 25 from your router's public address to your mail server's internal IP.

A question I have is . . . where are you telnetting from when testing? Remember that while troubleshooting anything network-wise, perspective makes all the difference in the world. Telnet from another device on your internal network is very different than telnetting from somewhere outside the LAN and of course both of those are different than telnet from the same server to port 25 on the same server.

Which reminds me - if you're testing by telnetting from the same server, you may need to add an allowed host to your server - which would be the internal IP address of your router.

Whew! So many variables . . .

Let us know how it goes -

I hope this helps -

/David C.

Thanks David,

Another question. Do you have and hints or tips on how to setup the reverse dns with BIND? I am using Webmin too if that could help.

Typically, the entity that has responsibility for the public IP address space that you're using would set up the PTR record in their DNS for you. This is most often an ISP or telco carrier.

You can set up your own PTR record, but since your name server isn't authoritative for that IP range, it would most likely not provide the confirmation that other mail servers are looking to receive. They are going to trace down from the root name servers to the assigned entity for your IP space. You can find that by doing a whois lookup at this web site:

https://www.arin.net/

Search whois is in the upper right corner.

Enter your router's public IP and you will be able to see who has responsibility for that address. Contact them to submit your request for the PTR record.

Not sure about the Webmin interface - I've never used it myself. Sorry about that.

I hope this helps -

/David C.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.