CheckHelo

HELO/EHLO checks can be specified using the below options. Most options can be inherited or explicitly set to yes or no.

• Use Blacklist
  • Enable the use of the global HELO/EHLO blacklist.

• Blacklist Period
  • Period the blacklisting will be active for, any successive attempts by the blacklisted host to use the blacklisted HELO/EHLO will result in the period being reset. Think of this period as the period in which Policyd v2 looks back to see if the host has used a blacklisted HELO/EHLO. This value is in seconds.

• Use HRP
  • Enable the use of helo randomization prevention. Enabling this option will track every HELO/EHLO a host uses.

• HRP Period
  • Similar in working to the Blacklist Period, this period can be thought of how far back Policyd v2 looks to see how many HELO's the host has used. If the number of unique HELO/EHLO's exceeds HRP Limit, email is rejected. This value is in seconds.

• HRP Limit
  • Reject mail when the number of unique HELO/EHLO's hits this number.

• Reject Invalid
  • Reject invalid HELO's which do not meet RFC 2821's requirements. More specifically if its not an IP address or domain name. You need to enable this in order for Reject non-literal IP and Reject Unresolvable to work. RFC 2821, page 29, section 4.1.1.1 describes the HELO/EHLO command and states the following "The argument field contains the fully-qualified domain name of the SMTP client …".

• Reject non-Literal IP
  • Reject invalid HELO's which do not meet RFC 2821's requirements. RFC 2821, page 22, section 3.6 defines a domain as being fully qualified and resolvable… "Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP…. Local nicknames or unqualified names MUST NOT be used… The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1…". Therefore, this option rejects a non-literal IP being used in a helo. ie. a.b.c.d would be rejected whereas [a.b.c.d] would be allowed. If this option is left disabled a.b.c.d would also be allowed.
  • (IPv6 support is available from r493+ and v2.1.x)
  • IPv6 address literals will be recognized aswell.

Configuration for this module is done in the CheckHelo section in the configuration file.

• enable
  • Set to 1 if you wish to enable this module. Default 0 (disabled).

• Whitelisting
  • Whitelisting of source IPv4 addresses in the format a.b.c.d[/x]. Bitmask is optional and defaults to 32.
  • Whitelisting of source IPv6 addresses. For a list of supported formats please see IP Address Specification.
  • (Supported in: r493+, v2.1.x)

Its highly recommended to use the whitelisted hosts file in the database/whitelists/ directory by running:

./parse-checkhelo-whitelist > checkhelo-whitelist.sql

Then load checkhelo-whitelist.sql into your database.

Taking the policies described in the other feature document, we can apply a reasonable set of HELO/EHLO checks to all inbound email:

Check HELO/EHLO on Inbound
Policy: Default Inbound Policy
UseBlacklist: Yes
BlacklistPeriod: 2419200 (28 days)
UseHRP: Yes
HRPPeriod: 2419200 (28 days)
HRPLimit: 5
RejectInvalid: Yes
RejectNonLiteralIP: Yes
RejectNonResolvable: No

Disable HELO/EHLO check on authenticated inbound policy
Policy: Default Inbound Policy (SASL)
UseBlacklist: No
BlacklistPeriod: Inherit
UseHRP: No
HRPPeriod: Inherit
HRPLimit: Inherit
RejectInvalid: No
RejectNonLiteralIP: No
RejectNonResolvable: No