Hardware with non-FQDN EHLO
Hi, I have some hardware which I've configured to send e-mails through my Postfix server. Unfortunately, this hardware's firmware has its' EHLO command hardcoded, not being it an FQDN. In Postfix, I've configured smtpd_helo_restrictions to have reject_non_fqdn_helo_hostname and I'm pretty happy with it so I don't want to remove it, however it makes its' attempts to get rejected. Another issue is that it's connections are made from a dynamic IP address, so whitelisting its IP address is not an option. However, it has a dynamic hostname which updates each time it changes (a DynDNS-like host). I know I can't add hostnames to $mynetworks, so my last resource would be writing a policy service which would check the client's IP address and match it with the dynamic hostname, and if positive, accept the EHLO command before it reaches the reject_non_fqdn_helo_hostname restriction. I'd like to know if there's a simpler way to handle these kind of situations, though. Do you guys have some tips? Thanks. Nicolás
Re: Hardware with non-FQDN EHLO
On Fri, Mar 25, 2016 at 04:39:23PM +, Nicolás wrote: > I have some hardware which I've configured to send e-mails through > my Postfix server. Unfortunately, this hardware's firmware has its' > EHLO command hardcoded, not being it an FQDN. > > In Postfix, I've configured smtpd_helo_restrictions to > have reject_non_fqdn_helo_hostname and I'm pretty happy with it so > I don't want to remove it, however it makes its' attempts to get Yes, reject_non_fqdn_helo_hostname is safe and effective, but ONLY when used on port 25. You should keep submission separate from MX mail (from other MTAs.) Clients like this broken device should be using submission, which would have -o overrides eliminating all unsafe (port-25-only) restrictions. (Submission should be some variant of "permit_sasl_authenticated,reject".) > rejected. Another issue is that it's connections are made from a > dynamic IP address, so whitelisting its IP address is not an > option. However, it has a dynamic hostname which updates each time > it changes (a DynDNS-like host). Does the client not authenticate? > I know I can't add hostnames to $mynetworks, so my last resource > would be writing a policy service which would check the client's IP > address and match it with the dynamic hostname, and if positive, > accept the EHLO command before it reaches > the reject_non_fqdn_helo_hostname restriction. > > I'd like to know if there's a simpler way to handle these kind of > situations, though. Do you guys have some tips? It might be easier and cleaner to set up a Postfix local to the broken client, which would accept the mail from it, and relay it on to the real server safely (SASL AUTH + STARTTLS on submission.) The SOHO_README will have some guidance for you if you do that. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Hardware with non-FQDN EHLO
Nicol?s: > Hi, > > I have some hardware which I've configured to send e-mails through > my Postfix server. Unfortunately, this hardware's firmware has > its' EHLO command hardcoded, not being it an FQDN. > > In Postfix, I've configured smtpd_helo_restrictions to > have?reject_non_fqdn_helo_hostname and I'm pretty happy with it > so I don't want to remove it, however it makes its' attempts to > get rejected. Another issue is that it's connections are made from > a dynamic IP address, so whitelisting its IP address is not an > option. However, it has a dynamic hostname which updates each time > it changes (a DynDNS-like host). Wrap the reject_non_fqdn_helo_hostname inside an access table: smtpd_mumble_restrictions = ...other stuff... check_client_access cidr:/etc/postfix/reject_non_fqdn_helo.cidr ...more stuff... /etc/postfix/reject_non_fqdn_helo.cidr: # Unlike hash files, cidr files are matched in the order of rules. # IPv4 1.2.3.4 dunno 0.0.0.0/0 reject_non_fqdn_helo_hostname # IPv6 1:2::3:4 dunno ::0/0 reject_non_fqdn_helo_hostname It's a bit clumsy with the CIDR patterns, but hash-based access maps don't have a wild-card pattern. Wietse
