Postfix, iPhone, Apple Mail and the reject_unknown_helo_hostname parameter
- Postfix, iPhone, Apple Mail and the reject
- Updating the SSL certs on the Unifi Controller
- Firefox and org-protocol URL Capture
- System Hangs on Shutdown
- Let's Encrypt Certificates and Arch
- /bin/mail as MTA
- Filtering bots with erc
- DSCP Tagging with iptables
- Bitlbee, Purple-Sipe-Lync, and Certificates
- daemontools, Apache, and the Whole Process Group
- Comma Trouble
- Emacs DNS Mode
- Wrangling Namespaces in Python
- Using Skype from Emacs
- Choosing the Right Technology
- Django, Testing, and Sessions
- KMS, xvideo-intel, and Arch Linux
- Verizon UMW-190 and Arch Linux
- Hawking Range Extender and Linux
- CUPS driver for the Dell 1320C Printer on Arch
- SANE and the Canon LIDE 20
- Getting easypg working in Ubuntu
Postfix, iPhone, Apple Mail and the reject_unknown_helo_hostname parameter
Published 2021-07-02
I run a mailserver for the various domains I've collected over the years. Due to a change in my mail routing (I'm dual homed on the intertubes), the iUsers in my crew were unable to send mail.
I use Postfix (under Arch Linux) and had the following for my smtpd_helo_restrictions parameter in main.cf:
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname,
reject_non_fqdn_hostname
Looking at the logs I saw that when an iUser connected, Apple Mail used a fake hostname:
Jul 02 17:05:08 smtp1 postfix/smtpd[101775]: connect from unknown[x.x.x.x] Jul 02 17:05:09 smtp1 postfix/smtpd[101775]: NOQUEUE: reject: EHLO from unknown[x.x.x.x]: 550 5.7.1 <smtpclient.apple>: Helo command rejected: Host not found; proto=SMTP helo=<smtpclient.apple> Jul 02 17:05:09 smtp1 postfix/smtpd[101775]: lost connection after EHLO from unknown[x.x.x.x] Jul 02 17:05:09 smtp1 postfix/smtpd[101775]: disconnect from unknown[x.x.x.x] ehlo=0/1 commands=0/1
I looked through my logs (thank you, ElasticSearch) for "Helo command rejected: Host not found" and found that there are a lot of issues. Some examples:
"helo=<suitepmta021102.emarsys.us>" – maybe a one of the mailservers for sur La Table since the email was from email.surlatable.com:
$ ping -c 1 emarsys.us ping: emarsys.us: No address associated with hostname $ host emarsys.us emarsys.us mail is handled by 10 return0.emarsys.net. emarsys.us mail is handled by 10 return1.emarsys.net.
$ ping -c 1 email.surlatable.com ping: email.surlatable.com: No address associated with hostname $ host email.surlatable.com email.surlatable.com mail is handled by 10 e3uspmta9.emarsys.net. email.surlatable.com mail is handled by 10 e3uspmta2.emarsys.net. email.surlatable.com mail is handled by 10 e3uspmta3.emarsys.net. email.surlatable.com mail is handled by 10 e3uspmta10.emarsys.net. email.surlatable.com mail is handled by 10 e3uspmta1.emarsys.net. email.surlatable.com mail is handled by 10 suitempta02.emarsys.net. email.surlatable.com mail is handled by 10 suitepmta01.emarsys.net. email.surlatable.com mail is handled by 10 e3uspmta4.emarsys.net.
The "helo" address isn't one of their mail servers?
"helo=<r72p76.contact.loccitane.com>"
$ host r72p76.contact.loccitane.com r72p76.contact.loccitane.com has address 130.248.204.72
- Has an A record and but no MX records (dig confirms).
"helo=<mta200221.neimanmarcusemail.com>"
$ host mta200221.neimanmarcusemail.com mta200221.neimanmarcusemail.com has address 72.166.183.56
- Has an A record but no MX records.
The reject_unknown_helo_hostname configuration parameter is documented as: "Reject the request when the HELO or EHLO hostname has no DNS A or MX record." So it looks like both an A record and MX record are required? I'm guessing here based on the above. Clearly, if you dig the mail record on the base domain you get valid MX records, but it seems the "HELO" logic doesn't do DNS lookups for the base domains.
Checking the hostname did block a ton of dynamic IPs from connecting…
I removed the parameter and the iUsers were able to send mail. Also, the spam got further down the stack before being rejected. :(
org-mode