Hardware with non-FQDN EHLO

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Hardware with non-FQDN EHLO

Nicolás-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware with non-FQDN EHLO

/dev/rob0
On Fri, Mar 25, 2016 at 04:39:23PM +0000, 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:
Reply | Threaded
Open this post in threaded view
|

Re: Hardware with non-FQDN EHLO

Wietse Venema
In reply to this post by Nicolás-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware with non-FQDN EHLO

Nicolás-2
In reply to this post by Nicolás-2
Thanks Wietse and Rob,

The client indeed uses SASL, but it gets rejected at HELO/EHLO time. I will observe these days if I can fence in a reduced CIDR range and use Wietse's approach, if not, I'll set up a Postfix local to the broken client, which indeed is a cleaner way than my original approach.

Thanks!

Nicolás


-------- Mensaje original --------
De: [hidden email]
Fecha:25/03/2016 17:56 (GMT+00:00)
Para: Postfix users
Asunto: 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
Reply | Threaded
Open this post in threaded view
|

Re: Hardware with non-FQDN EHLO

Noel Jones-2
On 3/26/2016 7:18 AM, Nicolás wrote:

> Thanks Wietse and Rob,
>
> The client indeed uses SASL, but it gets rejected at HELO/EHLO time.
> I will observe these days if I can fence in a reduced CIDR range and
> use Wietse's approach, if not, I'll set up a Postfix local to the
> broken client, which indeed is a cleaner way than my original approach.
>
> Thanks!
>
> Nicolás
>


If the client uses SASL, all you need to do is put
permit_sasl_authenticated before your reject_non_fqdn_helo_hostname.

No need for a CIDR table or any other workarounds.

smtpd_helo_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_non_fqdn_helo_hostname
   ... any other stuff...



  -- Noel Jones



>
> -------- Mensaje original --------
> De: [hidden email]
> Fecha:25/03/2016 17:56 (GMT+00:00)
> Para: Postfix users
> Asunto: 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

Reply | Threaded
Open this post in threaded view
|

Re: Hardware with non-FQDN EHLO

Curtis Villamizar
In message <[hidden email]>
Noel Jones writes:

>
> On 3/26/2016 7:18 AM, Nicols wrote:
> > Thanks Wietse and Rob,
> >
> > The client indeed uses SASL, but it gets rejected at HELO/EHLO time.
> > I will observe these days if I can fence in a reduced CIDR range and
> > use Wietse's approach, if not, I'll set up a Postfix local to the
> > broken client, which indeed is a cleaner way than my original approach.
> >
> > Thanks!
> >
> > Nicols
> >
>  
>  
> If the client uses SASL, all you need to do is put
> permit_sasl_authenticated before your reject_non_fqdn_helo_hostname.
>  
> No need for a CIDR table or any other workarounds.
>  
> smtpd_helo_restrictions =
>    permit_mynetworks
>    permit_sasl_authenticated
>    reject_non_fqdn_helo_hostname
>    ... any other stuff...


On http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
permit_sasl_authenticated is not listed.

Which makes some sense since the HELO occurs before AUTH.  HELO checks
seem to be all IP and hostname related.

>   -- Noel Jones

Am I missing something?

Curtis

> >
> > -------- Mensaje original --------
> > De: [hidden email]
> > Fecha:25/03/2016 17:56 (GMT+00:00)
> > Para: Postfix users
> > Asunto: Re: Hardware with non-FQDN EHLO
> >
> > Nicols:
> >> 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

Reply | Threaded
Open this post in threaded view
|

Re: Hardware with non-FQDN EHLO

Viktor Dukhovni
On Mon, Mar 28, 2016 at 05:32:24PM -0400, Curtis Villamizar wrote:

> > No need for a CIDR table or any other workarounds.
> >  
> > smtpd_helo_restrictions =
> >    permit_mynetworks
> >    permit_sasl_authenticated
> >    reject_non_fqdn_helo_hostname
> >    ... any other stuff...
>
>
> On http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
> permit_sasl_authenticated is not listed.
>
> Which makes some sense since the HELO occurs before AUTH.  HELO checks
> seem to be all IP and hostname related.
>
> Am I missing something?

    http://www.postfix.org/postconf.5.html#smtpd_delay_reject

--
        Viktor.